人月神話與沒有銀彈摘要

簡體傳統

所有软件活动包括根本任务——打造由抽象软件实体构成的复杂概念结构，次要任务——使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。软件生产率在近年内取得的巨大进步来自对后天障碍的突破，例如硬件的限制、笨拙的编程语言、机器时间的缺乏等等

一个相互牵制关联的概念结构，是软件实体必不可少的部分，它包括：数据集合、数据条目之间的关系、算法、功能调用等等。这些要素本身是抽象的，体现在相同的概念构架中，可以存在不同的表现形式。尽管如此，仅由于它们是不同的人——而非上帝——设计的结果。

软件工程师却无法从类似的信念中获得安慰，他必须控制的很多复杂度是随心所欲、毫无规则可言的，来自若干必须遵循的人为惯例和系统。它们随接口的不同而改变，随时间的推移而变化，而且，这些变化不是必需的，仅仅由于它们是不同的人——而非上帝——设计的结果。

毕竟，我的从业背景是程序员，乐观主义是这个行业的职业病。

普遍的做法是，选择一种方法，试试看；如果失败了，没关系，再试试别的。不管怎么样，重要的是先去尝试。
- 富兰克林 D. 罗斯福1

It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something.
- FRANKLIN D. ROOSEVELT1

但是我们中的一些——那些非常固执，以致于可以认为是现实主义者的人——把它看成是清新的空气。我们终于可以将焦点集中在更加可行的事情上，而不是空中的馅饼。现在，有可能，我们可以在软件生产率上取得逐步的进展，而不是等待不大可能到来的突破。

《人月神话》的观点：是或非？（Propositions of the Mythical Man-Month: True or False？）
我们理解的也好，不理解的也好，描述都应该简短精练。
塞缪尔·巴特勒，讽刺诗
For brevity is very good, where we are, or are not understood.
SAMUEL BUTLER Hudibras

编程系统产品（Programming Systems Product）开发的工作量是供个人使用的、独立开发的构件程序的九倍。我估计软件构件产品化引起了3倍工作量，将软件构件整合成完整系统所需要的设计、集成和测试又强加了3倍的工作量，这些高成本的构件在根本上是相互独立的。

编程行业“满足我们内心深处的创造渴望和愉悦所有人的共有情感”，提供了五种乐趣：
􀂉 创建事物的快乐
􀂉 开发对其他人有用的东西的乐趣
􀂉 将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力
􀂉 面对不重复的任务，不间断学习的乐趣
􀂉 工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动，其存在、移动和运转方式完全不同于实际物体

同样，这个行业具有一些内在固有的苦恼：
􀂉 将做事方式调整到追求完美，是学习编程的最困难部分
􀂉 由其他人来设定目标，并且必须依靠自己无法控制的事物（特别是程序）；权威不等同于责任
􀂉 实际情况看起来要比这一点好一些：真正的权威来自于每次任务的完成
􀂉 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外
􀂉 人们通常期望项目在接近结束时，（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢
􀂉 产品在即将完成时总面临着陈旧过时的威胁

良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。

关于进度安排，我的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。

为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。

第二个系统是人们所设计的最危险的系统，通常的倾向是过分地进行设计。

为功能分配一个字节和微秒的优先权值是一个很有价值的规范化方法。

即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的。
出于精确性的考虑，我们需要形式化的设计定义，同样，我们需要记叙性定义来加深理解。

工作手册的使用者应该将注意力集中在上次阅读后的变更，以及关于这些变更重要性的评述。

传统的树状组织结构反映了权力的结构原理——不允许双重领导。

精炼、充分和快速的程序。往往是战略性突破的结果，而不仅仅技巧上的提高。
更普遍的是，战略上突破常来自于数据或表的重新表达。数据的表现形式是编程的根本。

对于大多数项目，第一个开发的系统并不合用。它可能太慢、太大，而且难以使用，或者三者兼而有之。

系统的丢弃和重新设计可以一步完成，也可以一块块地实现。这是个必须完成的步骤。

因此，为舍弃而计划，无论如何，你一定要这样做。

在大型的团队中，各个小组倾向于不断地局部优化，以满足自己的目标，而较少考虑队用户的整体影响。这种方向性的问题是大型项目的主要危险。

出于这个原因，广受吹捧的市场概念——支持管理人员的“完备信息管理系统”并不基于反映管理人员行为的有效模型。
“开发人员交付的是用户满意程度，而不仅仅是实际的产品。”（Cosgrove）

用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。

软件产品易于掌握的特性和不可见性，导致了它的构建人员（特别容易）面临着永恒的需求变更。
程序员不愿意为设计书写文档的原因，不仅仅是由于惰性。更多的是源于设计人员的踌躇——要为自己尝试性的设计决策进行辩解。（Cosgrove）

对于一个广泛使用的程序，其维护总成本通常是开发成本的40％或更多。

在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏。
所有修改都倾向于破坏系统的架构，增加了系统的混乱程度。即使是最熟练的软件维护工作，也只是放缓了系统退化到不可修复混乱的进程，从中必须要重新进行设计。[许多程序升级的真正需要，如性能等，尤其会冲击它的内部结构边界。原有边界引发的不足常常在日后才会出现。]

目标机器的使用需求量是一种特殊曲线：刚开始使用率非常低，突然出现爆发性的增长，接着趋于平缓。

同天文工作者一样，系统调试总是大部分在夜间完成。

自顶向下、彻底地开发一个性能仿真装置。尽可能早地开始这项工作，仔细地听取 “它们表达的意见”。
有限的数据表明了系统软件开发中，交互式编程的生产率至少是原来的两倍。

系统调试的困难程度证明了需要一种完备系统化和可计划的方法。

“项目是怎样延迟了整整一年的时间？⋯一次一天。”

一天一天的进度落后比起重大灾难，更难以识别、更不容易防范和更加难以弥补。

根据一个严格的进度表来控制项目的第一个步骤是制订进度表，进度表由里程碑和日期组成。

里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。

如果里程碑定义得非常明确，以致于无法自欺欺人时，程序员很少会就里程碑的进展弄虚作假。

进取对于杰出的软件开发团队，同优秀的棒球队伍一样，是不可缺少的必要品德。

对于大型项目，一个对里程碑报告进行维护的计划和控制（Plan and Control）小组是非常可贵的。

对于软件编程产品来说，程序向用户所呈现的面貌与提供给机器识别的内容同样重要。

即使对于完全开发给自己使用的程序，描述性文字也是必须的，因为它们会被用户－作者所遗忘。
培训和管理人员基本上没有能向编程人员成功地灌输对待文档的积极态度—
—文档能在整个生命周期对克服懒惰和进度的压力起促进激励作用。

软件系统可能是人类创造中最错综复杂的事物（从不同类型组成部分数量的角度出发）。

软件工程的焦油坑在将来很长一段时间内会继续地使人们举步维艰，无法自拔。

人类历史是一个舞台，总是上演着相同的故事。随着文化的发展，这些故事的剧本变化非常缓慢，而舞台的布局却在随时改变。正是如此，我们发现二十世纪本身会反映在莎士比亚、荷马的作品和圣经中。因此，某种程度上，《人月神话》是关于人与团队的书，所以它的淘汰过程会是缓慢的。

核心观点：概念完整性和结构师

概念完整性。一个整洁、优雅的编程产品必须向它的每个用户提供一个条理分明的概念模型，这个模型描述了应用、实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。用户所感受到的产品概念完整性是易用性中最重要的因素。（当然还有其他因素。Macintosh上所有应用程序界面的统一就是一个重要的例子。此外，有可能建立统一的接口，尽管它可能很粗糙，就像MS-DOS。）

有很多由一个或者两个人设计的优秀软件产品例子。大多数纯智力作品，像书籍、音乐等都是采用这种方式创作出来的。不过，很多产业的产品开发过程无法负担这种获取概念完整性的直接方法。竞争带来了压力，很多现代工艺的最终产品是非常复杂的，它们的设计需要很多人月的工作量。软件产品十分复杂，在进度上的竞争也异常激烈。

今天，我比以往更加确信。概念完整性是产品质量的核心。拥有一位结构师是迈向概念完整性的最重要一步。这个原理决不仅限于软件系统，它适用于所有的复杂事物，如计算机、飞机、防御系统、全球定位系统等。

盲目的功能（Featuritis）。对于如电子表格或字处理等通用工具的结构师，一个不断困扰他们的诱惑是以性能甚至是可用性的代价，过多地向产品添加边界实用功能。

总结：为用户群的属性明确地记载各种猜测。清晰和错误都比模糊不清好得多。

“开发第二系统所引起的后果（second-system effect）”情况怎样？一位敏锐的学生说，人月神话推荐了一剂对付灾难的处方：计划发布任何新系统的第二个版本（第11章），第二系统在第5章中被认为是最危险的系统。

这实际上是语言引起的的差异，现实情况并不是如此。第5章中提到的“第二个”系统是第二个实际系统，它是引入了很多新增功能和修饰的后续系统。第11章中的“第二个”系统指开发第一个实际系统所进行的第二次尝试。它在所有的进度、人员和范围约束下开发，这些约束刻画了项目的特征，形成了开发准则的一部分。

特别值得注意的是，他建议开发项目后期增加的开发人员，必须作为团队成员，愿意在过程中努力投入和工作，而不是企图改变或者改进过程本身！

更基本的是，这来自一个信念，即对于项目的成功而言，项目人员的素质、人员的组织管理是比使用的工具或采用的技术方法更重要的因素。

过去在软件生产率上取得的进展大多数来自消除非内在的困难，如笨拙的编程语言、漫长的批处理周转时间等。

像这些比较容易解决的困难已经不多了。

彻底的进展将来自对根本困难的处理——打造和组装复杂概念性结构要素。

抽象数据类型提供了一种思考和指明模块接口的统一方式，以及容易保证实施的类型规范化访问方法。

E.F.Schumacher在他的经典《小就是美：人们关心的经济学》（Small is Beautiful：Economics as if People Mattered）中，提出了最大化员工创造力和工作乐趣的理论。他的第一个原理是引自Pope Pius XI教皇通谕Quadragesimo Anno中的“附属职能行使原理”：
向大型组织指派小型或者附属机构能够完成的职责是不公平的，同时也是正常次序的不幸和对它的干扰。对于每项社会活动，就其本质而言，应该配备对社会个体成员的帮助，而不是去破坏和吸收它们那些当权者应该确信遵守“附属职能行使”原理，能在各种各样的组织中维持更加完美的次序，越强和越有效的社会权威将会是国家更加融洽和繁荣的条件。

正如人们所预期的，完全不同的经济学引发了非常不同的编程文化。传统产业倾向于被大型公司以已指定的管理风格和企业文化所支配。另一方面，始于数百家创业公司的成品软件产业，行事自由，更加关注结果，而不是流程。在这种趋势下，那些天才的个人程序员更容易获得认可，这隐含了“卓越的设计来自于杰出的设计人员”的观点。创业文化能够对那些杰出人员，根据他们的贡献进行奖励。而在传统软件产业中，公司的社会化因素和薪资管理计划总会使上述做法难以实施。因此，很多新一代的明星人物被吸引到薄膜包装的软件产业，这一点并不奇怪。

今天，软件工程的一些特殊问题正如第1章中所提出的：
􀂉 如何把一系列程序设计和构建成系统
􀂉 如何把程序或者系统设计成健壮的、经过测试的、文档化的、可支持的产品
􀂉 如何维持对大量的复杂性的控制
软件工程的焦油坑在将来很长一段时间内会继续地使人们举步维艰，无法自拔。软件系统可能是人类创造中最错综复杂的事物，只能期待人们在力所能及的或者刚刚超越力所能及的范围内进行探索和尝试。这个复杂的行业需要：进行持续的发展；学习使用更大的要素来开发；新工具的最佳使用；经论证的管理方法的最佳应用；良好判断的自由发挥；以及能够使我们认识到自己不足和容易犯错的——上帝所赐予的谦卑。