过度设计是毒药
有一句成语叫“过犹不及”，意思是事情做过头了，和做得不够是一样的。还有一句成语叫“画蛇添足”，意思大家都明白，但是我还想再重复一下这个小故事，楚国有个祭祀的人，把一壶祭酒赏给前来帮忙的门客。门客们互相商量说：“几个人喝这壶酒不够，一个人喝这壶酒足够。请大家在地上画蛇，先画成的人喝酒。”一个人先把蛇画好了。他拿起酒壶准备饮酒，就左手拿着酒壶，右手画蛇，说：“我能够给蛇添上脚！”没等他画完，另一个人的蛇画成了，夺过他的酒说：“蛇本来没有脚，你怎么能给它添上脚呢？”于是就把壶中的酒喝了下去。意思是办了多余的事，反而把事情办糟了。 简单两句成语，意义却很深刻，即使放在软件开发中，表现的也尤为明显，对于过犹不及来说，其实做过头了，还不如没做到，因为你要花双倍时间去纠正这个错误。 现在我们把画蛇添足这个典故翻译为软件行业的一个故事，就更直观了，就是说呢，现在接到一个客户的软件项目，目标是要画一条蛇，而酬劳呢，就是一壶酒，现在有一个部门负责这个项目，需求调研完毕，说需要30天交付给用户，OK，开工，设计，编码，测试，没想到20天就完成了，还有十天空闲，项目经理来了，他很见不得开发人员清闲，就说，反正离交付时间还早，我们不如把用户的需求再分析分析，争取加些功能，做的更好，让客户更满意。经理说啥是啥，那就开始吧，就有好事者提议，你看蛇没脚，不好看，加上脚，说不定客户会更满意呢，经理拍板，就这么定了，花了十天功夫把脚加了进去，交付。用户一看，SHIT，你们家蛇还长脚呢，不予签字接收，一脚踢回来，还原我原本的需求，这个部门又开始忙着把脚去掉，项目经理仿佛没事人一样，又催着进度，可怜程序员又加班，花了十天去掉，再交付用户。行，可以用了，不过晚了十天，扣了不少尾款。看看，本来20天就已完成的项目，剩下的十天学习也好，休假也好，舒舒服服，既保证了交付时间，又减轻了劳动强度。可是，偏偏多了那只脚，时间拖了一倍，利润少了一截，程序员加了十天班，过度设计可怕不可怕？ 再举一个更接近点的例子，比如，在一个软件产品中，有一个配置文件，保存着用户一些自定义的参数配置，程序的很多功能依赖于这个文件，那么在开发的时候，又有聪明人想到，万一这个配置文件丢失或者损坏了怎么办（这种人总有很多个万一，那种极端情况一分钟能想十几个，正常功能设计半天说不出来一个的自作聪明的聪明人），如果碰到这种情况，我们自动生成一个配置文件，里面的参数都是缺省值，不会影响用户的使用的，多好，就这么干，这好啊，好的我想用板砖敲他，产品完成了，用户用了大半年，嗯，没问题，挺好。偏偏某一天，配置文件真就没了，误删除也好，系统原因也好，总之没了，可是用户不知道，循例打开程序，照样用，这就是自动生成的缺省配置文件的功劳，这样用了一个星期，有点不对劲，客户纳闷怎么我以前的参数不是这么配的啊，这产生的数据啊，文件啊全都不对，于是反馈给技术支持部，技术支持人员一看，没啥问题啊，配置文件就是那样配的啊，说这客户，睁眼说瞎话，与客户争辩，客户怒了，发一通飙，技术支持心虚了，一查历史，还真是，怎么以前是那样的，现在是这样的，这咋回事啊，百思不得其解，去找以前负责开发这个产品的聪明人，人家已经升成经理不管这事了，那么自己看代码吧，找啊找，原来陷阱在这里，靠，坑爹啊，删除这段自作聪明的垃圾代码，才解决，前前后后折腾了三个星期，还要给客户做合理的解释，头大不头大？ 那么，怎么避免过度设计呢？真没什么好办法，软件设计基于对需求的深度理解，对功能的精准把握，这完全取决于设计者一个综合的判断，从我的经验来看，这个东东类似于天资，有些人总就提高不了，遇到这种情况，只有借助于外力把他纠正过来，或者，干脆换个人吧
