上一篇：[Perl]高级Perl编程学习笔记 - 下一篇：《代码大全2》读书笔记(2) – 需求分析checklist(zz)
版权声明：可以任意转载，但转载时必须标明原作者charlee、原始链接http://tech.idv2.com/2009/02/11/code-complete-2-memo/以及本声明。
今天开始阅读《代码大全2》。这本书已经在我的书架上放了整整一年半的时间，现在下决心要将它读完。
今天阅读的是第1章～第3章的一部分。主要介绍的是软件构建的基础。
何谓软件构建？通常，软件构建是指详细设计、编码、单元测试这几个过程， 它占据了整个软件开发过程的30%～60%的时间。小型项目可能会省掉需求分析，时间紧迫的项目可能会省掉测试， 但构建的这几个过程是必不可少的。
但是，这并不是说其他过程都可有可无。软件产品的质量是设计出来的，而不是测试出来的。 测试只能告诉你，软件是不是符合设计要求，但如果设计本身偏离了方向，那么测试就无能为力了。 就像你拿着QQ的图纸造汽车，就算你再怎么测试，得到的也只不过是辆最好的QQ，而绝对造不出宝马。 最初的需求分析和设计，能保证你在做正确的事。就像盖房子， 移动一堵墙的成本远比移动图纸上一条线的成本大得多。
有时，设计上的一念之差，就会造成实现和维护上的大麻烦。我设计过几个系统， 有好的，也有相当糟糕的。曾经做过一个网站，大家在网站的整体架构上花费了很大的心思， 于是后来的项目进展得很顺利，我们提前完成了任务，而且质量相当有保证。 而另外一个小程序，当初设计时由于我的一点点懒惰， 结果每次版本升级时都要花费好几天的时间去修改代码实现，简直是噩梦一样。
还记得这张图吗？ 做了这么多年软件，现在总算有一点理解了。
题外话：其实，大厦、别墅和狗窝的建造方法是不一样的， 软件项目的特点多种多样，我们也不应该拿着一成不变的过程去做所有项目。 比如几十、上百人月的大中型ERP项目，需求定义也相当完备，按照瀑布式开发当然没有问题。 但对于几个人月、需求定义不明确的小项目，瀑布式是否合适呢？
切身体会：最近的一个项目，规模只有四人月，但最初客户的需求并不是很明确。 但我们仍采用了瀑布式，于是按照概要设计→详细设计→编码的过程一路走下来， 结果在编码接近尾声时，客户提出了新的要求，我们不得不返工到概要设计上， 浪费了许多人力物力。或许，这样的项目用原型法更为恰当吧。
2009-02-13 09:39
@ngok 是的，但问题是，我只能在瀑布过程中去控制质量，而客户也只认可这一种方式。如果用敏捷开发或极限编程，怎样才能控制质量呢？
2009-02-13 16:41
按客户的认同，在瀑布原则上作敏捷剪裁。你现在的情况是瀑布过程会了，从敏捷中拿出一些特性实施一下，让客户能了解成本。选择最优成本的方式去开发。
2009-02-13 20:08
@xds2000 谢谢！回去找找敏捷方面的资料看看
上一篇：[Perl]高级Perl编程学习笔记 - 下一篇：《代码大全2》读书笔记(2) – 需求分析checklist(zz)
2009-02-13 02:58
小规模而需求不明确的项目可以尝试采用敏捷开发（Agile software development）甚至是极限编程（Extreme Programming）来实现。
当然我也没试过。