今天开始阅读《代码大全2》。这本书已经在我的书架上放了整整一年半的时间，现在下决心要将它读完。

今天阅读的是第1章～第3章的一部分。主要介绍的是软件构建的基础。

何谓软件构建？通常，软件构建是指详细设计、编码、单元测试这几个过程， 它占据了整个软件开发过程的30%～60%的时间。小型项目可能会省掉需求分析，时间紧迫的项目可能会省掉测试， 但构建的这几个过程是必不可少的。

但是，这并不是说其他过程都可有可无。软件产品的质量是设计出来的，而不是测试出来的。 测试只能告诉你，软件是不是符合设计要求，但如果设计本身偏离了方向，那么测试就无能为力了。 就像你拿着QQ的图纸造汽车，就算你再怎么测试，得到的也只不过是辆最好的QQ，而绝对造不出宝马。 最初的需求分析和设计，能保证你在做正确的事。就像盖房子， 移动一堵墙的成本远比移动图纸上一条线的成本大得多。

有时，设计上的一念之差，就会造成实现和维护上的大麻烦。我设计过几个系统， 有好的，也有相当糟糕的。曾经做过一个网站，大家在网站的整体架构上花费了很大的心思， 于是后来的项目进展得很顺利，我们提前完成了任务，而且质量相当有保证。 而另外一个小程序，当初设计时由于我的一点点懒惰， 结果每次版本升级时都要花费好几天的时间去修改代码实现，简直是噩梦一样。

还记得这张图吗？ 做了这么多年软件，现在总算有一点理解了。

题外话：其实，大厦、别墅和狗窝的建造方法是不一样的， 软件项目的特点多种多样，我们也不应该拿着一成不变的过程去做所有项目。 比如几十、上百人月的大中型ERP项目，需求定义也相当完备，按照瀑布式开发当然没有问题。 但对于几个人月、需求定义不明确的小项目，瀑布式是否合适呢？

切身体会：最近的一个项目，规模只有四人月，但最初客户的需求并不是很明确。 但我们仍采用了瀑布式，于是按照概要设计→详细设计→编码的过程一路走下来， 结果在编码接近尾声时，客户提出了新的要求，我们不得不返工到概要设计上， 浪费了许多人力物力。或许，这样的项目用原型法更为恰当吧。