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

概述

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

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

我举个例子来说明。像电商行业里的满多少减多少这样的营销活动,如果你一开始只是认为这种活动就是单指满多少钱减多少钱的话(例如:满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里。

小结

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

  • 当你从产品经理那里拿到需求后,在做代码设计前,可以先问他,这个模块后面会怎么发展,提前了解一些将来可能要做的业务;
  • 自己参与某个模块开发的时候,如果业界也有类似的东西,最好也去了解一下,大家都是怎么玩的;
  • 你的设计不具备扩展性,导致后续改动起来难,也不要灰心气馁,因为有些情况下真的很难做到设计扩展性强。
    原文作者:Sam_Deep_Thinking
    原文地址: https://blog.csdn.net/linsongbin1/article/details/83654935
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞