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

<<== 上一节

＝＝＝＝＝

二、哪些是现象，哪些是答案，而哪些才是本质？

＝＝＝＝＝

Brooks 在 1961 年至 1964 年间，主持与领导了被称为人类从原子能时代进入信息时代标志的 IBM/360 。十余年后，在 1975 年，他将历年来所写的有关软件工程和项目管理方面的文章汇集成书，这就是《人月神话》。无疑的，《人月神话》是 Brooks 十年中对 IBM/360与操作系统OS360等项目的不断反思的结果。

而在我看到 Brooks 这些言论的时候，我并没有为它们所震惊。我所叹服的是 Brooks 在 30 年前便具有这样深远的思想。可以想见，对于 30 年前的黑暗时代，这些思想无疑是明灯和烛火。

（你有否打算用十年来思考一个问题呢？）

但这些在我看来，还只是“现象”。 Brooks 的持续思考也是现象，所述的言论也是现象。我们既不能因为其过程，也不能因为其结果而坚信这些观点：在决定全盘接受之前，至少要看清楚盘子里的东西。

我大概地统计了一下第 18 章列出的列表，其中：

章	现象	答案	本质	章	现象	答案	本质
1	3			9	7	7	2
2	10	1	1	10	7	4	1
3	3	3		11	21	6	2
4	3	4	1	12	15	3	1
5	3	2		13	13	4
6	3	5	1	14	13	4	1
7	5	14	2	15	9	5	1
8	10		1	统计	62%	31%	7%

列表中分出了三类：现象、答案和本质。通常我们总是能给出“答案”，但未见得触及“本质”。例如街口的乞丐向我伸出手来，我给了他十元钞票，我给出了解决了他伸手（这个问题）的答案，但没并有触及他伸手的本质：饥饿；更未能触及整个事件的本质：贫穷 ( 或者懒惰 ) 。另外，在标注成“现象”的项中，有一部分是包括某种现象的成因的。我最开始分析时，有“原因”这个分类，但后来发现原因其实也是一种现象，所以我合并了它们。

对“现象－答案－本质”的分析存在主观的成分，因此你可以重做这个实验。但我建议你谨慎使用“本质”这个标签。至于其它两种，即使你混淆了，（在接下来的讨论中）也不是至关重要的——尤其是现在，很多 Brooks 先生曾经给出的答案已经变成了思考同类问题的现实现象。

你可以在工程中应用这些既有的答案。但是无论这些“解／答案”看起来如何合理，如果脱离它本质上讨论的对象，那么就可能不是正确的解。而另一方面，如果作者的逻辑足够清晰，那么他提出的“解／答案”必然是围绕着某些本质的东西。在上面的列表的分析过程中，我只看到这样的几点本质：

本质含义	原文	注
项目在定义阶段就发生了错误	2.6 我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。
概念不完整＝定义不明确＝无法实施	4.1 “ 概念完整性是系统设计中最重要的考虑因素 ”	注 1
形式化会带来精确的定义	6.3 出于精确性的考虑，我们需要形式化的设计定义，同样，我们需要记叙性定义来加深理解。
组织是交流（沟通）的结果	7.1 巴比伦塔项目的失败是因为缺乏交流，以及交流的结果——组织。
组织的目标：减少必要的交流和协作量	7.16 团队组织的目标是为了减少必要的交流和协作量。
小型程序与大型程序不同	8.2 构建独立小型程序的数据不适用于编程系统项目。
私利性是本质问题	9.6 在大型的团队中，各个小组倾向于不断地局部优化，以满足自己的目标，而较少考虑队用户的整体影响。这种方向性的问题是大型项目的主要危险。	注 2
数据表现形式是编程的根本	9.16 更普遍的是，战略上突破常来自于数据或表的重新表达。数据的表现形式是编程的根本。
项目经理的基本职责	10.9 项目经理的基本职责是使每个人都向着相同的方向前进。
产品交付的关键是质量的保障程度	11.7 “ 开发人员交付的是用户满意程度，而不仅仅是实际的产品。 ” （ Cosgrove ）	注 3
用户需求变化的根源	11.9 软件产品易于掌握的特性和不可见性，导致了它的构建人员（特别容易）面临着永恒的需求变更。
某些计算机资源不能总是方便的得到	12.4 目标机器的使用需求量是一种特殊曲线：刚开始使用率非常低，突然出现爆发性的增长，接着趋于平缓。	注 4
里程碑的性质／定义	14.4 里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。
程序＝用户认识＋机器认识	15.1 对于软件编程产品来说，程序向用户所呈现的面貌与提供给机器识别的内容同样重要。

注 1 ：这里“精确定义”是本质，形式化只是答案。

注 2 ：对组织中的个体或组织的局部来说。

注 3 ：产品问题不是本身的“完成度”的问题，而是用户可感受到的质量问题。

注 4 ：书用例举的是“调试环境和目标系统”，但可以引申到例如“目标用户”或者“客户现场”。

我们应该清楚：现象之存在与是否被发现无关。例如苹果从树上掉到地上是现象，你看见这个现象也并不体现你的伟大，你四处大叫“苹果掉地上了”会被人当成疯子。而牛顿没有被人（因此）看成疯子的原因：现象只是引起了他的注意，而探究到“本质”才是关键。

所以上表列出的“ 62% 的现象”只是 Brooks 从四十年前就好心的提醒我们：看啦，快看看这些奇怪的现象，你难道不觉得它们奇怪么？于是，我们开始关注这些，并把它们当成关注的焦点。我只能因此承认 Brooks 是一个醒客，但这并不表明“陈述现象”，就等于告诉了我们什么真理。

接下来我们讨论“ 31% 的答案”。

下一节==>>

杀不死的人狼——我读《人月神话》（二）相关推荐

杀不死的人狼——我读《人月神话》（四）
<<==上一节＝＝＝＝＝四.没有银弹,或人狼杀不死＝＝＝＝＝人狼这个动物很奇怪,皮肉坚实还是自疗系的,所以要么砍它不动,要么杀它不死.这种动物如同习得(传说中的)金钟罩功夫,刀枪不 ...
杀不死的人狼——我读《人月神话》（五）
<<==上一节＝＝＝＝＝五.从广义工程到狭义工程＝＝＝＝＝现在我们回到一个实际的问题上:工程的本质需求是什么?如果我问一千个人工程的本质,可能会得到一千种答案.因为大家离本质的东西 ...
杀不死的人狼——我读《人月神话》（四） 1
2007年03月15日 02:11:00 >>==上一节＝＝＝＝＝四.没有银弹,或人狼杀不死＝＝＝＝＝人狼这个动物很奇怪,皮肉坚实还是自疗系的,所以要么砍它不动,要么杀它不死.这种 ...
杀不死的人狼——我读《人月神话》（一）
＝＝＝＝＝前言＝＝＝＝＝在这与这段文字之前,我已经阅读过种种关于<人月神话>的文字.评论者既有刘天北这样的美食家,试图在书页中夹点胡椒面以慢慢品味,为了表现食客特有的风格,他的书页都 ...
杀不死的人狼——我读《人月神话》（三）
<<==上一节＝＝＝＝＝三.<人月神话>是预言了未来还是控制了未来? ＝＝＝＝＝事实是:我们现在的很多工程知识,--无论是从书上看到的,还是从实践中体验到的--大多未曾 ...
没有银弹-读《人月神话》重点摘录
2019独角兽企业重金招聘Python工程师标准>>> 作为软件工程的经典著作,<人月神话>的主要贡献是对软件开发过程的几个重要关键点,提出了独到的见解. ...
人月神话——我从绝望中读到了希望
<人月神话>是我在入职培训时被被培训员屡次提及并且奉为神话的一本软件工程类书籍,当时的培训里有一个下午的课程专门来讲"银弹"这件事儿,当年初入此行,听个懵懵懂懂.最近被 ...
也读《人月神话》：没有银弹的软件工程
一.关于人月神话这本书记得在上大学的时候,就经常听学长和老师讲起<人月神话>,但是却一直没有阅读.记得当时一听到这个书名,还以为是个神马科幻类别的书,结果是个软件工程方面的书籍.这本书是 ...
读《人月神话》有感2
人月神话的核心法则:概念完整性和架构师.Books认为,一个整洁.优雅的变成产品必须向它的每位用户提供一个条理分明的概念模型,这个模型描述了应用,实现应用的方法以及用来指明操作和各种参数的用户界面使用 ...

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

杀不死的人狼——我读《人月神话》（二）相关推荐

最新文章

热门文章