[人月神话]读书笔记---人月神话的观点：是与非

人月神话的观点：是与非

所有这些观点都是可操作验证的，我将他们表达成刻版的形式是希望能引起读者的思考，判断和讨论。

第一章：焦油坑

□编程系统产品
我估计软件构件产品引起了3倍工作量，将软件构件整合成完整系统所需要的设计集成和测试又强加了3倍工作量。这些高成本的构件在根本上是相互独立的。

□编程的快乐
创建事物的快乐,开发对其它人有用东西的乐趣
将可以活动，相互齿合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力。
不间断学习的乐趣
工作在如此易于驾驭的介质上的乐趣--纯粹的思维活动，其存在移动和运转方式完全不同于实际物体。

□行业的苦恼
将做事方式调整为追求完美
由其它人来设定目标，并且必须依靠自己无法控制的事物
人们通常期望项目在接近结束时，能收敛的快一些，然而软件项目的情况却是越接近完成，收敛的越慢
产品在即将完成时总面临着陈旧过时的威胁

第二章：人月神话

缺乏合理的时间进度时造成滞后的最主要原因，它比其他所有因素加起来影响还大。
良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。
所有的编程人员都是乐观主义者"一切将运作良好"。
由于编程人员通过纯粹的思维活动来开发，所以我们期待在实现过程中不会碰到困难。
但是我们的构思是有缺陷的，总会有BUG。
人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。
在若干人员中分解任务会引发额外的沟通工作量--培训和相互沟通。
关于进度安排：1/3计划，1/6编码，1/4构建测试，1/4系统测试。
作为一个学科，我们缺乏数据估计。
因为我们对自己的估计技术不确定，所以在管理和客户的压力下，常常缺乏坚持的勇气。
向落后进度的项目中增加人手，只会使进度更加落后。
向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务的重新分配本身和所造成的工作中断。培训新人员，额外的相互沟通。

第三章：外科手术队伍

优秀的专业程序员的工作效率是较差的程序员的十倍。
经验和实际表现之间没有相互联系。
小型精干的队伍是最好的--尽可能的少。
一拥而上的开发方法是高成本，速度缓慢，不充分的，开发出的产品无法进行概念上的集成。
一位首席程序员，类似于外科手术队伍的团队架构提供了一种方法--即能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底减少了沟通的工作量。

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

概念完整性是系统设计中最重要的考虑因素。
功能与理解上的复杂程度的比值才是系统设计的最终测试标准。
为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。
对于非常大型的项目，将设计方法体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。
概念上统一的系统能够更快地开发和测试。
纪律规则对行业是有益的，外部的体系结构规定实际上是增强，而不是限制实现小组的创造性

第五章：画蛇添足

尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
结构师如何成功影响实现：
 牢记是开发人员承担创造性地实现责任；结构师只能提出建议。
 时刻准备着为所指定的说明建议一种实现的方法，准备接受任何其他可行的方法
 对上述的建议保持低调和平静
 准备对所建议的改进放弃坚持
 听取开发人员在体系结构上改进的建议
第二个系统是人们所设计的最危险的系统，通常的倾向是过分地进行设计

第六章：贯彻执行

即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的
出于精确性的考虑，我们需要形式化的设计定义，同样，我们需要记述性定义来加深理解。
必须采用形式化定义和记述性定义中的一种作为标准，另一种作为辅助措施。
允许体系结构师对实现人员的询问做出电话应答解释是非常重要的，并且必须进行日志记录和整理发布。

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

失败的原因是缺乏交流，以及交流的结果--组织。
因为左手不知道右手在做什么，从而进度灾难，功能的不合理和系统缺陷纷纷出现。
团队应该以尽可能多的方式进行相互之间的交流：非正式，常规项目会议，会上进行简要的技术陈述，共享的正式项目工作手册。

□项目工作手册：
 不是独立的一篇文档，它是对项目必须产生的一系列文档进行组织的一种结构。
 项目所有的文档都必须是该(工作手册)结构的一部分。
 需要尽早和仔细地设计工作手册结构。
 事先制定了良好结构的工作手册"可以将后来书写的文字放置在合适的章节中"，并且可以提高产品的质量。
 每一个团队成员应该了解所有的材料(工作手册)。实时更新是至关重要的。
 工作手册的使用者应该将注意力集中在上次阅读后的变更，以及关于这些变更重要性的评述。
 强烈地认为使每个人看到每件事的目标是完全错误的；各个部分应该被封装，从而没有人需要或者允许看到其他部分的内部结构，只需要了解接口。

□组织架构：
 团队组织的目标是为了减少必要的交流和协作量。
 为了减少交流，组织结构包括了人力划分(division labor)和限定职责范围(specialization of function)。
 传统的树状组织结构反映了权力的结构原理--不允许双重领导。
 组织中的交流是网状，而不是树状结构，因而所有的特殊组织机制(往往体现成组织结构图中的虚线部分)都是为了进行调整，以克服树状组织结构中交流缺乏的困难

 产品负责人和技术主管这两种角色中的任意组合可以是非常有效的。一个充当产品负责人，一个充当技术主管

第八章 胸有成竹

仅仅通过对编码部分的估计，然后乘以任务其他部分的相对系数，是无法得出对整项工作的精确估计的。
构建独立小型程序的数据不适用于编程系统项目
程序开发呈程序规模的指数增长。
全职程序员仅将50%的时间用于编程和调试。
生产率是系统各个部分交互的函数，在1.5K千代码行/人年至10K代码行/人年的范围内变化。
当使用恰当的高级语言时，程序编制的生产率可以提高5倍。

第九章 削足适履

规模本身不是坏事，但不必要的规模是不可取的。
软件开发人员必须设立规模目标，控制规模，发明一些减少规模的方法--就如同硬件开发人员为减少元器件所做的一样。
规模预算不仅仅在占据内存方面是明确的，同时还应该指名程序对磁盘的访问次数。
在大型的团队中，各个小组倾向于不断地局部优化，以满足自己的目标，而较少考虑对用户的整体影响。
在整个实现的过程期间，系统结构师必须保持持续的警觉，确保连贯性的系统完整性。
培养开发人员从系统整体出发，面向用户的态度是软件编程管理人员最重要的职能。
编程需要技术积累，每个项目需要自己的标准组件库。
库中的每个组件需要有两个版本，运行速度较快和短小精炼的。
精炼充分和快速的程序，往往是战略性突破的结果，而不仅仅技巧上的提高。
这种突破常常是一种新型算法。
为了取得良好的空间--时间折中，开发队伍需要得到特定于某种语言或者机型的编程技能培训，特别是在使用新语言或新机器时。更普遍的是，战略上突破常来自于数据或表的重新表达。数据的表现形式是编程的根本。

第十章 提纲挈领

少数文档形成了关键的枢纽，每个项目管理的工作都围绕着他们运转。他们是经理们的主要个人工具
对于软件项目，要求是：目标，用户手册，内部文档，进度，预算，组织结构图和工作空间分配
即使是小型项目，也应该在项目早期规范化上述的一系列文档。
以上集合中每一个文档的准备工作都将注意力集中在对讨论的思索和提炼，而书写这项活动需要上百次的细小决定，正是由于他们的存在，人们才能从令人迷惑的现象中得到清晰确定的策略。

对每个关键文档的维护提供了状态监督和预警机制。
每个文档本身就可以作为检查列表或者数据库。
项目经理的基本职责是使每个人都向着相同的方向前进。
项目经理的主要日常工作是沟通而不是做出决定；文档使各项计划和决策在整个团队范围内得到交流。
只有一部分管理人员的时间--可能只有20%--用来从自己头脑外部获取信息。

第十一章 未雨绸缪

对于大多数项目，第一个开发的系统并不合用。它可能太慢，太大，而且难以使用，或者三者兼而有之。
系统的丢弃和重新设计可以一步完成，也可以一块块地实现。这是个必须完成的步骤。
将开发的第一个系统--丢弃原型--发布给用户，可以获得时间，但是它的代价高昂--对于用户，使用极度痛苦；对于重新开发的人员，分散了精力；对于产品影响了声誉，即使最好的再设计也难以挽回名声。

因此为舍弃而计划，无论如何，你一定要这样做。开发人员交付的是用户满意程度，而不仅仅是实际的产品。
用户的实际需要和用户感觉会随着程序的构建，测试和使用而变化。
软件产品易于掌握的特征和不可见性，导致了它的构建人员(特别容易)面临着永恒的需求变更。
为变更计划软件产品的技术，特别是细致的模块接口文档--非常地广为人知，但并没有相同规模的实践。
高级语言的使用，编译时操作，通过引用的声明整合和自文档技术能减少变更引起的错误。

□为变更计划组织架构
程序员不愿意为设计书写文档的原因，不仅仅是由于惰性，更多的是缘于设计人员的踌躇--要为自己尝试性的设计决策进行辩解。为变更组建团队比为变更进行设计更加困难。

只要管理人员和技术人才的天赋允许，老板必须对他们的能力培养给与极大的关注，使管理人员和技术人才具有互换性；特别是希望能在技术和管理角色之间自由地分配人手的时候。

很容易为不同的晋升线建立相互一致的薪水级别，但要同等威信的建立需要一些强烈的心理措施：相同的办公室，一样的支持和技术调动的优先补偿。

对于灵活组织架构问题，这的确是一个长期行之有效的解决方案。

□前进两步，后退一步--程序维护
对于一个广泛使用的程序，其维护总成本通常是开发成本的40%或更多。
维护成本受用户数目的严重影响。用户越多，所发现的错误也越多。
缺陷修复总会以20-50%的几率引入新的BUG。
在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏。
同样设计实现的人员越少，接口越少，产生的错误也就越少。

□前进一步，后退一步--系统熵随时间增加
所有的修改都倾向于破坏系统的架构，增加了系统的混乱程度。即使是最熟练的软件维护工作，也只是放缓了系统退化到不可修复混乱的进程，从中必须要重新进行设计。

第十二章 干将莫邪

项目经理应该制定一套策略，以及为通用工具的开发分配资源，与此同时，他还必须意识到专业工具的需求。
开发操作系统的队伍需要自己的目标机器，进行调试开发工作。相对于最快的速度而言，它更需要最大限度的内存，还需要安排一名系统程序员，以保证机器上的标准软件是即时更新和实时可用的。

目标机器的使用需求量是一种特殊曲线：刚开始使用率非常低，突然出现暴发性的增长，接着趋于平缓。
同天文工作者一样，系统调试总是大部分在夜间完成。
抛开理论不谈，一次分配给某个小组连续的目标时间块被证明是最好的安排方法，比不同小组的穿插使用更为有效。
如果目标机器是新产品，则需要一个目标机器的逻辑仿真装置。
(1)一系列独立的私有开发库(2)正处在系统测试下的系统集成子库(3)发布版本。正式的分离和进度提供了控制。
自顶向下，彻底地开发一个性能仿真装置。尽可能早地开始这项工作，仔细地听取"他们表达的意见"。

□高级语言
只有懒散和惰性会妨碍高级语言和交互式编程的广泛应用。如今他们已经在全世界使用。
高级语言不仅仅提升了生产率，而且还改进了调式：Bug更少，以及更容易寻找。

□交互式编程
调试是系统编程中很慢和较困难的部分，而漫长的调试周转时间是调试的祸根。
交互性编程的生产率至少是原来的两倍。

第十三章 整体部分

许许多多的失败完全源于那些产品未精确定义的地方。
在编写任何代码之前，规格说明必须提交给测试小组，以详细地检查说明的完整性和明确性。
在交互式调试过程中，第一次交互取得的工作进展是后续交互的三倍。这实际上获益于在调试开始之前仔细地调试计划。
系统调试仅仅应该在所有部件能够运作之后开始。系统测试期间，一次只添加一个构件。
开发大量的辅助调试平台(脚手架)和测试代码是很值得的，代码量甚至可能会有测试对象的一半。
必须有人对变更进行控制和文档化，团队成员应使用开发库的各种受控拷贝来工作。
变更的阶段(量子)要么很大，间隔很宽；要么小和频繁。后者很容易变得不稳定。

第十四章 祸起萧墙

项目是怎样延迟了一年的时间？---- 一次一天。
一天一天的进度落后比起重大灾难，更难以识别，更不容易防范和更加难以弥补。
里程碑必须是具体的，特定的，可度量的事件，能进行清晰能定义。
如果里程碑定义得非常明确，以至于无法自欺欺人时，程序员很多会就里程碑的进展弄虚作假。
慢性进度偏离是士气杀手。
进取对于杰出的软件开发团队，同优秀的棒球队伍一样，是不可缺少的必要品德。
不存在关键路径进度的替代品，使人们能够辨别计划偏移的情况。
每个老板同时需要采取行动的异常信息以及用来进行分析和早期预警的状态数据。
状态的获取时困难的，因为下属经理有充分的理由不提供信息共享。
老板的不良反应肯定会对信息的完全公开造成压制；相反，仔细区分状态报告，毫无惊慌地接受报告，决不越俎代庖，将能鼓励诚实的汇报。

必须有评审机制，从而所有成员可以通过它了解真正的状态。出于这个目的，里程碑的计划和完成文档是关键。
对于大型项目，一个对里程碑报告进行维护的计划和控制小组是非常可贵的。

第十五章 另外一面

程序向用户呈现的面貌与提供给机器识别的内容同样重要。
文档能在整个生命周期对克服懒惰和进度的压力起促进激励作用。
每一份发布的程序拷贝应该包括一些测试用例，其中一部分用于校验输入数据，一部分用于边界输入数据，另一部分用于无效的输入数据。
流程图是被吹捧得最过分的一种程序文档。
在线系统的高级语言(应该使用的工具)中，自文档化技术发现了它的绝佳应用和强大功能。
程序修改人员所使用的文档中，除了描述事情如何以外，还应阐述它为什么那样。对于加深理解，目的是非常关键的，但即使是高级语言的语法，也不能表达目的。

原著结束语

软件系统可能是人类创造中最错综复杂的事物(从不同类型组成部分数量的角度出发)。
软件工程的焦油坑在将来很长一段时间内会继续地使人们举步艰险，无法自拔。