《构建之法》第五章 团队和流程

摘至 邹欣《构建之法》一书，以作学习之用

写了再改模式（Code-and-Fix）

史蒂夫·迈克康奈尔（Steve McConnell）在这里提到了不少开发流程。第一个提到的开发流程——Code-and-Fix

这个流程也有好处，不需要太多其他准备或相关知识，大家上来就写代码，也许就能写出来，写不出来就改，也许能改好。当面临下面的任务时，也许这个方法是有用的。

• 只用一次”的程序
• 看过了就扔”的原型
• 一些不实用的演示程序

但是，要写一个有实际用户、解决实际需求的软件，这个方法的缺点就太大了。

---

瀑布模型（Waterfall Model）

当软件行业还在年幼的时期，它从别的成熟行业（硬件设计，建筑工程）借用了不少经验和模型。在那些“硬”的行业中，产品大多遵循 [分析→设计→实现（制造）→销售→维护] 这个流程。由于在“硬”行业中产品一旦大规模生产，要再返回去修改时就非常困难，甚至是不可能的。因此这个模型描述了单向的、不可逆的生产过程

在设计大型系统时，要做相邻步骤的回溯，解决上一阶段未能解决的问题：又如，温斯顿指出，要让产品成功，最好把这个模型走两遍，先有一个模拟版本（Simulation of FinalProduct），在此基础上收集反馈，改进各个步骤，并交付一个最终的版本

用户的及早介入、讨论、复审是很重要的。他建议：Customer involvement shouldbe formal, in-depth, and continuing.他也提到在这个模型下文档的重要性

尽管狭隘定义的瀑布模型有这样那样的问题，可它还是一个反映人类解决问题思路的常用模型
1. 它在软件工程中的局限性在于：

• 各步骤之间是分离的，但是软件生产过程中的各个步骤不能这样严格分离出来

• 回溯修改很困难甚至不可能，但是软件生产的过程需要时时回溯