您现在的位置是:首页 > 文章详情

设计要做到扩展性强还挺难的

日期:2018-11-21点击:464

概述


在日常开发中,有时候你的上司会跟你说,这个模块的设计扩展性要高。把这句话说出来很简单,但是要做到则非常难。导致难的其中一个因素是:

你不熟悉这个行业的业务的玩法

我举个例子来说明。像电商行业里的满多少减多少这样的营销活动,如果你一开始只是认为这种活动就是单指满多少钱减多少钱的话(例如:满100元减20元),那么就很有可能导致无论你如何设计,它都不具备可扩展性。为什么呢?

由于你只是认为只有类似满100元减20元这样的玩法,就很有可能如下设计表:

CREATE TABLE `manjian_activity` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键', `activity_name` varchar(100) NOT NULL DEFAULT '' COMMENT '活动名称', `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '活动状态', `target_price` int(11) DEFAULT NULL COMMENT '满减,目标金额', `off_price` int(11) DEFAULT NULL COMMENT '满减,减额' ) 

以满100减20为例子,target_price就是100,off_price就是20,我们把这两个钱放置在活动表里了。好了,所有的业务代码都围绕这样的表设计来写代码,也经过测试和上线了。表面看起来一帆风顺的,但是产品经理还会再跟你提需求,说我们要支持如下规则:

  • 满100享受5折
  • 满100送1件赠品
  • 要支持梯度,满100元减20,满200减30

这个时候就傻眼了,manjian_activity表不支持这样的玩法,而之前的所有代码已经围绕这个表设计来展开了。如果要支持新的玩法,改动会很大。这个时候你可能会说,当时的表设计真烂。但是你要知道,设计者当时对满多少减多少这种营销活动的认知是不够的,不知道业界各种各样的玩法,怎么可能会有扩展性强的设计呢。这个不能怪罪开发。

如果一早就知道满减这种营销活动的各种业务玩法,那么我们就知道需要设计一张规则表,来存储规则。像

  • 满100享受5折
  • 满100送1件赠品
  • 要支持梯度,满100元减20,满200减30

这些都是规则。

CREATE TABLE `manjian_rule` ( `id` int(11) NOT NULL AUTO_INCREMENT, `threshold_value` int(11) NOT NULL DEFAULT '0' COMMENT '门槛值', `discount_type` int(11) NOT NULL DEFAULT '0' COMMENT '优惠类型0 减钱,1 打折 2 送赠品', `discount_value` varchar(50) NOT NULL DEFAULT '' COMMENT '优惠值,字符意义由优惠类型决定', `activity_id` int(11) NOT NULL COMMENT '满减活动id' PRIMARY KEY (`id`) ) 

manjian_rule表就可以满足产品提的新需求了。一个活动对应的所有规则都在manjian_rule里。


小结


从上面的例子可以总结出几个小的体会:

  • 当你从产品经理那里拿到需求后,在做代码设计前,可以先问他,这个模块后面会怎么发展,提前了解一些将来可能要做的业务;
  • 自己参与某个模块开发的时候,如果业界也有类似的东西,最好也去了解一下,大家都是怎么玩的;
  • 你的设计不具备扩展性,导致后续改动起来难,也不要灰心气馁,因为有些情况下真的很难做到设计扩展性强。

原文链接


设计要做到扩展性强还挺难的

原文链接:https://my.oschina.net/samgege/blog/2885394
关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。

文章评论

共有0条评论来说两句吧...

文章二维码

扫描即可查看该文章

点击排行

推荐阅读

最新文章