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

这篇文章发表于我的博客 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的封装成方法来根据不同的数据集打印，好傻。），感触没那么深。

六年了，好快。

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

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

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