以前总是举不出过度设计的例子,今天遇上一件事,总算有了一个反例：
程序员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年内,这个模块就因为其它原因要重构）
为什么要为了未来的支撑能力,耗费现在的开发资源呢?做一个额外的表,不是增加新的逻辑吗?
再举一个例子,对闰年的判断逻辑：
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多年中,我的代码都不会出问题.
过度设计,需要更多设计时间和测试成本,如无必要,还是尽量简洁一些好.
