设计与开发的五条原则–六年真谛

这篇文章发表于我的博客 http://blog.feihoo.com/archives/388 。
但是希望各位拍砖，就贴到这里了。
---------------------------------------------------------------------------

从2004年初（大学二年级第二学期）加入学校就业信息网站，靠写代码获得第一笔收入，迄今已经将近六年。

第一条原则，首先弄清你的问题是什么。这一条规则无论怎么强调都不过分。在《Programming Pearls》第二版的开篇，Jon Bentley 讲的就是，首先弄清你的问题是什么！ 在你没有详细、明确地定义好你的问题之前，你所做的大部分工作只产出废物。这些年，曾经的最头疼的事，就是经常搞了一大堆东西，累死累活，甚至加班加点，最后总才发现很多事情偏离了目标。但这样的事情，总是在周围一遍一遍地发生。

  一个工程师，如果在接到一个问题时首先不是尽可能挖到细致的资料，定义问题，并向了解问题的人去反馈，详细讨论问题的定义。虽然问题定义不是那么容易，但不首先定义好问题，那就是不合格的工程师。

  还有很多原则，大抵都是这个原则的派生品。

第二条规则，弄清你要干什么，以及哪些先干，哪些后干，哪些根本就不需要干。说白了，就是把问题分解，列个表，排个先后顺序。这是大部分程序员最蹩脚的部分。高效的本质不是捧着ThoughtWorks那本《卓有成效的程序员》，而是我这条原则。我对Joel的书里印象最深刻的就是有关用Excel列任务列表的部分。

  这条仍然是如此重要，以致于著名的YAGNI, (You ain’t gonna need it ）仅仅是一条推论而已。

   当然，区分的标准是什么？It depends. 但是最重要的参照是，怎么做你能获得最大产出？也许你会在所谓的扩展性、适应需求变化与可工作的代码，用户的需求之间抉择。 最重要的还是可工作的代码，能够按时 ship the beta!

  记住，先列出来要干什么；然后分清先后顺序，然后淘汰那些可以不干的。

第三条规则，KISS。 Keep It Simple Stupid。用郭靖和杨过来比喻，代码要像郭靖一样用最简单直接的方式强壮地工作，不需要太多的波折。你的程序要是像杨过的人生那么复杂、聪明，早死翘翘了。你的程序要简单强壮地干活，思想越简单越好，功能和特性越少越好。

   这一条对于设计是至关重要的，浮躁的程序员们经常要在架构设计中引入模式、分层，又或者是绚丽的Ajax效果之类，完全是无知下的自虐。我也是好些年后才明白这条道理，直到后来开始使用Unix下的那些让无数人着迷的工具，才真真地看到了这条规则的巨大威力。

   要特别澄清一下，KISS 与你的程序是否好用，是否易于复用，不但不矛盾，而且是相辅相成的。你要知道的只是你的程序应该做什么，然后努力做好。借用《Programming Pearls》开篇里法国作家兼飞机设计师的话：：“设计者确定其设计已经达到了完美的标准是不能再减少任何东西”。

第四条规则，一键集成和适当的自动化测试。这条不多说了，在有条件的情况下做会受益非浅。

其他还有一些很有名的原则，例如 DRY （Don’t Repeat Yourself)， 也许是因为一开始我就懂得了这个道理（尤记得大学的时候把ASP代码提取函数，封装Head和Foot，将写HTML Table的封装成方法来根据不同的数据集打印，好傻。），感触没那么深。

六年了，好快。

=============================================================
(Update 2009-12-22)
写完以后觉得要考虑补上的，思考几日后觉得必须补上的第五条。

第五条： 一定需要且只需要数页简单明了的设计说明书。

这个设计说明最好不用word，最好是放在源代码下的html或者txt格式。简单粗线条的UML最适宜用在这种地方。当然设计文档也可以放在别的地方。

评论

35 楼 piao_bo_yi 2010-01-12  

A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.

—Douglas Adams

34 楼 yg84 2010-01-06  

赞成KISS。更加赞成不能盲目分层。将项目复杂化。复杂和可扩展性并不成正比的。

33 楼 it.go 2009-12-31  

我个人的经验，程序员不仅仅是写代码。更多是应对需求变化。楼主所说的都是理想情况，反正我是没有遇到过一次这样的情况，需求清晰，无变更，稳定。。我好渴望这样的项目。

32 楼 evilseed 2009-12-31  

引用

有时候连甲方都不知道要具体做什么东西，只知道要做大致的东西，让你替他想，等你做出东西后，他在看，再提出具体的需求，往往大相径庭…………

这个可以用界面原型去克服。
大概的流程是客户提出初步需求后，根据初步需求画出界面原型。
用界面原型和客户讨论详细的需求。
直到达到客户满意的需求为止。

31 楼 抛出异常的爱 2009-12-27  

引用

    其实问题就发生在我们很多时候不能去确定作什么和不作什么。哈哈，有时候有句话行也得做，不行也得做.....确实经常发生的。

小公司项目经理的经验就比较重要了。
他们相当于本行业的需求库。
对于一些看起来有道理
但最后会废掉的需求也很了解
 

引用

哈哈，在这方面你比我威猛。其实最关键的是，很少有项目能真正和真正用户面对面的。

现在的开发方式很少有开发人员与客户交流的
我只看见布置时，或维护团队能达到你说的状态

引用

其实免费的蛮多，不过还得要专人来搞

花钱不花钱其漂没成本不一样。
最好还是公司花钱来提高漂没成本
我之前的公司我在时有junit
我走之后没有几个月
我以前作的努力就漂没了

30 楼 yilong511 2009-12-26  

这些很多人都知道，但是做起来就不是那简单了。
很多时候，需求是不断变更的。
退一步讲，什么都变，纯技术性的细节，也只有在不断开发中才会发现问题，
而这个时候，有的人因为暂时的时间关系会接着继续开发下去，有的人对代码进行行整合。。
没有哪个强人可以，把整个项目的共用性代码一次开发出来，并发给整个项目小组进行约定呵。。

29 楼 凤舞凰扬 2009-12-26  

引用

定义是设计过程.
把人类的思考变成固化的过程.
如果人类没思考过这种方式
那么这样的软件至少你我是作不出的.
定义最大特点是
1.作什么(人类概念)
2.不作什么(技术,时间,资源限定)
3.测试方式(开发人员所需要的完成标准,比如美工画出来的纯html-demo,)
以上其实也成为kiss的

    其实问题就发生在我们很多时候不能去确定作什么和不作什么。哈哈，有时候有句话行也得做，不行也得做.....确实经常发生的。

引用

我也是作这行业出来的.
怎么会没发现呢?
如果客户不想就要逼着他们想
跟着他们寸步不离
榨取他们的工作时间......
所用的极端方式没见过
也都听说过.

   哈哈，在这方面你比我威猛。其实最关键的是，很少有项目能真正和真正用户面对面的。

引用

有时公司花点钱买个好点的平台是最经济的.
我公司有几个这样的平台.
学习成本比开发成本低很多.

  其实免费的蛮多，不过还得要专人来搞

引用

用手画出来时讨论时需要的成本更少...
一块玻璃, 一只笔.
大小限定的面积
可以让很多不必要的东西不体现在图上面
由于合作开发会有小的交流(非全体的会议)
可以从图上看出你需要交流的人是谁

每个图中文字最多的地方是争议最大的地方.
(文字少的大家都理解不用再讨论)

   所以嘛，你上面说的应该是开会才更恰当一些。设计说明书其实并不只是为了方面当前开发人员的讨论，更多地是为了知识的积累，为了以后的开发人员能够比较容易回顾和理解。

28 楼 抛出异常的爱 2009-12-26  

凤舞凰扬 写道

引用

没定义过的东西就不要开发.
变更的话.....
就在简单的东西上重作
也比在复杂系统上修改要快的多.

  这话就不对了。这么一来，就不存在任何创新了，任何东西都是定义过都是清楚的。再说，开发与不开发其实已经脱离了技术人员的角度了。真正做事的方式是应该将复杂的事情分离，解构成多个部分，先从清晰的部分入手，而不是0，1的关系。当然了，从这个角度讲，其实我相信我们的意思也是相同的。

定义是设计过程.
把人类的思考变成固化的过程.
如果人类没思考过这种方式
那么这样的软件至少你我是作不出的.
定义最大特点是
1.作什么(人类概念)
2.不作什么(技术,时间,资源限定)
3.测试方式(开发人员所需要的完成标准,比如美工画出来的纯html-demo,)
以上其实也成为kiss的

凤舞凰扬 写道

引用

一对于这点
应该是哪些必须作,只作最必须作的
这东西一定是客户明确提出的东西.
只有客户最需要的东西
变更才会最少.....
因为这个概念已经在他的脑子里review多次了
明确的点多,模糊的点少.
呼之欲出

   看来是你没有见过20个需求有18个是must have的情况了。其实谁都不知道客户最需要什么，连客户自己也不知道。千万不要指望客户能告诉我们准确的东西。敏捷的一个最基本的思路其实就和计算机图形学中的逼近算法一样。小步骤，频繁的发布，频繁地与客户交互，理解每个步骤的偏差，不停地调整。

我也是作这行业出来的.
怎么会没发现呢?
如果客户不想就要逼着他们想
跟着他们寸步不离
榨取他们的工作时间......
所用的极端方式没见过
也都听说过.

凤舞凰扬 写道

引用

kiss是指概念上的少.
设计1->code->test->变更->回到设计2
在变更时拷贝的成本变的巨大无比

太简化的代码在二次设计时
你要用100倍的时间去找到原先的设计需求.
再用1份时间去重新设计.
把这一百份的设计时间
放在分模块设计上吧.

ajax效果如果是需求
那么一定要使用
以前不用是由于技术上达不到
现在技术上能达到需要就要上

   讲得非常对，我很赞成。其实正因为这样，这种概念上的KISS往往就成为了一个模糊的标准，成为了去推卸，去逃避的借口了。正如我对楼主那句当什么都不能减的时候就是最好的观点的不赞成。真正的KISS，是它本身完成了一个清晰的事，但是它有足够的空间去扩展，去补充。

凤舞凰扬 写道

引用

个人经验大多数人都会折在这上面....
这点远比看起来更复杂一些.
成本更高.
已经大于一个程序员的
最大劳动输出可能的了.
必须要有团队共同积累.
当然这个可以慢慢完善.
如果想单干不是太现实.

   说得好，建立自动构建以及简单化的自动化流程，是团队的工作，更是团队积累的工作。

有时公司花点钱买个好点的平台是最经济的.
我公司有几个这样的平台.
学习成本比开发成本低很多.

凤舞凰扬 写道

引用

开发时的设计说明书最好可以手绘.
不要用电子档
太不KISS了

   如果把发字改成会字，我是赞同的。不太清楚设计说明书手绘指什么？用笔？然后扫描？ 如今做IT的还用纸质文档来保存信息啊？注意环保......

用手画出来时讨论时需要的成本更少...
一块玻璃, 一只笔.
大小限定的面积
可以让很多不必要的东西不体现在图上面
由于合作开发会有小的交流(非全体的会议)
可以从图上看出你需要交流的人是谁

每个图中文字最多的地方是争议最大的地方.
(文字少的大家都理解不用再讨论)

27 楼 凤舞凰扬 2009-12-25  

引用

没定义过的东西就不要开发.
变更的话.....
就在简单的东西上重作
也比在复杂系统上修改要快的多.

  这话就不对了。这么一来，就不存在任何创新了，任何东西都是定义过都是清楚的。再说，开发与不开发其实已经脱离了技术人员的角度了。真正做事的方式是应该将复杂的事情分离，解构成多个部分，先从清晰的部分入手，而不是0，1的关系。当然了，从这个角度讲，其实我相信我们的意思也是相同的。

引用

一对于这点
应该是哪些必须作,只作最必须作的
这东西一定是客户明确提出的东西.
只有客户最需要的东西
变更才会最少.....
因为这个概念已经在他的脑子里review多次了
明确的点多,模糊的点少.
呼之欲出

   看来是你没有见过20个需求有18个是must have的情况了。其实谁都不知道客户最需要什么，连客户自己也不知道。千万不要指望客户能告诉我们准确的东西。敏捷的一个最基本的思路其实就和计算机图形学中的逼近算法一样。小步骤，频繁的发布，频繁地与客户交互，理解每个步骤的偏差，不停地调整。

引用

kiss是指概念上的少.
设计1->code->test->变更->回到设计2
在变更时拷贝的成本变的巨大无比

太简化的代码在二次设计时
你要用100倍的时间去找到原先的设计需求.
再用1份时间去重新设计.
把这一百份的设计时间
放在分模块设计上吧.

ajax效果如果是需求
那么一定要使用
以前不用是由于技术上达不到
现在技术上能达到需要就要上

   讲得非常对，我很赞成。其实正因为这样，这种概念上的KISS往往就成为了一个模糊的标准，成为了去推卸，去逃避的借口了。正如我对楼主那句当什么都不能减的时候就是最好的观点的不赞成。真正的KISS，是它本身完成了一个清晰的事，但是它有足够的空间去扩展，去补充。

引用

个人经验大多数人都会折在这上面....
这点远比看起来更复杂一些.
成本更高.
已经大于一个程序员的
最大劳动输出可能的了.
必须要有团队共同积累.
当然这个可以慢慢完善.
如果想单干不是太现实.

   说得好，建立自动构建以及简单化的自动化流程，是团队的工作，更是团队积累的工作。

引用

开发时的设计说明书最好可以手绘.
不要用电子档
太不KISS了

   如果把发字改成会字，我是赞同的。不太清楚设计说明书手绘指什么？用笔？然后扫描？ 如今做IT的还用纸质文档来保存信息啊？注意环保......

26 楼 xuby 2009-12-25  

所谓设计，就是解耦。按照自己的项目/产品实际情况，而不是3层、N层理论来划分解耦后的模块。保证这些模块在自己的项目/产品中逻辑上符合实际项目情况的独立，而不是按照某种理论看起来他们很独立。
灵活性只需要处理那些在有限可见未来真的会有实际扩充的情况，而不是自己臆想的扩充情景。

25 楼 xuby 2009-12-25  

high_java 写道

KISS,当你不知道你后面的的需求变化有多大的时候，还是保证你的设计具有灵活性才好，而不是Keep it Simple,Stupid

好多时候是越KISS，越灵活，真的。
“超级灵活”(或者叫过度设计)带来的复杂性，有时反而抵消了“灵活”。有点绕口，不过是血的教训。

24 楼 luihuilang 2009-12-25  

怎么兄弟的经历实在跟我太一样啦，在学其间也是用ASP做就业信息网赚了自己的第一份工资。好激动哦，记得我拿了钱就和女朋友出去撮了一顿大餐。好Happy.好满足。

23 楼 抛出异常的爱 2009-12-25  

凤舞凰扬 写道

引用

第一条原则，首先弄清你的问题是什么。这一条规则无论怎么强调都不过分。在《Programming Pearls》第二版的开篇，Jon Bentley 讲的就是，首先弄清你的问题是什么！ 在你没有详细、明确地定义好你的问题之前，你所做的大部分工作只产出废物。这些年，曾经的最头疼的事，就是经常搞了一大堆东西，累死累活，甚至加班加点，最后总才发现很多事情偏离了目标。但这样的事情，总是在周围一遍一遍地发生。

  一个工程师，如果在接到一个问题时首先不是尽可能挖到细致的资料，定义问题，并向了解问题的人去反馈，详细讨论问题的定义。虽然问题定义不是那么容易，但不首先定义好问题，那就是不合格的工程师。

  还有很多原则，大抵都是这个原则的派生品。

不是所有问题在一开始就能完全清楚的，XP推崇的是隐喻，说白了也就是知道问题的主要关键以及方向，而不是一开始去弄清它。等你完全弄清楚后，新问题又来了。所以此条作为原则不适合， 对待问题的关键是知道如何解构问题。

没定义过的东西就不要开发.
变更的话.....
就在简单的东西上重作
也比在复杂系统上修改要快的多.

凤舞凰扬 写道

引用

第二条规则，弄清你要干什么，以及哪些先干，哪些后干，哪些根本就不需要干。说白了，就是把问题分解，列个表，排个先后顺序。这是大部分程序员最蹩脚的部分。高效的本质不是捧着ThoughtWorks那本《卓有成效的程序员》，而是我这条原则。我对Joel的书里印象最深刻的就是有关用Excel列任务列表的部分。
  这条仍然是如此重要，以致于著名的YAGNI, (You ain’t gonna need it ）仅仅是一条推论而已。

   当然，区分的标准是什么？It depends. 但是最重要的参照是，怎么做你能获得最大产出？也许你会在所谓的扩展性、适应需求变化与可工作的代码，用户的需求之间抉择。 最重要的还是可工作的代码，能够按时 ship the beta!

  记住，先列出来要干什么；然后分清先后顺序，然后淘汰那些可以不干的。

对于软件设计，尤其是复杂的软件设计，不是很容易详细区分哪些先干，哪些后干的。当然了，清楚事情的优先级是必要的，不过，这个应该是二维关系，而不是简单的前后续关系。

一对于这点
应该是哪些必须作,只作最必须作的
这东西一定是客户明确提出的东西.
只有客户最需要的东西
变更才会最少.....
因为这个概念已经在他的脑子里review多次了
明确的点多,模糊的点少.
呼之欲出

凤舞凰扬 写道

引用

第三条规则，KISS。 Keep It Simple Stupid。用郭靖和杨过来比喻，代码要像郭靖一样用最简单直接的方式强壮地工作，不需要太多的波折。你的程序要是像杨过的人生那么复杂、聪明，早死翘翘了。你的程序要简单强壮地干活，思想越简单越好，功能和特性越少越好。
  这一条对于设计是至关重要的，浮躁的程序员们经常要在架构设计中引入模式、分层，又或者是绚丽的Ajax效果之类，完全是无知下的自虐。我也是好些年后才明白这条道理，直到后来开始使用Unix下的那些让无数人着迷的工具，才真真地看到了这条规则的巨大威力。
   要特别澄清一下，KISS 与你的程序是否好用，是否易于复用，不但不矛盾，而且是相辅相成的。你要知道的只是你的程序应该做什么，然后努力做好。借用《Programming Pearls》开篇里法国作家兼飞机设计师的话：：“设计者确定其设计已经达到了完美的标准是不能再减少任何东西”。

还好，这是规则，要是原则就会撞死许多人了。 对于设计者确定其设计已经达到了完美的标准是不能再减少任何东西“这句话最经典的反驳就是最烂的设计也是什么不能减去，你要一个苹果，它给你一大篮水果。其实真正优秀的设计是可以简单并且容易的增加东西（也就是扩展）。设计模式也好，其他也好，追求的就是重用性。KISS的目的是要程序不要将简单问题复杂化，而并非意思要将复杂问题简单化。如果纯粹一个KISS的概念，一个类，一个方法最好了，完成功能了，讲究什么重用啊，大不了再拷贝。

kiss是指概念上的少.
设计1->code->test->变更->回到设计2
在变更时拷贝的成本变的巨大无比

太简化的代码在二次设计时
你要用100倍的时间去找到原先的设计需求.
再用1份时间去重新设计.
把这一百份的设计时间
放在分模块设计上吧.

ajax效果如果是需求
那么一定要使用
以前不用是由于技术上达不到
现在技术上能达到需要就要上

PS:由于需要兼容各种机器的稳定性
所以UNIX上大多数工具只开发命令行模式的.
GUI太不稳定了.
会产生出太多的意料外的bug

凤舞凰扬 写道

引用

第四条规则，一键集成和适当的自动化测试。这条不多说了，在有条件的情况下做会受益非浅。
其他还有一些很有名的原则，例如 DRY （Don’t Repeat Yourself)， 也许是因为一开始我就懂得了这个道理（尤记得大学的时候把ASP代码提取函数，封装Head和Foot，将写HTML Table的封装成方法来根据不同的数据集打印，好傻。），感触没那么深。

这个是赞同的，因为程序员的”懒“促进了进步，促进了重用。

个人经验大多数人都会折在这上面....
这点远比看起来更复杂一些.
成本更高.
已经大于一个程序员的
最大劳动输出可能的了.
必须要有团队共同积累.
当然这个可以慢慢完善.
如果想单干不是太现实.

凤舞凰扬 写道

引用

第五条： 一定需要且只需要数页简单明了的设计说明书。
这个设计说明最好不用word，最好是放在源代码下的html或者txt格式。简单粗线条的UML最适宜用在这种地方。判断一个开发人员的设计素质如何，打开源代码，看看有没有这个文档以及这个文档的水平，就知道了。

  简单明了的设计说明书是好事，不过什么放在源代码下的html和txt最好，就有些牵强了。楼主还有本事用txt画UML？至于后续说判断一个开发人员素质如何的方式，呵呵，那apache, spring, jboss, sun等所有的开发人员都比较低劣，因为几乎没发现他们这样做。

开发时的设计说明书最好可以手绘.
不要用电子档
太不KISS了

22 楼 phpxer 2009-12-25  

引用

楼上这话我就不认同了，我们可以说任何规则都有例外，但如果原则都是可以例外，那也就是无原则....

总体上而言，此文“原则”之意，大抵是前车之辙，后车之谏的意思，并非公理之意。用“原则”是强调其重要性。日常工作中，或可提供参考，各自斟酌之。

21 楼 凤舞凰扬 2009-12-24  

引用

都不错。
任何原则都是有例外的，所谓仁者见仁，智者见智。
原则是没有错的，只有领会错，用错的人。

   楼上这话我就不认同了，我们可以说任何规则都有例外，但如果原则都是可以例外，那也就是无原则....

20 楼 bohemia 2009-12-24  

最近开会，经常说的一句话是“有道理”。。呵呵

19 楼 hatedance 2009-12-24  

都不错。
任何原则都是有例外的，所谓仁者见仁，智者见智。
原则是没有错的，只有领会错，用错的人。

18 楼 刃之舞 2009-12-24  

只对第四条有同感，其他几条，呵呵，就不发表什么评论了，不知道楼主做的项目涉及的领域都是什么方面。

17 楼 凤舞凰扬 2009-12-23  

引用

KISS 确实首先强调的当然包括不要将简单问题复杂化。不过你后面举的这个例子就是过了，与KISS没关系。所谓的追求重用性，跟KISS并不矛盾， 遵循KISS原则，则恰恰可以帮助许多总是想着重用的人们端正态度，不要去臆测重用需求，只着眼于有确实根据的需求或衍生需求。

这个非常赞同.... 不过现在啊，最大的问题就是KISS被滥用了，呵呵。

引用

放在源代码下是是词不达意，应该说是说跟源代码放在一起，通常是一起放在版本控制系统下的。 txt 格式当然不能画 UML，不过UML文件你可以放在同一目录下的了。 在文字上细究那当然无可奈何

我到也不是究你文字，只是你作为原则，让人误解了总是不好。 而对于放在版本控制下的文件，其中有个建议是最好不用二进制格式的，包括word,excel等等，因为二进制是无法进行版本识别和判断的。其实wiki比较好，在没有wiki的情况下，word其实是一个不错的选择的，因为word是可以跟踪修改记录的。所以使用html也好（其实这个并建议，html最好是自动化生成，而非人手写的文档，受格式的影响非常难以版本比较），txt也好，也只能是建议，而上升不到原则的。

   其实跟楼主说这些，只是希望大家在很多时候更多斟酌，不要轻易下决定，其实很多时候，技术也好，方法论也好，都是有适用场景的，不是么？

16 楼 Elrond 2009-12-23  

楼主是沈阳工业大学的么?....