人月神话读书笔记(一)
第一章 焦油坑
表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被
解决，但是当它们相互纠缠和积累在一起的时候，团队的行动就会变
得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很
难看清问题的本质。不过，如果我们想解决问题，就必须试图先去理
解它。--清楚地解释系统开发的困难所在。
这，就是编程。一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共
存的创造性活动。对于许多人而言，其中的乐趣远大于苦恼。而本书
的剩余部分将试图搭建一些桥梁，为通过这样的焦油坑提供一些指导。
--本书的目的
第二章 人月神话
1.在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。导致灾难的原因是：
首先，我们对估算技术缺乏有效的研究。
第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆
第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。 第四，对进度缺少跟踪和监督。
第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。
2.系统开发过程中，乐观主义并不应该是理所应当的。
在单个任务中，“一切都将运转正常”的假设在时间进度上具有可实现性。因为所遇的延迟是一个概率分布曲线，“不会延迟”仅具有有限的概率，所以现实情况可能会像计划安排的那样顺利。然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于无。
3.成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
因为软件开发本质上是一项系统的工作--错综复杂关系下的一种实践--沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。
4.在时间进度中，顺序限制所造成的影响，没有哪个部分比单元测试和系统测试所受到的牵涉更彻底。
对于任务的进度安排，以下是作者使用了很多年的经验法则：
1/3 计划
1/6 编码
1/4 构件测试和早期系统测试（单元测试）
1/4 系统测试
5.如果发现项目的实际进度滞后于预计的进度，项目经理最好的办法是重新安排进度，而不是增加项目人手。
6.项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。从这两个数值可以推算出进度时间表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能过时）。相反，分派较多的人手，计划较短的时间，将无法得到可行的进度表。总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加
起来的影响还要大。
第三章 外科手术队伍
1.对于效率和概念的完整性来说，最好由少数干练的人员来设计和开发，而对于大型 系统，则需要大量的人手，以使产品能在时间上满足要求。如何调和这两方面的矛盾呢？--本章要解决的问题
2.Mills的建议：
外科医生（首席程序员）：定义功能和性能技术说明书，设计程序，编制源代码，测试 以及书写技术文档。
副手：主要作用是作为设计的思考者、讨论者和评估人员。
管理员：控制财务、人员、工作地点安排和机器，充当组织中其他管理机构的接口。 编辑：根据外科医生的草稿或者口述的手稿，进行分析和重新组织，提供各种参考信息 和书目，对多个版本进行维护以及监督文档生成的机制。
两个秘书
程序职员：维护编程产品库中所有团队的技术记录。
工具维护人员：保证所有基本服务的可靠性，以及承担团队成员所需要的特殊工具（特 别是交互式计算机服务）的构建、维护和升级责任。
测试人员：各个功能设计系统测试用例的对头，同时也是日常调试设计测试数据的助手。 负责计划测试的步骤和为测试搭建测试平台。
语言专家：寻找一种简洁、有效的使用语言的方法来解决复杂、晦涩或者棘手的问题。
3.当进行大系统开发时：
要有一个系统结构师从上至下地进行所有的设计。要使工作易于管理，必须清晰地划分体
系结构设计和实现之间的界线，系统结构师必须一丝不苟地专注于体系结构。
第四章 贵族专制、民主政治和系统设计
1.概念一致性
在系统设计中，概念完整性应该是最重要的考虑因素。也就是说为了反映一系列 连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合 的系统，哪怕它们其实包含着许多很好的设计。
2.功能与理解上复杂程度的比值才是系统设计的最终测试标准。但是功能本身 或者易于使用都无法成为一个好的设计评判标准。
3.简洁和直白来自概念的完整性。每个部分必须反映相同的原理、原则和一致 的折衷机制。在语法上，每个部分应使用相同的技巧；在语义上，应具有同样的 相似性。因此，易用性实际上需要设计的一致性和概念上的完整性。
4.概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。
5.系统的体系结构(architecture)指的是完整和详细的用户接口说明。体系结 构必须同实现仔细地区分开来。
6.作者不认为只有结构师才有好的创意。新的概念经常来自实现者或者用户。 然而系统的概念完整性决定了使用的容易程度。不能与系统基本概念进行整合的 良好想法和特色，最好放到一边，不予考虑。如果出现了很多非常重要但不兼容 的构想，就应该抛弃原来的设计，对不同基本概念进行合并，在合并后的系统上 重新开始。
7.概念的完整性的确要求系统只反映唯一的设计理念，用户所见的技术说明来 自少数人的思想。实际工作被划分成体系结构、设计实现和物理实现，但这并不 意味着该开发模式下的系统需要更长的时间来创建。经验显示恰恰相反，整个系
统将会开发得更快，所需要的测试时间将更少。同工作的水平分割相比，垂直划 分从根本上大大减少了劳动量，结果是使交流彻底地简化，概念完整性得到大幅 提高。
第五章 画蛇添足
1.本章的目标：结构设计师要避免向系统中添加很多不实际的功能（避免
画蛇添足）。
2.尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获
得对设计的信心，并且不会混淆各自的责任分工。
3.面对估算过高的难题，结构师有两个选择：削减设计或者建议成本更低
的实现方法--挑战估算的结果。后者是固有的主观感性反应。此时，结构师 是在向开发人员的做事方式提出挑战。想要成功，结构师必须
牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而 不能支配；
时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能 达到目标的方法；
对上述的建议保持低调和平静；
准备放弃坚持所作的改进建议。
4.一个可以开阔结构师眼界的准则是为每个小功能分配一个值：每次改进， 功能 x 不超过 m 字节的内存和 n 微秒。这些值会在一开始作为决策的向导 ，在物理实现期间指南和对所有人的警示。
5.项目经理必须坚持至少拥有两个系统以上开发经验的结构师的决定。同时 ，保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和 目标在详细设计中得到完整的体现。
第六章 贯彻执行
1.问题：项目经理如何确保每个人听从、理解并实现结构师的决策？对于有多个结构师
的小组如何保持系统概念上的完整性。
2.手册、或者书面规格说明，是一个非常必要的工具。手册是产品的外部规格说明，它
描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。
手册不但要描述包括所有界面在内的用户可见的一切，它同时还要描述用户看不见的事物。
后者是编程实现人员的工作范畴，而实现人员的设计和创造是不应该被限制的。体系结构
设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该试图支配具体的实
现过程。
规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义，所以每条说明都
必须重复所有的基本要素，所以所有文字都要相互一致。
3.规格说明中，形式化定义是精确的，它们倾向于更加完整；差异得更加明显，可以更
快地完成。但是形式化定义的缺点是不易理解。记叙性文字则可以显示结构性的原则，描
述阶段上或层次上的结构，以及提供例子。应同时包括形式化和记叙性定义两种方式。
4.通过会议的方式，开发人员进行沟通和讨论问题。
5.不同实现之间严格要求相互兼容。如果起初至少有两种以上的实现，那么定义会更加
整洁和规范。
6.对于存有疑问的实现人员，应鼓励他们打电话询问相应的结构师，而不是一边自行猜
测一边工作。
一种有用的机制是由结构师保存电话日志。日志中，他记录了每一个问题和相应的回答。 每周，对若干结构师的日志进行合并，重新整理，并发布给用户和实现人员。这种机制很
不正式，但非常快捷和易于理解。
7.在最后的分析中，用户是独立的监督人员。在残酷的现实使用环境中，每个细微缺陷
都将无从遁形。产品测试小组则是顾客的代理人，专门寻找缺陷。不时地，细心的产品测
试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。出于这方
面的原因，设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手
，与设计同时实现的重要环节。
第七章 为什么巴比伦塔会失败
1.项目人员之间的交流和沟通是项目能否顺利和成功的一个重要因素。
2.缺乏交流引起进度灾难、功能的不合理和系统缺陷纷纷出现。随着工作的进行，许多小组慢慢地修改自己程序的功能、规模和速度，他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定。
团队如何进行相互之间的交流沟通：
清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通，从而达到对所书写文档的共同理解。
常规项目会议。会议中，团队一个接一个地进行简要的技术陈述。这种方式非常有用，能澄清成百上千的细小误解。
在项目的开始阶段，应该准备正式的项目工作手册。
3.项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。
项目所有的文档都必须是该结构的一部分。这包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。
4.使用项目工作手册的原因：
技术说明几乎是必不可少的。如果某人就硬件和软件的某部分，去查看一系列相关的用户手册。他发现的不仅仅是思路，而且还有能追溯到最早备忘录的许多文字和章节，这些备忘录对产品提出建议或者解释设计。
正确的文档结构非常重要。事先将项目工作手册设计好，能保证文档的结构本身是规范的。另外，有了文档结构，后来书写的文字就可以放置在合适的章节中。
控制信息发布，确保信息能到达所有需要它的人的手中。
5.团队组织的目的是减少不必要的交流和合作的数量。减少交流的方法是人力划分和限定职责范围。当使用人力划分和职责限定时，树状管理结构所映出对详细交流的需要会相应减少。
第八章 胸有成竹
1.问题：系统编程需要花费多长时间？需要多少工作量？如何进行估计？
2.工作量是规模的幂函数。
Portman的数据：工作花费的时间大约是估计的两倍。
Aron、Harr、OS/360的数据：生产率会根据任务本身的复杂度和困难程度表现出显著差异。
Carbato的数据：对常用的编程语句而言。生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况。使用适当的高级语言，编程的 生产率可以提高5倍。
第九章 削足适履
1.系统的空间规模：规模是软件系统产品用户成本中如此大的一个组成部分，开发 人员必须设置规模的目标，控制规模，考虑减小规模的方法。同任何开销一样，规模 本身不是坏事，但不必要的规模是不可取的。
2.对项目经理而言，规模控制既是技术工作的一部分，也是管理工作的一部分。必 须研究用户和他们的应用，以设置将开发系统的规模。接着，把这些系统划分成若干 部分，并设定每个部分的规模目标。由于规模--速度权衡方案的结果在很大的范围内 变化，规模目标的设置是一件颇具技巧的事情，需要对每个可用方案有深刻的了解。 聪明的项目经理还会给自己预留一些空间，在工作推行时分配。
仅对核心程序设定规模目标是不够的，必须把所有的方面都编入预算。
在指明模块有多大的同时，确切定义模块的功能。
培养开发人员从系统整体出发，面对用户的态度。
3.在速度不变的情况下，更多的功能意味着需要更多的空间。其中一个技巧是用功 能交换尺寸。设计人员必须决定用户可选项目的精细程度。
4.考虑空间--时间的折衷。对于给定的功能，空间越多，速度越快。
项目经理可以做两件事来帮助他的团队取得良好的空间--时间折衷。一是确保他们在 编程技能上得到培训，而不仅仅是依赖他们自己掌握的知识和先前的经验。特别是使 用新语言或者新机器时，培训显得尤其重要。另一种方法是认识到编程需要技术积累， 需要开发很多公共单元构件。
5.战略上的突破常来自数据或表的重新表达--这是程序的核心所在。数据的表现形 式时编程的根本。
第十章 提纲挈领
1.文档的跟踪维护是项目监督和预警的机制。文档本身可以作为检查
列表、状态控制，也可以作为汇报的数据基础。
2.软件项目文档的内容：
目标。待完成的目标、迫切需要的资源、约束和优先级。 软件开发网
产品技术说明。
进度表。
资金预算。
工作空间分配。
人员组织。
3.为什么要有正式的文档
首先，书面记录决策是必要的。人们能从令人迷惑的现象中得到清晰、确
定的决策。
第二，文档能作为同其他人沟通的渠道。项目经理的基本职责是使每个人
都向着相同的方向前进，所以他的工作主要是沟通，而不是做出决定。文
档能极大地减轻他的负担。
最后，文档可以作为数据基础和检查列表。通过周期性的回顾，他能清楚
项目所处的状态，以及哪些需要重点进行更改和调整。
项目经理的任务是制订计划，并根据计划实现。只有书面计划是精确和可
以沟通的。通过遵循文档开展工作，项目经理能更清晰和快速地设定自己
的方向。
第十一章 未雨绸缪
1.对于大多数项目，第一个开发的系统并不合用。可能太慢、太大，而且难以 使用，或者三者兼而有之。要解决所有的问题，除了重新开始以外，没有其他的 办法--即开发一个更灵巧或者更好的系统。系统的丢弃和重新设计可以一步完成 ，也可以一块块地实现。所有大型系统的经验都显示，这是必须完成的步骤。 -- 构建一个试验性的系统，然后抛弃它。
2.一旦认识到实验性的系统必须被构建和丢弃，具有变更思想的重新设计不可 避免。
3.为变化设计系统，包括细致的模块化、可扩展的函数、精确完整的模块间接 口设计、完备的文档。另外，还可能会采用包括调用队列和表驱动技术。
最重要的措施是使用高级语言和自文档技术，以减少变更引起的错误。采用编译时的操作来整合标准说明，在很大程度上帮助了变化的调整。
变更的阶段化是一种必要的技术。每个产品都应该有数字版本号，每个版本都应 该有自己的日程表和冻结日期。在此之后的变更属于下一个版本的范畴。
4.为变更计划组织架构和团队。
5.程序维护中的一个基本问题是 -- 缺陷修复总会以(20%--50%)的机率引入新 的bug。整个过程是前进两步，后退一步。作为引入新bug的一个后果，程序每条 语句的维护需要的系统测试比其他编程要多，成本非常高。
缺陷不能被彻底修复的原因：
首先，看上去很轻微的错误，似乎仅仅是局部操作上的失败，实际上却是系统级 别的问题。其次，维护人员通常不是编写代码的开发人员。
5.使用能消除、至少是能指明副作用的程序设计方法，会在维护成本上有很大 的回报。设计实现的人员越少、接口越少，产生的错误也就越少。
6.维护工作破坏系统的架构，增加了系统的混乱程度。随着时间的推移，系统 变得越来越无序，无法再成为下一步进展的基础。这时，系统的重新设计完全是 必要的。
系统软件开发是减少混乱度的过程，软件维护是提高混乱度的过程，即使是最熟 练的软件维护工作，也只是放缓了系统退化的进程。
