人月神话

一、焦油坑

编程系统产品（ Programming Systems Product） 开发的工作量是供个人使用的、独立开发的构件程序的九倍

职业的乐趣

（1）创建事物的快乐；
（2）开发对其他人有用的东西的乐趣；
（3）将可以活动、 相互啮合的零部件组装成类似迷宫的东西， 这个过程所体现出令人神魂颠倒的魅力；
（4）面对不重复的任务，不间断学习的乐趣；
（5）工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动， 其存在、 移动和运转方式完全不同于实际物体；

职业的苦恼

（1）必须追求完美：作者认为学习编程的最困哪部分，是将做事的方式往追求完美的方向调整。
（2）由他人设定目标，供给资源，提供信息：编程人员很少能控制工作环境和工作目标。
（3）概念性设计有趣的，但寻找琐碎的bug却只是一项重复性的活动。
（4）人们通常期望项目在接近结束时，（ bug、 工作时间） 能收敛得快一些， 然而软件项目的情况却是越接近完成，收敛得越慢
（5）产品完成时却变得陈旧了。

二、人月神话

美酒的酿造需要年头，美食的烹调需要时间；片刻等待，更多美味，更多享受（延迟满足感）

缺乏合理的时间进度是造成项目滞后的最主要原因：

（1）进行项目安排时，总是假设“一切将运作良好”；
（2）错误地将进度与工作量相互混淆；
（3）由于对自己估算缺乏信心，不会有耐心进行持续地估算这项工作；

乐观主义

（1）创造性活动分为三个阶段：构思、实现、交流
（2）一切正常的概率非常小，甚至接近于无

人月

荒谬的神话：

（1）完全可以分解的任务，并且不需要交流（系统编程中近乎不可能）
（2）无法分解的任务，由于次序上的顺序无法分解（许多软件具有这种特征）
（3）需要沟通的可分解任务，尽量不要增加人手（沟通所增加的负担由两部分组成：培训和互相交流）
（4）关系错综复杂的任务，工作量按照n(n-1)/2递增

系统测试

（1）通常实际出现的缺陷数量比预期的要多得多，因此测试进程的安排常常是编程中最不合理的部分。
（2）软件任务的进程安排：1/3计划、1/6编码、1/4构建测试和早期系统测试、1/4系统测试，所有构件完成

空泛的估算

（1）某项任务的计划程度，可能受限于顾客要求的紧迫程度，因此容易估算出错
（2）重复产生的进度灾难
（3）向进度落后的项目中增加人手，只会使进程更加落后

三、外科手术队伍

问题

（1）小型精炼的团队比大型团队效率要高很多
（2）大型团队在某些时刻开发用时可能比小型团队要短

Mills的建议

外科医生：亲自定义功能和性能的技术说明书，设计程序，编制源代码，测试以及书写技术文档
副手 ：外科医生的后备，能完成任何一部分工作，作为设计的思考着、讨论者和评估人员
管理员 ：管理控制财务、人员、工作地点等
编辑 ：整理外科医生的文档
两个秘书：管理员和编辑各一个秘书
程序职员：负责维护编程产品库中所有团队的技术记录
工具维护人员：维护例如交互式计算机服务之类的书
测试人员：搭建测试平台、测试
语言专家：寻找一种简洁、有效的使用语言的方法来解决棘手的问题

如何运作

（1）所有人都为外科医生服务
（2）观点的不一致由外科医生单方面来统一

团队的扩建

（1）决定设计的人员应是原来的七分之一或者更少
（2）清晰地划分体系结构设计和实现之间的界限

四、贵族专制、民主政治和系统设计

获得概念的完整性

（1）系统设计中，概念的完整性应该是最重要的考虑因素
（2）编程系统的目的是使计算机更加容易使用（易用性），易用性实际上需要设计的一致性和概念上的完整性

贵族专制统治和民主政治

解决概念完整性与进度压力的方法：

（1）仔细地区分设计方法和具体实现
（2）组建外科手术队伍

在等待时，实现人员应该做什么？

实现人员对设计人员提出的问题：

该说明中的功能过于繁多，而对实际情况中的成本考虑比较少
结构师获得了所有创造发明的快乐，剥夺了实现人员的创造力，实现同样是一项高级别的创造性工作
当体系结构的队伍工作缓慢时，很多实现人员只能空闲地坐着等待，所以
（1）必须设定良好定义的时间和空间目标，了解产品运行的平台配置
（2）开始设计模块的边界、表结构、算法以及所有的工具
（3）需要花费一些时间和体系结构师沟通
整个创造性活动包括了三个独立的阶段：
（1）体系结构
（2）设计实现
（3）物理实现

五、画蛇添足

结构师的交互准则和机制：

（1）牢记开发人员承担创造性和发明性的实现责任，所以结构师只能建议，不能支配；
（2）时刻准备着为所指定的说明建议一种实现方法，同样准备接受其他任何能达到目标的方法；
（3）对上述的建议保持低调和平静；
（4）准备放弃减持所作的改进建议；

自律——开发第二个系统所带来的后果

（1）第二个系统是设计师们所设计的最危险的系统；
（2）避免功能上的修饰；
（3）把工作量投入在提高动态内存分配和动态交叉引用的性能上；
（4）为每一个小功能分配一个值：每次改进，功能X不超过m字节的内存和n微秒

六、贯彻执行

（1）文档化的规格说明--手册
（2）形式化定义
（3）直接整合
（4）会议和大会
（5）多重实现：为了如实地遵从手册更新机器所造成的延迟和成本消耗
（6）电话日志
（7）产品测试

七、为什么巴比伦塔会失败

巴比伦塔的管理教训

（1）交流产生组织
（2）交流与组织很重要
（3）没有交流，组织就会分裂而不是争吵

大型编程项目中的交流

（1）非正式途径
（2）会议
（3）工作手册

项目工作手册

（1）他是对项目必须产出的一系列文档进行组织的一种结构（目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录）
（2）为了回顾的时候发现思路，查看备忘录对产品提出的建议和设计解释说明
（3）项目手册的目的是确保信息能到达所有需要它的人的手中
（4）处理机制：涉及到大规模多人参与的项目的信息索引管理机制，详见p43

大型编程项目的组织架构

（1）产品负责人和技术主管是同一个人
（2）产品负责人作为总指挥，技术主管充当其左右手
（3）技术主管作为总指挥，产品负责人充当其左右手

八、胸有成竹

九、削足适履

（1）作为成本的程序空间
（2）规模控制
（3）空间技能
（4）数据的表现形式是编程的根本

十、提纲挈领

文档来自：技术、周边组织机构、行业传统等若干因素凑在一起；

文档的某些部分包含和表达了一些管理方面的工作

（1）文档的跟踪维护是项目监督和预警的机制
（2）文档本身可以作为检查列表、状态控制、汇报的数据基础

计算机产品的文档

目标，技术说明，进度、时间表，预算，组织机构图，工作空间的分配，报价、预测、价格
大学科系的文档（略）

软件项目的文档

做什么，时间：进度表，资金：预算，地点：工作空间分配，人员：组织图

为什么要有正式的文档？

（1）记录下来减少矛盾；
（2）作为同其他人沟通的渠道；
（3）作为数据基础和检查列表；

十一、未雨绸缪

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

试验性工厂和增大规模

（1）海水淡化先在量产为10000加仑/每天试验，然后再用于2000000加仑/每天；
（2）开发的系统总要被抛弃；

唯一不变的就是变化本身

（1）开发人员交付的是用户满意度，而不是实际的产品，用户的需求和感觉会变化；
（2）事先为它们做准备总比假设它们不会出现要好得多；

为变更计划系统

（1）细致的模块化、可扩展的函数、精确完整的模块间接口设计、完备的文档；
（2）采用一些调用队列和表驱动的一些技术（并不明白这是怎么用的）；
（3）最重要的措施是，使用高级语言和自文档技术，以减少变更引起的错误；

为变更计划组织架构

设计人员不愿意为设计书写文档化的原因：懒惰、时间压力、不愿意为此进行辩解；

减少人员的变更

（1）有两三个顶级程序员在最前沿解决各种问题；
（2）减少管理头衔，每个人都是技术人员中的一员；
（3）组建外科手术团队；

前进两步，后退一步

（1）新发布的版本对上一版本的缺陷修复总会以（20-50）%的机率引入新的bug；
（2）轻微的错误，有时候实际上是系统级别的问题；
（3）设计实现的人员越少、接口越少、产生的错误也就越少；

前进一步，后退一步

（1）大型操作系统的所有修改都倾向于破坏系统的架构，增加了系统的混乱程度；
（2）实际上，机器失灵了。看上去，就好像是机器正常启动，跑了几部，然后垮掉了（这句真的很搞笑）；
（3）系统开发是减少熵的过程，系统维护是增加熵的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的进程

十二、干将莫邪

巧匠因为他的工具而出名。（新鲜！）

目标机器

（1）软件所服务的对象，程序必须在该机器上进行最后测试；
（2）计划安排好使用目标机器；

辅助机器和数据服务

（1）仿真装置：用于新机器初现之前的调试；
（2）仿真机器无法精确地达到与新型机器一致的实现；
（3）编译器和汇编平台：也需要运行在可靠的辅助平台上；
（4）维护程序库；
（5）编程工具；
（6）文旦系统：在所有工具中，最能节省劳动力的，可能是运行在可靠平台上的、计算机化的文本编辑系统；
（7）性能仿真装置（并没有用过）；

高级语言和交互式编程

（1）此处作者建议使用高级语言编程
（2）多个级别上的数据和程序的共享和保护，可延伸的库管理，以及协助终端用户开发的设施；

十三、整体部分

和古老神话里一样，现代神话里也总有一些爱吹嘘的人
我能召唤遥远的精灵。
那又怎么样，我也可以，谁都可以，问题是你真的召唤的时候，它们会来吗？

剔除bug的设计

（1）各个组成部分的开发者都会做出一些假设，而这些假设之间的不匹配，是大多数致命和难以察觉的bug的主要来源。
（2）编码之前测试规格说明就要交给测试小组；
（3）采用自顶向下的设计；

构建单元调试，四个步骤

本机调试——>内存转储——>快照——>交互式调试
系统集成调试(系统调试花费的时间会比预料的更长；需要一种完备系统化和可计划的方法来降低它的困难程度；)

使用经过调试的构件单元

（1）除了构件上的bug之外，还存在系统bug，越早将各个部分合拢，系统bug出现得越早；
（2）另一种观念，使用系统的各个部分进行相互测试，避免了大量测试辅助平台的搭建工作；
（3）但经验显示，使用完好的、经过调试的构件，能比搭建测试平台和进行全面的构件单元测试节省更多的时间； 搭

建充分的测试平台

（1）伪构件的形式
（2）微缩文件
（3）微缩文件的特例，伪文件

控制变更

（1）一次添加一个构件，对系统进行回归测试
（2）阶段（量子）化、定期变更，不要采用小而频繁的变更

十四、祸起萧墙

带来坏消息的人不受欢迎

里程碑还是沉重的负担？

（1）里程碑要有明显边界和没有歧义
（2）里程碑要清晰，切实的完成
（3）政府的承包商的两项有趣的研究结果显示：
　　1.如果在某项活动开始之前就着手估计，并且每两周进行一次仔细的修订。这样，随着开始时间的临近，无论最后情况会变得如何的糟糕，它都不会有太大的变化。
　　2.活动期间，对时间长短的过高估计，会随着活动的进行持续下降。
　　3.过低估计在活动中不会有太大的变化，一直到计划的结束日期之前大约三周左右。

“其他的部分反正会落后”

（1）必须关注每一天的滞后，它们是大灾祸的基本组成元素；
（2）使用PERT图

地毯的下面

老板很难得到项目进展状况的真相；
掀开毯子的方法：
（1）减少角色冲突和鼓励状态共享：不对项目经理可以解决的问题做出反应，并且决不再检查报告的时候做安排；
（2）猛地拉开地毯：使用PERT图；

十五、另外一面

不了解，就无法真正拥有。 ————歌德

需要什么样的文档

使用程序

（1）目的：主要的功能是什么？开发程序的原因是什么？
（2）环境：程序运行在什么样的机器、硬件配置和操作系统上？
（3）范围：输入的有效范围是什么？允许显示的合法范围是什么？
（4）实现功能和使用的算法：精确地阐述它做了什么。
（5）输入－输出格式：必须是确切和完整的。
（6）操作指令：包括控制台及输出内容中正常和异常结束的行为。
（7）选项：用户的功能选项有哪些？如何在选项之间进行挑选？
（8）运行时间：在指定的配置下，解决特定规模问题所需要的时间？
（9）精度和校验：期望结果的精确程度？如何进行精度的检测？

验证程序

（1）针对遇到的大多数常规数据和程序主要功能进行测试的用例。它们是测试用例的主要组成部分。
（2）数量相对较少的合法数据测试用例，对输入数据范围边界进行检查，确保最大可能值、最小可能值和其他有效特殊数据可以正常工作。
（3）数量相对较少的非法数据测试用例， 在边界外检查数据范围边界， 确保无效的输入能有正确的数据诊断提示。

修改程序

（1）流程图或子系统的结构图，对此以下有更详细的论述。
（2）对所用算法的完整描述，或者是对文档中类似描述的引用。
（3）对所有文件规划的解释。
（4）数据流的概要描述——从磁盘或者磁带中， 获取数据或程序处理的序列——以及在每个处理过程完成的操作。
（5）初始设计中，对已预见修改的讨论；特性、功能回调的位置以及出口；原作者对可能会扩充的地方以及可能处理方案的一些意见。另外，对隐藏缺陷的观察也同样很有价值。

流程图

流程图被鼓吹的过于重要；

自文档化的程序

数据处理的基本原理告诉我们，试图把信息放在不同的文件中，并努力维持它们之间的同步，是一件非常费力不讨好的事情。
解决方案是，把文档整合到源代码：
（1）在代码中添加标签、声明语句、符号名称等；
（2）提高程序的可读性，表现从属和嵌套关系；
（3）段落注释的形式，向程序中插入必要的记述性文字；

一些技巧

（1）为每次运算使用单独的任务名称。 维护一份日志， 记录程序运行的目的、 时间和结果。如果名称由一个助记符（这里是 QLT）和数字后缀组成，那么后缀可以作为运算编号，把列表和日志联系在一起。这种技术要求为每次运算准备新的任务卡， 不过这项工作可以采用“重复进行公共信息的批处理”来完成。
（2）使用包含版本号和能帮助记忆的程序名称。 即， 假设程序将会有很多版本。 例子中使用的是 1967 年的最低一位数字。
（3）在过程（ PROCEDURE）的注释中，包含记叙性的描述文字。
（4）尽可能为基本算法提供参考引用，通常它会指向更完备的处理方法。这样，既节省了空间，同时还允许那些有经验的读者能非常自信地略过这一段内容。
（5）显示和算法书籍中的传统算法的关系。
　　a) 更改 b) 定制细化 c) 重新表达
（6）声明所有的变量。采用助记符，并使用注释把 DECLARE 转化成完整的说明。注意，声明已经包含了名称和结构性描述， 需要增加的仅仅是对目的的解释。 通过这种方式， 可以避免在不同的处理中重复名称和结构性的描述。
（7）用标签标记出初始化的位置。
（8）对程序语句进行分组和标记，以显示与设计文档中语句单元的一致性。
（9）利用缩进表现结构和分组。
（10）在程序列表中， 手工添加逻辑箭头。 它们对调试和变更非常有帮助。 它们还可以补充在页面右边的空白处（注释区域），成为机器可读文字的一部分。
（11）使用行注释来解释任何不很清楚的事情。 如果采用了上述技术， 那么注释的长度和数量都将小于传统惯例。
（12）把多条语句放置在一行， 或者把一条语句拆放在若干行， 以吻合逻辑思维， 表示和其他算法描述一致。

为什么不？

在一些情况下会增加源代码的大小；

十六、没有银弹——软件工程中的根本和次要问题

没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。

是否一定那么困难呢？————根本困难

计算机硬件发展得太快，软件发展跟不上；

根本的————软件特性中固有的困难

（1）软件实体必不可少的部分：数据集合、 数据条目之间的关系、 算法、 功能调用等等；
（2）作者认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概念进行表达和对实现逼真程度进行验证；
（3）复杂度：由于复杂度，团队成员之间的沟通非常困难；列举和理解所有可能的状态十分困难；使全面理解问题变得困难，从而妨碍了概念上的完整性；使所有离散出口难以寻找和控制；引起了大量学习和理解上的负担，使开发慢慢演变成了一场灾难。
（4）一致性：软件工程是面对的是没有一致性的代码；
（5）可变性：软件工程有时需要很大量的修改；
（6）不可见性：软件无法形象的表现出来，这种缺陷不仅限制了个人的设计过程，也严重地阻碍了相互之间的交流。

次要的————出现在目前生产上的，但并非那些与生俱来的困难

（1）高级语言：软件生产率、可靠性和简洁性上最有力的突破；
（2）抽象程序包含了很多概念上的要素：操作、数据类型、流程和相互通讯，而具体的机器语言程序则关心位、寄存器、条件、分支、 通道、 磁盘等等。
（3）分时：提高了程序员的生产率和产品的质量
（4）统一编程环境：它们主要通过提供集成库、统一文件格式、管道和过滤器

银弹的希望

（1）Ada和其他高级编程语言
（2）面向对象编程
（3）专家系统
（4）“自动”编程
（5）图形化编程
（6）程序验证
（7）更好的环境和工具
（8）高运算速度的工作站

针对概念上根本问题的颇具前途的方法

（1）也许购买软件比自行开发要快捷有效的多，学会使用软件比会编写软件要有用的多；
（2）软件系统的快速原型对重要的系统界面进行模拟，并演示待开发系统的主要功能；
（3）增量的方式一点一点搭建系统，一个原因是雏形可以极大的推动士气；
（4）卓越的开发人员和一般之间的差异接近于一个数量级

十七、再论《没有银弹》

那些想看到完美方案的人，其实在心底里就认为它们以前不存在，以后也不可能出现。 ————亚历山大 波普

创造性活动包括

（1）概念性结构的形式规格化；
（2）使用现实的介质来实现；
（3）在实际的使用中，与用户交互 ；

现实问题

　　《没有银弹》无可争辩地指出，如果开发的次要部分少于整个工作的9/10，那么即使不占用任何时间（除非出现奇迹），也不会给生产率带来数量级的提高。因此， 必须着手解决开发的根本问题。