杀不死的人狼——我读《人月神话》（三）

<<==上一节

＝＝＝＝＝ 

三、《人月神话》是预言了未来还是控制了未来？

＝＝＝＝＝

事实是：我们现在的很多工程知识，——无论是从书上看到的，还是从实践中体验到的——大多未曾脱离《人月神话》之所言。

我在开篇中说《人月神话》“是一本可怕的书”。然而我认为真正的可怕之处在于：如今只要论及工程（且不要让人认为是离经叛道），那么所讲述的一定是Brooks的这样的经验以及由此推出的观点，或者在不违背这些经验和观点上的一些具体的实作方法！我们全然不顾书中所言是现象，还是本质的推论，或者只是现象归结的一个（未必正确的）答案。尽管这些答案大多数时候都如同预期地出现在你的现实工程中：

原文	基本含义	现实
规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义，所以每条说明都必须重复所有的基本要素，所以所有文字都要相互一致。这往往使手册读起来枯燥乏味，但是精确比生动更加重要。(P46)	重复所有基本要素，以便于单个的特性可能会被抽离出来进行讨论。	RUP
将来的规格说明同时包括形式化和记叙性定义两种方式。(P46)	用形式化来精确定义，用记叙性定义来被充说明。	UML
使用实现来作为一种定义的方式有一些优点……（但）可能更加过度地规定了外部功能。(P47)	陈述实现并不是设计中规定外部功能的方法。	UserCase不应指示或暗示实现的方法。
对软件系统的体系结构师而言，存在一种更加可爱的方法来分发和强制定义。对于建立模块间接口语法，而非语义时，它特别有用……(P48)	寻求一种描述功能而不涉及实现的方法，来协助架构师陈述它们的设计。	Interface
项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。项目所有的文档都必须是该结构的一部分……(P54)	项目工作手册应当有组织、有结构地陈述项目各个方面的细节。	RUP
笨拙的文字归档工作确保了所有变更会被阅读，这正是工作手册要达到的目的。(P56)	确保变更不会丢失。	需求管理系统或任务管理系统
是因为控制序更加复杂,所以需要更多的人员？或者因为它们被分派了过多的人员，所以要求有更多的模块？是因为复杂程度非常高，还是分配较多的人员，导致花费了更长的时间？没有人可以确定……(P64)	随时关注生产率并控制它。	项目管理软件
但是只有书面计划是精确和可以沟通的。计划中包括了时间、地点、人物、做什么、资金……(P75)	以书面化的形式来制定计划，并且确保一些要素的准确性。	项目管理软件
试验性的系统必须被构建然后丢弃……(P77)	做一个原型并准备好扔掉它。	原型过程
目标上的一些变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。不但目标上的变化不可避免，而且设计策略和技术上的变化也不可避免……(P77)	为变化而做出设计。	延长设计和迭代的周期。风险评估。
流程图是被吹捧得最过分的一种程序文档。事实上，很多程序甚至不需要流程图，很少有程序需要一页纸以上的流程图。 (P107)	编程的结果产生流程图（以供讨论和分析），而不是对照着流程图进行编程。	编程的结果产生流程图（以供讨论和分析），而不是对照着流程图进行编程。
试图把信息放在不同的文件中，并努力维持它们之间的同步，是一种非常费力不讨好的事情……(P108)	文档应该与代码同步。	代码文档化。
没有银弹(P114)		所有曾被认为是银弹的东西都无情地否定了。

原文中还有许多类似的观点、现象和答案，都成为了现实工程中的既存现象。先民们所说的圣人以及通神者，皆因他们多数时候在正确地预言自己的现实。只有当这个“多数时候”变成少数的时候，先民们才会置疑圣人和通神者的能力。其实我们知道并没有预言未来的人，大多数时候是两种情形导致的假象：

• 他做出了正确的判断；
• 你主观地跟从了他对未来的设定。

后者是危险的。大师们预言了未来也就改变了未来，即便未来未必“应当”如同他所预言的那样。

 

但如果这种预言的前提不正确，那么未来必然脱离这种影响而回到它应该的状态上去。如同我们看到的另一些事实一样，有很多现象表明，我们正在回归工程本相的道路上摸索前进。我们也发现，在大多数情况下，先哲们的预言在实践中被印证着，只是偶尔“不太灵光”。下表则列出一些不同的例子：

原Brooks所述相同的例子	不同的例子	注
UML	AP：可以工作的软件重于求全责备的文档。	注1
Interface
RUP
需求管理系统／任务系统	代码走查，结对编程。 AP：人和交互重于过程和工具。 AP：客户合作重于合同谈判。
项目管理软件
质量管理／评估和工程化测量
User Case要尽可能避免指示或暗示实现的方法	测试驱动从一开始就规定表现是什么，以及如何确认它。
原型过程	迭代过程	注2
延长设计和迭代的周期	缩短周期使得变化来不及发生。
编程的结果产生流程图（以供讨论和分析），而不是对照着流程图进行编程。	不强调具体代码实现方法的、设计过程中的流程图例。例如时序图。	注3
代码文档化。	通过工具来使代码与文档同步维护。
所有曾被认为是银弹的东西都无情地否定了。	我们还是有成功的工程实践的。

注1：我例举了敏捷的一些观点，并不表明我是AP/XP的fans。AP/XP的问题另论，在这里，我只是说明存在一种不同的思想。

注2：Brooks后来承认“必须扔弃原型”是一个不太正确的观点。

注3：Brooks在这里没有犯错误，只是他所讨论的是狭义的流程图，而我们例举的时序图则更广义。

 

我们回顾上一小节，在《人月神话》中的那“31%的答案”的前提——也就是那7%的本质中，如下两项是明显存疑的（也是主要置疑）：

• 目标的本质：是大型工程，是系统项目，而不是程序
• 个体的本质：是私利性的

其实早就有人意识到个体的本质“未必全是私利的”，尊重这些个体就会带来一些效果。例如AP正是因为更尊重开发人员的个性与能力，以及相互间的合作而得到了效率的提升。

再进一步地说，既然Brooks设定了“大型工程或系统项目”这样的目标，并给出了一些答案。那么在“小那么一点点的”工程项目中，是不是这些答案就不必须了呢？例如Brooks的许多建议，对于某些目标——例如你要用为期三个月的时间开发一个的产品——就并不是很有效；或者根本无法实施——例如你的团队总共只有6个人，连“外科手术式的团队”都组织不起来。

Brooks的答案对于同样的目标，以及在他所述的“本质”未能发生改变时，还是比较有效（或有实施的可能性）。因此上述一些例外，总是在上述的“7%的本质”被否定或被改变的情况下获得的。因而我们提出的问题是“如何否定或改变”这些难以撼动的本质。然而在我看来，Brooks早已经在最佳位置上，给出了撬动它们的一个支点：

•  Brooks认为构建“独立小型程序”与“编程系统产品”是不同的问题。

Brooks讨论的编程系统产品的规模到底有多大呢？我想至少应该是以IBM 360为参考的。不过书中在引用Joel Aron（IBM在马里兰州盖兹堡的系统技术主管）的例子时说，“大型意味着程序员的数目超过25人，将近30,000行的指令”。而按照《人月神话》的数据：人均效率800指令/人年，则这个“大型项目”应该需要1.5年才能完成。此外，还需要大约一倍的人工，来负责除开代码之外的测试、管理、文档和沟通等工作。

 

好的，如果你有一个“(至少)50人，开发一年半”的项目，那么你可以先接受Brooks的答案去实践一下：起码你可以有时间来讨论工程问题，也能够组建那样规模的团队。但是，难道只有这样的“大型工程”才算得工程，而“小那么一点点”的就不算吗？现实是，我们一方面在做着“小那么一点点的”工程项目，另一方面在听着整个业界喧嚣着“为更大规模的工程”而准备的工程理论。我们总在实践Brooks的“答案”或者“预言”，而忘却这些答案的前提：

• Brooks的经验源自对IBM 360等大型项目的实践与分析；
• Brooks所述的工程是要得到编程系统产品；
• Brooks认为编程系统产品的工作量可能是独立小型程序的9倍（在实现大致相同功能的情况下）。

事实上我们现在的软件工程的发展是被驾驭了，而不是被预言了。从本质上来说，Brooks在《人月神话》中只是讨论了大型工程的实施，以及相应规模下的团队建设。而我们，便按照这样的设定来铺开了整个软件行业的工程化实施。

促成这种现状的，并不仅仅是一本书的力量，还在于商业的力量。因为只有在这样铺展开来的行业环境中，才可能有商业机会。——即使那些工程顾问与实施专家从来没有实施过“50人，开发一年半”这样的项目，只要他们能报出Brooks的名字，能谈及某些工具在应对“大型项目”中的成功经验，他们就已经成功了一半了。

为什么“敏捷”之初颇受争议？为什么敏捷对一些中小型的团队显得有效和可实施？为什么当这些争议被摆在眼前的成功平息之后，传统工程的理论家们却不忘恨恨地评上一句：那是一种不能（或难以）应用于大型工程的方法呢？！

因为如果大家都很“敏捷”，都只做比这些大型工程“小那么一点点”的工程，那么传统工程的专家们就失业了。反过来，只有把工程做大，大到“敏捷”失去了意义，而“庞大”变成了实质的时候，传统工程就可以为任何失败找到借口：看啊，Brooks就说过“没有银弹”嘛。

 

下一节==>>