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

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

转载自：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做培训做销售去了。而在那些需要简约设计的地方，我们却自诩为高手而加上很多华丽的设计来维护虚幻的可扩展性和灵活性。

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

 

评论

16 楼 jespring 2010-10-08  

lipeixin说的太复杂，就好比软件做的很复杂，客户直接就不想用了，你设计再好，没用。

15 楼 clufeng 2010-10-08  

计划赶不上变化呀...

14 楼 lipeixin 2010-10-08  

我这发不了连续的帖子,发了几个,大家辛苦,累个眼睛看下

13 楼 lipeixin 2010-10-08  

综上分析:刀软件的生产要考虑如上几部分,结合自己的情况来生长,

通过我的分析:是否可以发现,刀软件的生产并不是一件简单的事情,到软件的生产一定要有科学的研究,IT的高智力劳动体现出来了,所以你人才一直很重要,
当我很多年前,听到一个新闻,国内购买oracle软件的时候,真正的软件可能一张光盘就够了,
可是广客户说明书等就有几十公斤重,用了好几个箱子,密密麻麻写了估计几十万资料
我就明白了客户的设计是如何才能在市场上立足的,是如何成为大家模仿也模仿不了的,因为你没法做到别人那样的程度,
所以我们就一致在口水战,缺只是一点点的几句话,给出我对刀软件的一点分析,大家也可以看出,生产一个刀软件需要很多的基础研究资料,基础研究特性,不管platform还是

12 楼 lipeixin 2010-10-08  

从以上分析能得出客户和我们的四种情况考虑,由于篇幅没时间每种情况考虑,

具体的能力对应的具体的工具, 刀

刀软件是什么,基于我们对杀鸡业务的理解和对行业的认识,我认为刀软件至少有两个部件
一个是刀柄,
一个是刀刃

刀柄可能是任何材质,任何形式
刀刃可能是任何材质,任何形式,

刀柄可以分解成塑料,木制,不锈钢
刀刃可以是不锈铁,不锈钢

刀柄和刀刃以某种插槽结合,可以是固定形式,也可以是可拆卸形式,

11 楼 lipeixin 2010-10-08  

到了这里,问题又分成两个关键点.
1 客户要的是什么.
2 我们能给客户什么

讨论就此开始:

我的设计:
1 客户要刀,
其实分析出上面这些东西,发现客户并不是要刀软件,客户要的是杀鸡,杀牛的能力,注意是能力,不是工具,工具只是能力的具体表现(如果你能提供意念杀鸡,杀牛也是可以的,只不过这个属于过度设计,客户没有意念杀鸡的需求,也很难在本世纪提出这个需求)

2 我们能提供刀软件 ,我们提供的其实是一种效率,客户因此赚了钱,才会用我们的刀软件,否则客户就自己拔毛,用铁片杀鸡,杀牛了,所以为了让客户能用我们的刀软件能赚到钱,我们要设计好刀,一切以这个目的,
客户可能有钱,要我们重新设计刀,
客户可能没钱,要我们改改就好了
我们可能只给这一个客户做刀,我们就按照客户的要求做就好了
我们可能给很多客户做刀,我们要有自己的考虑.

10 楼 lipeixin 2010-10-08  

软件工程毕竟和盖大厦不一样,大厦盖好了,客户最多不满意,局部细节修改修改,不可能让你把大楼从竖的修改成横的,也不会让你把大厦推倒重新建,
软件就不一样了,就算让客户全程参与软件设计,最后客户可能还是有这样那样的需求,不管合适不合适,反正要求你加入到系统中,最后反正实现功能就可以了,导致最后软件乱七八糟,什么东西都有.

还是拿刀来说我的设计想法:
客户要刀这个软件,他说了他要它来面对杀鸡这个业务,我们是生产刀软件的公司,
客户掌握着杀鸡业务的发展和扩展,我们掌握着刀软件的提供,我们的刀软件可以帮客户提高杀鸡效率,客户喜欢
客户一年没用刀软件只能杀10只鸡,用了我们刀软件可以杀100只鸡.
客户想赚更多的钱,扩展业务要开展杀牛业务,要我们继续提供刀软件,
开始到了十字路口,我们面临几个个选择
1 把我们的刀软件重新设计,把刀设计成既可以杀鸡又可以杀牛
2 重新生产刀软件,只能杀牛

1 的问题是客户要重新适应刀的使用,客户麻烦,万一以后可以又要杀别的,我们又修改修改刀软件,我们麻烦
2 的问题是客户要重新买刀,提高了很多费用.

9 楼 lipeixin 2010-10-08  

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

treblesoftware 写道

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

</p>
<p> </p>

8 楼 darwintest 2010-10-08  

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

7 楼 skyuck 2010-10-08  

大巧若拙，大道至简

6 楼 七月十五 2010-10-07  

有个词叫“重构”

5 楼 wandou 2010-10-07  

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

4 楼 fredchen 2010-10-07  

对基于重构的演进式设计，我也比较喜欢
不过对于文中所说的“最简单的才是最好的”，就不是很赞同
首先，“简单”这个词更多的是人主观的看法，缺少客观的衡量标准，至少文章中没有说，只是空泛的和抽象的形容了一下，这样就容易变成“谈玄”，虽然听上去很有道理，但没有实质的帮助。而且，所谓“真正的高手是手中无剑”，也只是武侠小说里的想象，缺乏现实基础。实际情况是，拿刀的一般还是比空手的更有威胁，拿枪的就更不用说了。
其次，“最”简单的也未必是最好。爱因斯坦的名言里有一句，“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等）的意见，然后结合自己的实际情况，通过不断的实践和思考，应该能大大提高对设计的审美能力和控制能力，设计出较为理想的系统

3 楼 treblesoftware 2010-10-07  

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

2 楼 beneo 2010-10-07  

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

1 楼 raymondlueng 2010-10-06  

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