完美软件开发方法：逻辑链2的精彩探索

软件是一种固化的思维→思维的澄清必然是渐进的→全新软件的需求和实现必然是渐进的→单纯从开发完美软件的角度看，新软件的开发必然是要迭代的→而大多软件开发都有“新”的部分，所以根本上来讲，软件开发是迭代的。

完美的瀑布主义者认为在设计的时候要把接口都定义清楚，做的人只负责做就可以了。这并非是不能尝试的事情，我们来看一个例子。

有一个小规模的项目，大概在10KSLOC左右。为了定义清楚所有的关键接口，概要设计写了40页左右，详细设计则写到了120页左右，加上Review和修改，每页平均花了4个多小时。这就意味着在设计上总计花去了4个多人月。结果在实现的时候却发现，很多定义的接口需要进一步修改。于是项目组的任务变成了一边修改代码，一边修改文档。最终整个项目的开销达到了15个人月以上，远超出该组织的平均水平。

这个例子所体现的问题的实质是：在不知道实现细节的时候，却预先勉强定义较底层的接口。这事实上和赵括的纸上谈兵并无本质区别。很多接口的确立确实需要迭代下去，在对其职责有清楚认识后可以定义最初的接口，而后在进一步迭代中可能会做适当修正。

同类的事情可以完美地复制到需求开发之中，如果有人试图在最初阶段定义软件所有的需求细节，那么其中需要被推倒重来的部分也将占到比较大的比重。当UI被看做需求时，这类返工就会变得更为明显。

对是否应该开始迭代，其基本方法与上一节中所述相同，这里不再重复。

额外想强调的是迭代对开发提出了的两个新挑战：一个是一旦开始迭代就必须有适合的自动回归测试方法来确保软件的质量；另一个是在持续迭代的情况下如何处理各种需要产出的文档。(www.xing528.com)

●软件内部依据调用关系构成了一张彼此关联的网。线程、进程、加上各种变量的组合

使任何一个上点规模的软件的内部可能状态非常之多。

迭代的同时等于不停地对软件进行修改，而这种修改可能的影响范围并不能人为地标识清楚。这时候如果没有保证了一定覆盖率的自动回归测试，就根本没法判定新加入的代码是否会让老的代码产生“降级”。

这大概就是测试驱动开发的根本价值—越纯粹的迭代，越和测试驱动开发不可分割。否则就像高速行驶不系安全带一样，是自寻死路的做法。

●在倾向于瀑布类的模型下，文档的制作相对比较容易；在倾向于迭代的模型下，要想保证文档和实现的同步则需要对文档的粒度有一个相对比较清晰的尺度，并且组内的人要对此形成一定共识。即对什么样的东西需要文档，什么样的东西不需要文档上有一致的认识。很多项目的困境在于，现有的系统有与之相应的文档，但随着需求的逐渐碎片化，文档也有了碎片化的趋势。