谈谈"设计不足"与"过度设计"

昨天看到一老兄的文章，深有感触，所以转载来给大家分享一下

转载自：http://www.cnblogs.com/mainz/archive/2008/07/06/1237046.html

 

 

什么是设计不足(under-engineering)？设计出来的系统复用性差，扩展性不强，不能灵活的应对变化，简言之，设计没到位。设计不足，多半是因为经验有限，设计能力有限。

什么是过度设计(over-engineering)？设计出来的系统比恰到好处要复杂臃肿的多，过度的封装、一堆继承、接口和无用的方法，超复杂的xml配置文件，简言之，客户需求是要一把杀鸡的刀，你给设计了一把牛刀（杀鸡用牛刀）。过度设计，多半是因为有设计的癖好，喜欢炫耀或玩弄无谓的技巧，或是喜欢把简单的问题搞复杂化。

如此说来，没有人能说自己的设计就是恰到好处的。适合的就是最好的，但什么是适合的？这个度很难把握。

客户只是告诉你他“需要一把杀鸡的刀”，至于将来有没有需求变化，有没有可能要这把刀能杀牛，客户也不知道。所以当然这个设计的度就很难把握了。

 

有人主张设计必须前瞻与用户需求，不能以需求为导向。因为客户从来不会告诉你他未来的需求，连他也不知道。例如，消费者从来不会告诉RIM公司，我需要一款能收企业邮件的BlackBerry手机。

但也有人持相反观点，认为设计必须以需求为导向，软件以人为本，以用为本。

其实从一定意思上说，过度设计和设计不足都是“设计错误”的一种形式。

设计不足，则意味着系统复用性扩展性和灵活性差，系统僵化，不能应对将来的需求变化，或者将来修改和维护的代价和成本会很高，这当然是设计错误；

过度设计，则意味着为了实现这个设计要付出的额外代价，例如成本上升，缺陷可能性加大，提升维护成本，甚至降低系统性能。而可维护性和系统的高性能都是系统的隐性需求，这些需求没实现好，当然也是设计错误。

从另外一个角度看来，能够进行过度设计的，多半设计能力高于设计不足的；过度的设计改回来的成本也比设计不足的改过去的成本低的多。

 

Martin Fowler说敏捷开发不是轻视设计重实践和重构，而是演进式的设计(Evolutionary Design，区别与计划性的设计 Planned Design)。每一次的重构和迭代都映射和更新到最新的设计中来，从而最大限度的满足客户的功能性需求和非功能性需求。从最初的Prototyping、初始需求分析与建模，然后进行演进式的架构设计和实践，这也许是适合于大多数中小型项目的最佳实践。

 

因为变化是无穷无尽的，需求是变幻莫测的，我们每天都跟在需求后面跑，跑的很累。而客户还要求我们随需应变，抱怨我们不够敏捷，要求我们以欢喜的心态来拥抱变化，因为变化就是IT的机会嘛! 但我们能找到“银弹”来封装所有未知的需求变化吗？我们能超前于客户的需求，能变被动为主动吗？我们能设计出一个系统超前于未来客户的需求吗？

 

没有一个完美的能随需应变的系统，所谓“设计之美”也是盛名之下其实难副。我们实际的目标只是最大限度的封装变化，最大限度的预测某些未来可能的变化，提供某些系统扩展和变化的可能性，从而减低未来变化的成本，为客户创造价值。

 

也许，最简单的才是最好的。大巧若拙，大道至简，有时候越简单的反而越难实现，而且越接近真理。也许这个只能靠个人体会和悟性了，才能最终体会到简单的精妙设计之美。熟背各种设计模式、学个一招半式的人，就像一个天天背着一把剑的剑客一样，唯恐旁人不知道其剑术高强；而真正的高手是手中无剑，却照样可以打赢别人，因为万物都可被他用来施以剑法。这才是真正的高境界。

 

我们缺乏的是真正有创意的创造性的设计，比如我们为什么没有设计出中国人自己的framework和platform？因为我们经验、技术和设计能力不足，大家都沉迷于玩一些小技巧，战术技巧，不是战略技巧；玩到30岁然后都去做PM做培训做销售去了。而在那些需要简约设计的地方，我们却自诩为高手而加上很多华丽的设计来维护虚幻的可扩展性和灵活性。

中国的架构师，缺乏的不仅仅是经验、技术、创意、设计能力，也许最缺乏的是思想，是心境。

 

同意，特别是最后一句。个人认为，解决设计不足与过度设计的问题可以先做加法，再做减法。

我怎么感觉实际项目中，没怎么有时间重构，都是推倒重来。。。

老生常谈，永远没有结果。
软件工程本身就是世界上最烂的工程，稳定性极差，变速太多。
如果谈项目技术稳定，不如先谈软件体系本身，和开发人员的稳定。

对基于重构的演进式设计，我也比较喜欢
不过对于文中所说的“最简单的才是最好的”，就不是很赞同
首先，“简单”这个词更多的是人主观的看法，缺少客观的衡量标准，至少文章中没有说，只是空泛的和抽象的形容了一下，这样就容易变成“谈玄”，虽然听上去很有道理，但没有实质的帮助。而且，所谓“真正的高手是手中无剑”，也只是武侠小说里的想象，缺乏现实基础。实际情况是，拿刀的一般还是比空手的更有威胁，拿枪的就更不用说了。
其次，“最”简单的也未必是最好。爱因斯坦的名言里有一句，“Everything should be made as simple as possible, but no simpler. ”。这也是说要简单，但不能过于简单。
另外，我想举个例子，就是1到100的整数求和的问题。对于学过等差数列的人来说，用等差数列求和公式计算是很自然的选择，计算方法也很简单。但对于没有学过的人来说，也许就只能一个一个数的相加了，这种方法虽然计算量非常大，但也可以认为是很“简单”，因为它的计算方法很直接，基本上是人人都会，连没上过学的人也可以慢慢的来算（虽然计算过程中出错的可能性很大）。所以，对不同的人，或者从不同的角度去看，“简单”的标准都不一样。我们只能根据具体的情况来选择比较合适的“简单”。
对于设计不足和过度设计，用上面的例子也可以来描述一下。我觉得用一个一个数相加的方法来计算1到100的整数之和，这就是设计不足。用等差数列求和公式来算1+2+3，就是过度设计。当然，现实中设计不足和过度设计的差别往往不是那么容易区分，甚至不同人的看法都会有很大的差异。不过我们还是可以参考一些专家（例如Kent Beck、Martin Fowloer、Robert C. Martin等）的意见，然后结合自己的实际情况，通过不断的实践和思考，应该能大大提高对设计的审美能力和控制能力，设计出较为理想的系统

设计不足-----设计者还没有什么设计经验。
过度设计-----开始学习设计了，但还是菜鸟，处于练习阶段
恰当设计-----经过若干次过度设计的教训之后，知道用最简练的方法来解决问题（注意，是简练不是简单）
努力程度，经验值，以及逻辑抽象能力都会影响架构师的能力。

有个词叫“重构”

大巧若拙，大道至简

具体的设计程度要根据项目，这个没法定论

lz 终于开始认真研究什么是过度设计了,还记得lz的"过度设计之嫌"文章中引来了众多的讨论和口水,我还建议lz要明确过度设计的标准,没想到lz已经开始研究了,赞赏研究精神,确实只有明白了什么是过度设计,什么是设计不足,我们才能有个一致的标准面对问题,别人可能做的是超级网银的系统,你告诉他要简化结构,他要批死你,告诉你系统设计要怎么怎么弄才合适,可能你做的只是一次性的学校中的学籍管理系统,你用别人的结构,你会骂设计这个结构的人,脑子有病,MVC系统要用这么复杂的结构,简单几个类不就好了.另外我也比较赞同这位兄弟的言论

[quote="treblesoftware"]老生常谈，永远没有结果。
软件工程本身就是世界上最烂的工程，稳定性极差，变速太多。
如果谈项目技术稳定，不如先谈软件体系本身，和开发人员的稳定。[/quote]