过度设计-举例

过度设计,需要更多设计时间和测试成本,如无必要,还是尽量简洁一些好。
未来的事情,比如 访问量,比如数据库的容量,比如是否需要改成分布式  都是无法预料的

再举一个例子,对闰年的判断逻辑:
  1、 if($Year%4==0) return True; else return Fasle;
  2、if (   ($Year%4==0  &&  $Year%100!=0 )  ||  $Year%400==0  ) retrue True; else return False;
  我选择了第一种逻辑,当然第二种更为标准。我的原因是:
  1、第一种逻辑速度够快;
  2、我做的不是日历程序,只是一个应用需要判断闰年;2100年,对我来说太遥远,我的编码活不到那一年,中间肯定被别人废弃了。在未来的80多年中,我的代码都不会出问题。


实际例子:

以前总是举不出过度设计的例子,今天遇上一件事,总算有了一个反例:
  程序员A编写代码,记录用户购买商品记录,设计1个8字节字段,前4个放用户ID,后4个放商品ID。
  粗看设计没有太大问题。实际编码中,发现数据库中商品ID,是long long类型,8个字节。他遇上困难,卡在那里了。他找上leader,说明要改设计,需要更多时间,完美兼容这种情况。
  但是现在没有足够的时间,来做大的变动,于是找了个折中方案,整个字段8字节放商品ID,另外再用一张表去关联用户ID同商品ID的购买关系。

  在我看来,这就是过度设计了。
  我的方案,仍然坚持原有设计,前4字节放用户ID,后4个字节放商品ID的后4字节。这个方案,是有缺陷的,商品ID是一个自增的循环数,存在一种 用户ID+商品ID后4字节 重复的可能性。
  但是我们考虑一下,现有商品ID增长到:约2亿,4个字节能够支撑40亿商品,现有商品库运营4年了。
  按照现在的业务发展速度,无论如何,2年内,我看不到一点重复的可能。不需要重新设计,简单把功能实现。并记录,规划在1年后重构这部分代码。(很可能在1年内,这个模块就因为其它原因要重构)
  为什么要为了未来的支撑能力,耗费现在的开发资源呢?做一个额外的表,不是增加新的逻辑吗?

你可能感兴趣的:(过度设计)