过度设计-举例(转)

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

再举一个例子，对闰年的判断逻辑：
　　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年内，这个模块就因为其它原因要重构）
　　为什么要为了未来的支撑能力，耗费现在的开发资源呢？做一个额外的表，不是增加新的逻辑吗？