《人月神话》之章节笔记

[此文于2010年7月23日被重新编辑]

 

      初次听到“人月神话”这个词是在大二的时候，当时以为是人和月亮的故事，后来看到这本书的英文名（The Mythical Man—Month）时，才知道原来是月份的月，于是猜想，这可能是一本关于软件开发过程管理的书籍，讲的是软件开发人员与开发月份的适度安排问题，下面就每个章节本人的理解做小摘录和总结，画下划线的部分为原书中的小标题，表示该章节的内容过多，在此省略，有兴趣读者可以去参看原文。 

      第1章：焦油坑

       1.表面上看似单独可行的问题，当他们相互纠结和累积在一起的时候会触发预料之外的问题，最终导致软件不可交付。

      2.单独的程序本身没有任何价值，有两种途径使程序转变为更有用、成本更高的产物：把程序变成通用的编程产品，使他可以被任何人运行、测试、修复和扩展；把程序变成编程系统中的一个构建单元，它在功能 上相互协作、具有规范的格式、可以进行交互的程序集合，并可以用来组装和搭建整个系统。

      第2章：人月神话

       1.在众多软件项目中，缺乏合理的京都安排是造成项目之后的主要原因，它比其他所有因素加起来的影响还要大。

      2.当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。

      3.对于错中复杂关系的任务，实践、沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间，从而，添加更多的人手，实际上是延长了时间进度。

      4.向工作落后的项目中增加人手，由于，新加入成员需要时间理解项目目前进度和融入新团体，只会使进度更加落后。

      第3章：外科手术队伍

       Mills提供了一个崭新的、创造性的解决方案，十个人的团队，其中七个专业人士在解决问题，而系统是一个人活着最多两个人思考的产物，因此客观上达到了概念的一致性，而成员的合理分工成为团队高效开发的关键。

      第4章：贵族专制、民主政治和系统设计

       1.在系统设计中，概念完整性应该是最重要的考虑因素。为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，即使它包含着许多很好的设计。

      2.简洁和直白来自概念的完整性，每个部分必须反映相同的原理需求的一致平衡。在语法上，每个部分应使用相同的技巧；语义上，应具有相同的相似性。

      第5章：画蛇添足

       1.程序员无法跳过二次系统。但可以有意识关注那些系统的特殊危险，运用特别的自我约束准则，来避免那些功能上的修饰；根据系统基本理念及目的变更，舍弃一些功能。

      2.项目经理如何避免画蛇添足（second-system effect）？他必须坚持至少拥有两个系统以上开发经验结构师的决定。同时，保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。

      第6章：贯彻执行

       1.文档化的规格说明——手册

      2.形式化定义

      3.直接整合

      4.会议和大会

      5.多重实现

      6.电话日志

      7.产品测试

      第7章：为什么巴比伦塔会失败

       1.大型编程项目中的交流：非正式交流（电话等）；会议；工作手册

      2.项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档（包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录等）进行组织的一种结构，而且它也被用来控制信息的发布，确保信息能够到达所有需要它的人的手中。

      3.工作手册实时更新是非常关键的。

      4.减少交流的方法是人力划分和限定职责范围。当使用人力划分和职责限定是，树状管理结构反映出对详细交流的需要会相应减少。

      5.产品负责人和技术主管是同一人。这种方式可以非常容易地应用在小型（3-6人）的队伍中，在大型的项目中则不容易获得应用。

      第8章：胸有成竹

       1.Portman的数据

      2.Aron的数据

      3.Harr的数据

      4.OS/360的数据

      5.Corbato的数据

       第9章：削足适履

       1.规模控制中，应该制订驻留程序空间预算，制订总体规模的预算，制订后台存储访问的预算。并且在指明模块有多大的同时，确切定义模块的功能。

      2.项目规模本身很大，缺乏管理和沟通，以至于每个团队成员为了满足目标，每个人都在局部优化自己的程序，而缺乏对整体的考虑。在整个实现的过程期间，系统结构师必须保持持续的警觉，确保连贯的系统完整性。在这种监督机制之外，是实现人员自身的态度问题。培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能。

      3.内存受限的后果是即使最细密的 功能模块，它的适应范围也难以得到推广。

      4.编程需要技术积累，需要开发很多公共单元构件。每个项目又能用与队列、搜索、散列和排序的例程或者宏库。对于每项功能，库至少应该有两个程序实现：运行速度较快和短小精炼的。

      5.数据的表现形式是编程的根本，良好的数据表现可以减少空间消耗。

       第10章：提纲掣领

       在堆积如山的文件资料中，少数文档是关键枢纽，每一件项目管理的工作都围绕着它们运转。这些文档时项目经理最重要的个人工具。

      第11章：未雨绸缪

       1.对于大多数项目，第一个开发的系统并不合用，所以预先计划抛弃原型的开发，为舍弃而开发是不二的选择。

      2.开发人员交付的是用户满意程度，而不仅仅是实际的产品。用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。

      3.不建议顾客目标和需求的所有变更必须、能够、或者应该整合到设计中。项目开始时建立的基准，肯定会随着开发的进行越来越高，甚至开发不出任何产品。

      4.把项目的不确定性减小到最小，需要细致的模块化、可扩展的函数、精确完整的模块间接口设计、完备的文档。另外，还可能会采用包括调用队列和表驱动的一些技术。

      5.程序维护中的一个基本问题是——缺陷修复总会以（20－50）%的机率引入新的bug。所以整个过程是前进两步，后退一步。

      6.理论上，在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏。实际情况中，回归测试必须接近上述理想状况，所以它的成本非常高。

      7.系统软件开发是减少混乱度（减少熵）的过程，所以它本身是处于亚稳态的。软件维护是提高混乱度（增加熵）的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的进程。

      第12章：干将莫邪

       1.目标机器

      2.辅助机器和数据服务

      3.高级语言和交互式编程

      第13章：整体部分

      好的自顶向下设计从几个方面避免了bug。首先，清晰的结构和表达方式更容易对需求和模块功能进行精确的描述。其次，模块分割和模块独立性避免了系统级的bug。另外，细节的隐藏使结构上的缺陷更加容易识别。第四，设计在每个精化步骤的层次上是可以测试的，所以测试可以尽早开始，并且每个步骤的重点可以放在合适的级别上。

       第14章：祸起萧墙

       1. 如果在某项活动开始之前就着手估计，并且每两周进行一次仔细的修订。这样，随着开始时间的临近，无论最后情况会变得如何的糟糕，它都不会有太大的变化。
      2. 活动期间，对时间长短的过高估计，会随着活动的进行持续下降。
      3. 一直到计划的结束日期之前大约三周左右，过低估计在活动中不会有太大的变化。

      4.老板必须区别行动信息和状态信息。他必须规范自己，不对项目经理可以解决的问题做出反应，并且决不在检查状态报告的时候做安排。

      5.不论协作与否，拥有能了解状态真相的评审机制是必要的。PERT图以及频繁的里程碑是这种评审的基础。

      第15章：另外一面

       1.需要什么样的文档

      2.流程图

      3.自文档化的程序（在代码添加注释）

      第16章：没有银弹

       1.相对必要任务而言，软件工程师在次要任务上花费了多少时间和精力？除非它占了所有工作的9/10，否则即使全部次要任务的时间缩减到零，也不会给生产率带来数量级上的提高。

      2.软件开发总是非常困难的。天生就没有银弹。

      3.现代软件系统中这些无法规避的内在特性：复杂度、一致性、可变性和不可见性。

      4.目前业界所有的努力，并没有从根本上解决软件的内在特性所带来的问题，如果这些问题解决了，那软件开发也没有必要作为一门学科来研究了。

      …………

      第17章：再论“没有银弹”

      …………

 

     

 

 

 

参考文献：《人月神话23周年中文纪念版》——清华大学出版社，Frederich P.Brooks.Jr.著，汪颖译——ISBN 9787302155676