《人月神话》

章节重点

作者：Freder ick P.Brooks
作者简介摘抄至豆瓣~
Freder ick P.Brooks.曾荣获美国计算机领域最具声望的图灵奖（A.M.TURINGAWARD）桂冠。美国计算机协会（ACM）称赞他“对计算机体系结构、操作系统和软件工程作出了里程碑式的贡献”。

Brooks博士被认为是“IBM 360系统之父”，曾担任360系统的项目经理，以及360系统项目设计阶段的经理。凭借在此项目中的杰出贡献，他与BobEvarls和Erich BIocll在1985年荣获了美国国家技术奖（NationalMedal of TecPlnoIogy）。Brooks博士早期曾担任IBM公司stretcPl和Harvest计算机的体系结构设计师。
　　
《人月神话》是一本无论程序员开发年限、资历、经验多少都可以读的书，而且不同经验在阅读这本书时都会有不同的感受和领悟。这篇类读后感，写下此时读完这本书的读书笔记整理与感悟。希望自己每看一次可以记录一些新的体会。

我从该书的每个章节摘选自己觉得比较有意思的话，加以自己的体会写下此篇。

焦油坑

1、谚语： 前车之覆 后车之鉴（a ship on the beach is a lighthouse to the sea）
前面的车翻了，后面的车要引以为戒。比喻以往的失败，应该拿来当作教训。

2、编程系统产品
有两种途径可以将程序转变成更有用及成本更高的产物，即编程系统产品。第一，通过程序转变成编程产品，首先程序按照普遍认可的风格编写（特别是输入的范围和形式必须广泛适用于所有可以合理使用的基本算法），然后对程序进行彻底测试，保证程序的稳定性和可靠性，另外还需要完备的文档。第二种是通过程序转变成编程系统，首先程序必须按照一定的要求编制，是输入和输出在语法和语义上与精确定义的接口一致，然后程序要符合预先定义的资源限制（内存空间、输入输出设备、计算机时间），最后程序必须和其他系统构建单元以任何能想象到的组合进行测试。
（程序变成系统产品的过程就是产生产品的过程，产品进行需求分析，编程人员对需求进行详细设计、编码、自测，测试人员进行功能测试、性能测试、安全测试等）

3、职业的乐趣
作者认为编程的快乐包括：创建事物的纯粹快乐；这种快乐来自于开发对他人有用的东西；在整个编程过程中，将系统的零部件组装在一起的过程使人快乐；这种快乐也是持续学习的快乐；这种快乐来自于在易于驾驭的介质上工作。
编程的过程也存在固有的苦恼：追求完美；由他人设定目标、供给资源和提供信息；对他人的依赖；概念性设计后是寻找琐碎bug的过程；投入大量劳动产品即将完成时却显得陈旧过时的无奈感。

（作者用焦油坑描述编程人员的挣扎和乐趣与苦恼并存的现状，但以编程作为工作的程序员，快乐会远远大于苦恼的。但真正热爱编程的程序员有多少呢？ 到2019年，互联网行业是不是已经不再是大家争先想要从事的行业？ 我对编程并不是那么热爱，只是作为职业而言，我可以去了解它，也可以去运用它，但工作这一年来，我觉得我并没有深切的感受到编程的乐趣。所以我想要从编程思想入手，站在其他层面了解编码这回事，所以开始看关于编程思想的书籍，参考上一篇整理的《程序员修炼之道》。其实想想很多系统都是在实用系统，在生活中的充分应用是可以在编程中体现的，比如设计模式的应用、编码用户思维。）

人月神话

1、乐观主义
系统编程的进度安排背后的第一个错误假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。
第二个谬误的思考方式：用人月作为估计和进度安排的实用工作量单位。作者认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话，它暗示人员数量和时间是可以相互替换的。

2、系统测试
软件任务进度安排：
1/3 计划
1/6 编码
1/4 构建测试和早期系统测试
1/4 系统测试，所以的构建已完成

3、空泛的估计
为了满足顾客期望的日期而造成的不合理进度安排，在软件领域中比其他任何工程领域要普遍得多，非阶段化方法的采用、少得可怜的数据支持加上完全借助软件经理的直觉，这种方式很难生产出有力的、看似可靠的和规避风险的估计。
（只是想吐槽一下，虽然大家都不容易，现在项目的产品做得真的很差，连测试都忍不住要吐槽他。。。）

4、重复产生的进度灾难
向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later）。
项目的时间依赖于顺序上的限制，人员的最大数量依赖于独立子任务的数量。

外科手术队伍

1、效率高和效率低的实施者之间的个体差异非常大，经常能够达到数量级的水平。
（之前看综艺《密室大逃脱 大神版》发现大神之所以称为大神，真的是有原因的。他们在密室的应变能力、对场景的预判能力、逻辑推理能力都有很好的表现。每个都好喜欢啊，，， 哈哈哈哈）

2、问题
数据表明，经验和实际的表现没有相互联系。
对于效率和概念的完整性来说，最好由少数干练的人员来设计和开发，而对大型系统，则需要大量的人手，以使产品能在时间上满足要求。
问题是：如何使用少数人开发大型项目？

3、Mills的建议
Mills建议大型项目的每一个部分由一个团队解决，但是该队伍用类似外科手术的方式组件，而不是一拥而上。以下是参考外科手术队伍对10人的编程队伍进行专业化角色分工。

外科手术队伍	开发人员队伍	开发人员职能
外科医生	首席程序员	定义功能和性能技术说明，设计程序，编制源代码，测试，书写技术文档
副手	助手	作为设计的思考者、讨论者和评估人员。详细了解所有代码，研究设计策略的备选方案。
管理员	老板	仅在项目具有法律、合同、报表和财务方面的需求时，管理员才具有全职责任。
编辑	编辑	创建各种文档，提供各种参考信息和书面，对多个版本进行维护，冰监督文档生成机制。
两个文秘	文秘	管理员和编辑每个人需要一个文秘，管理员的文秘负责非产品文件和是项目协作一致
职员	程序职员	维护编程产品库中所有团队的技术记录。接受文秘性质的培训，承担机器码文件和可读文件的相关管理责任。
工具维护人员	维护人员	开发实用程序，编制具有目录的函数库和宏库
	测试人员	功能测试、日常调试设计测试数据、计划测试步骤、为单元测试搭建测试平台。
	语言专家	寻找一种简洁、有效的使用语言的方法解决复杂、晦涩或棘手的问题。

4、如何运作
① 首席程序员和副手了解所有的设计和全部的代码，节省了空间分配、磁盘访问的工作量，同时也确保了工作概念上的完整性。
② 不存在利益的差别，观点不一致的地方可以有首席程序员单方面统一。外科手术队伍的组件对问题不进行分解和上下级的关系。
③ 团队中剩余人员职能的专业化分工是高效的关键。

5、团队的扩建
扩建过程的成功依赖于每个部分的概念完整性得到彻底的提高，整个系统必须具备概念完整性，要有一个系统结构师从上至下地进行所有的设计。要使工作易于管理，必须清晰地划分体系结构设计和实现之间的界限，系统结构师必须一丝不苟地专注体系结构。

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

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

2、获得概念的完整性
① 编程系统（软件）的目的是使计算机更加容易使用。
② 由于系统的目标是易用性（simplicity），功能与概念的负责成都的比值才是系统设计的最终测试标准。但是功能本身或者简洁都无法成为一个好的设计评判标准。
③ 对于给定级别的功能，能用最简洁和直接的方式来指明事情的系统时最好的。
④ 易用性实际上需要设计的一致性和概念上的完整性。

3、规则专制统治和民主政治
① 概念的完整性要求设计必须由一个人厚着非常少数互有默契的人员完成，而进度压力却要求很多人员开发系统，通过两种方法可以解决这种矛盾。第一种是仔细地对设计方法和具体实现进行分工，第二章是崭新的组件开发团队。
② 对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。体系结构陈述的是发生了什么，而实现描述的是如何实现。（举例：时钟）
③ 系统的体系结构指的是完整和详细的用户接口说明。
④ 产品的成本性能比很大程度上依赖实现人员，就如同易用性在很大程度上依赖于结构师一样。

3、在等待时，实现人员应该做什么
① 编程的整个创造性活动包括三个独立的阶段：体系结构（architecture）、设计实现（implementation）、和物理实现（realization）。
② 在计算机设计中，一旦设计实现人员有了对手册的模糊设想，对技术有了相对清晰的构想以及拥有适当的成本和目标时，实现人员的工作就开始了。他可以设计数据流、控制序列、进行总体概念包装等；设计所需的工具以及进行相应的调整，特别是记录存档系统和设计自动化系统；在物理实现的阶段，对于电路、板卡、线缆、机箱、电源和内存，必须分别设计、细化和编制文档。
③ 在编程系统的设计中，只要有一些最终将并入外部说明的系统功能雏形时，实现人员的工作就可以开始了。设定良好定义的时间和空间目标，了解产品运行的平台配置；设计模块的边界、表结构、路径和阶段分解、算法以及所有的工具；在物理实现阶段，处理在库调整、系统管理以及搜索和排序算法的编写。

画蛇添足

1、聚沙成塔，集腋成裘。（Add little to lillte and there will be a big pile.）

2、结构师的交互准则和机制
① 开发人员承担创造性和发明性的实现责任，所以结构师只能建议而不能支配；
② 时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任意能达到目标的方法；
③ 对上述的建议保持低调和不公开；
④ 准备放弃坚持所作的改进建议。

3、自律 – 开发第二个系统所带来的后果
① 第二个系统时设计师们所设计的最危险的系统。
② 开发第二个系统所引起的后果另一个表现与纯粹的功能修饰和增强明显不同，也就是说存在对某些技术进行细化、精炼的趋势。
③ 结构师避免开发第二个系统所引起的后果：有意识地关注这个系统的特殊危险，运用特别的自我约束准则；根据系统基本理念及目的变更，舍弃一些功能。
④ 项目经理避免开发第二个系统引起的后果：必须坚持至少拥有两个系统以上开发经验结构师的决定；保持度特使诱惑的警觉；不断提出正确的问题，确保原则上的概念和目标在详细设计中得到完整的体现。

贯彻执行

1、文档化的规格说明——手册
① 手册要描述包括所有界面在内的用户课件的一切，还有避免描述用户看不见的事物。
② 规格说明的风格必须清晰、完整和准确。

2、形式化定义
① 形式化定义是精确地，倾向完整，差异月明显，填补得越快。
② 形式化定义是一种设计实现，设计实现也可以作为一种形式化定义的方法。
③ 使用实现作为一种定义的方式有一些优点：所有问题可以通过试验清晰地得到答案，从来不需要争辩和商讨；通过定义得到的答案，总是同所要求的一样精确和正确。
④ 实现作为定义的方式存在的缺点：实现可能更加过度地规定了外部功能；作为一种定义，实现体现了更多的内容；定义不然描述了系统必须做什么，还声明了自己到底要做什么；当实现充当标准时，必须防止对实现的任何修改。

3、直接整合
直接整合设计被传递参数或共享存储器的声明，并要求编程实现在编译时的一些操作来包含这些声明。

4、会议和大会

5、多重实现

6、电话日志

7、产品测试
设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手，与设计同时实施的重要环节。

为什么巴比伦塔会失败

1、巴比伦塔的管理教训
① 一个项目做得好的几个先决条件：清晰的目标、人力、材料、足够的时间、足够的技术。
② 项目失败的原因在与缺乏两个方面：一是交流；而是交流的结果——组织。

2、大型编程项目中的交流
团队进行相互之间的交流沟通：非正式途径（清晰定义小组内部的相互关系和充分利用电话）、会议、工作手册。

3、项目工作手册
① 项目工作手册不是一篇独立的文档，是对项目必须产出的一系列文档进行组织的一种结构。项目所有的文档都必须是该结构的一部分，包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。
② 项目手册能保证文档的结构本身是规范的，使用项目手册可以控制信息发布。
③ 项目手册的第一步是对所有的备忘录编号、工作手册必须是最新的。

4、大型编程项目的组织架构
① 团队组织的目的是减少所需的交流和合作的数量。
② 减少交流的方法是人力划分（division of labor）和限定职责范围（specialization of function）
③ 产品负责人和技术主管的区别：产品负责人组建团队，划分工作及制定进度表；技术主管对设计进行构思，识别系统的子部分，提供整个设计的一致性和概念完整性，控制系统的复杂程度，提供问题的解决方案。

胸有成竹

1、实践是最好的老师。但智者还能从其他的地方得到收获。
（前一句话是大多数人知道的至理名言，但后一句话才是区别普通人和智者的。我们总以为自己努力就会有收获，但聪明的人不仅学的快，效率还高。）

2、估计系统编程方法：计划进度、编码、构建测试和系统测试的比率。

3、Portman的数据
Portman发现他的编程队伍落后进度的大约1/2，每项工作花费的时间大约是估计的2倍。

4、Aron的数据
Joel Aron，根据程序员和系统部分之间的交互划分系统，得到如下的生产率：

5、Harr的数据

6、OS/360的数据
生产率会根据任务本身复杂度和困难程度表现出显著差异。

7、Corbato的数据
对常用编程语句而言，生产率似乎是固定的，这个固定的生产率包括了编程中需要注释并困难存在错误的情况。
使用适当的高级语言，编程的生产率可以提高5倍。

削足适履

1、作为成本的程序空间
规模是软件系统产品用户成本中很大的一个组成部分，开发人员必须设置规模的目标，控制规模。

2、规模控制
① 仅对核心程序设定规模目标是不够的，必须把所有方面的规模都编入预算。
② 为每个单元设立核心规模的同事，需要设置访问的预算。
③ 和制定驻留空间预算一样，应该制定总体规模的预算；和制定规模预算一样，应该制定后台存储访问的预算。

3、空间机能

4、数据的表现形式是编程的根本

提纲挈领

1、计算机产品的文档
目标、技术说明、进度、预算、组织结构图、做空间的分配、报价、预算、价格。

2、大学科系的文档
目标、课程描述、学位要求、研究报告、课程表和课程的安排、预算、教室分配、教室和研究生助手的分配。

3、软件项目的文档
内容（目标、产品技术说明）、时间（进度）、资金（预算）、地点（工作空间分配）、人员（组织图）。

4、为什么要有正式的文档
① 书面记录决策时必要的。
② 文档能够作为同其他人的沟通渠道。
③ 项目经理的文档可以作为数据基础和检查列表。（项目经理的任务是制定计划并实现计划）

未雨绸缪

1、不变只是愿望，变化才是永恒。（There is nothing in this world constant but inconstancy.）
—— SWIFT

2、试验性工厂和增大规模
系统的丢弃和重现设计可以一步完成，也可以一块块地实现，新的系统概念或新技术会不断出现，必须构建一个用来抛弃的系统。
为舍弃而计划，无论如何，你一定要这样做。

3、唯一不变的就是变化本身
目标上的变化、设计策略和技术上的变化不可避免。抛弃原型概念本身就是对事实的接受——锁着学习的过程更改设计。

4、为变更设计系统
① 细致的模块化、可扩展的函数、精确完整的模块间接口设计和完备的文档。
② 采用包括调用队列和表驱动的技术。
③ 使用高级语言和自文档技术。

5、为变更计划组织架构

6、前进两步，后退一步

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

干将莫邪

1、谚语： 巧匠因他的工具而出名。（A good workman is known by his tools）