相信这张图大家一定见过，它描述了在软件开发各个阶段，发现并修改bug所需的相对费用。 例如，一个本应在设计阶段发现的bug，如果一直到部署并开展应用之后才被发现， 那么修改这个bug所花费的代价是设计时修改的代价的470倍-880倍。
设计阶段是在选定方向，而编程则是朝着目标前进，测试就是检查有没有达到目的地。 如果最初选择了错误的方向，那么无论如何努力前进也无法到达目的地， 事后走回头路会花费更多的时间。最近在开发中几次验证了这个事实。 一次是在详细设计审查时发现了设计中的一个重大方向性错误， 如果没发现并继续编程，测试阶段再去改代码就会使得代码、测试用例等完全重做， 浪费大量时间。另外一个例子就是以前开发的一个项目， 当时没有做详细设计而直接开始编程，就等于放弃了修改bug效率最高的设计阶段， 增大了项目风险。
因此在软件开发中，最重要的阶段不是测试，而是设计（概要设计和详细设计）。 做好设计文档并严格审查，就能大幅度地减少开发风险，降低开发费用。
我曾经做过一个失败的项目。那时我对项目管理一知半解， 对于风险管理、进度管理等更是一无所知， 以致最后花费了当初几倍的人力来挽救它造成的损失。
项目概况
这个项目的策划是在11月开始的，是对现有的一个Web应用程序进行改造。 客户写了一份简单的需求说明，希望能在12/25圣诞节之前投入使用。 根据这份需求说明，我们整理出了一份功能列表， 然后估算每个功能的代码规模，发现规模大大超出期限，于是跟客户交涉， 删减了一些功能，并将发布日期定为1/26。 最后结果为服务器端3KL，客户端3KL，按照1KL/人月的保守估计， 需要6个人月，投入两个人，正好能在1月底完工。 于是项目就开始了。
阅读全文 »如何统计代码的修改规模？如果肯花钱，则能买到统计代码修改规模的专业工具。这里介绍一种利用subversion和grep组合的方法简单统计代码修改规模。下面假设程序代码中的注释有两种格式，一种以 // 开头，另一种是Javadoc格式，即
/**
* This is a function.
* @param {String} v str
*/
为清晰起见，下面的统计命令分成了几行来写。
svn diff -r4:320 # 获取rev4和rev320之间的差异
| sed -e 's/\r//g' # 删除行尾的换行符^M。Windows下必须
| grep "^+[^+]" # 取得修改部分
| grep -Ev "^+[[:space:]]*(\/\*)|(\*)|(\/\/)" # 删除注释
| grep -v "^+[[:space:]]*$" # 删除空行
| wc -l # 统计行数
