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

这篇文章发表于我的博客 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最适宜用在这种地方。当然设计文档也可以放在别的地方。

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

貌似KISS 和灵活性并不矛盾吧。事实上我认为不必要的复杂度和过度设计是灵活性和可扩展性的大敌。

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

楼主的感悟非常有道理。但在有些时候是不符合国情的，就像corejava5 所说的，需求变更非常大的情况在某些行业里还是有的。

至少第二点我非常的认同，如果不清楚自己工作怎么干，请分解。自顶而下，逐级细分，这个任何一个传统软件工程书里都会说的老掉牙的理论，但是我周围的小伙子们总是不自觉地去避免这么作。

1，2两点确实是非常重要的，也做工作的基础。也较容易掌握。第3点，说起来容易，但做起来却很难，是需要很丰富的实战经验才能体会到的。第4点，我暂时还没做过，不过也想学习下。

有收获。

收藏了。

但是有疑问。就是第三条规则，KISS。 Keep It Simple Stupid。

模式、重构、分层真的是“无知下的自虐”吗？

我也说一下我的经验.
1.要有技术储备,不要盲目的应用不熟悉的技术.
2.设计阶段,可以不精细到方法,参数级别,但是流程一定要细化.千万不要糊弄自己.
3.层与层,块与块之间的接口方法与对象预先定义清楚.这步做好了,就可以做到把一个大项目分成N个小项目,否则真不要分那么多层和块了,因为会把一个大项目变成一个更大的项目.

严重同意！