《人月神话》读书笔记

人月神话

（如需高清无码大图可以私信）

没有银弹

软件活动包括：

• 1、根本任务：打造由抽象软件实体构成的复杂概念结构

• 2、次要任务：使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言

软件开发困难：

• 1、根本的：软件特性中固有的困难

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

软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概念进行表达和对实现逼真程度进行验证

软件系统中无法规避的内在特性：

• 1、复杂度

• 2、一致性

• 3、可变性

• 4、不可见性

以往解决次要困难的一些突破：

• 1、高级语言

• 2、分时

• 3、统一编程环境

银弹的希望：

• 1、高级编程语言

• 2、面向对象编程

• 3、人工智能

• 4、专家系统

• 5、“自动”编程

• 6、图形化编程

• 7、程序验证

• 8、环境和工具

• 9、工作站

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

• 1、购买和自行开发

• 2、需求精炼和快速原型

• 3、增量开发-增长，而非搭建系统

• 4、卓越的设计人员

整体部分

剔除bug的设计

• 1、防范bug的定义

• 2、测试规格说明

• 3、自顶向下的设计：设计是一系列精化的步骤

  • S1、勾画能得到主要结果的，但比较粗略的任务定义和大概的解决方案

  • S2、对该定义和方案进行细致的检查，以判断结果与期望之间的差距。同时，将上述步骤的解决方案在更细的步骤中进行分解

• 4、结构化编程

构件单元调试

• 本机调试

• 内存转储

• 快照

• 交互式调试

• 测试用例

系统集成调试

• 1、使用经过调试的构件单元

• 2、搭建充分的测试平台：供调试使用的所有程序和数据

  • 1、伪构件

  • 2、微缩文件

• 3、控制变更

• 4、一次添加一个控件

• 5、阶段（量子）化、定期变更

削足适履

规模控制

• 对项目经理而言，规模控制是技术以及管理工作的一部分

  • S1、研究用户和应用，设置系统的规模

  • S2、将系统划分为若干部分，并设定每个部分的规模目标

• 几个道理：

  • 1、和制订驻留空间预算一样，应该制订总体规模的预算；和制订规模预算一样，应该制订后台存储访问的预算

  • 2、在指明模块有多大的同时，确切定义模块的功能

  • 3、培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能

空间技能

• 1、用功能交换尺寸

• 2、时间-空间的折衷

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

• 创造出自精湛的技艺，技艺的改进的结果往往是战略上的突破，战略上的突破常来自于数据或表的重新表达，这是程序的核心所在

画蛇添足

结构师的交互准则和机制

• 1、牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，不能支配

• 2、时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法

• 3、对上述建议保持低调和平静

• 4、准备放弃坚持所作的改进建议

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

• 产生原因：设计第一个系统时结构师会面对不断产生的润色功能，这些功能被搁置，成为下一个项目的内容。做下一个项目时，结构师信心十足，会向系统添加大量修饰功能和想法，然而很多是画蛇添足之举

• 结构师无法跳过第二个系统，但他可以有意识关注那个系统的特殊危险，运用特别的自我约束准则来避免那些功能上的修饰；根据系统基本理念及目的变更，舍弃一些功能

• 项目经理为了避免画蛇添足，必须坚持至少拥有两个系统以上开发经验结构师的决定

焦油坑

编程系统产品

职业的乐趣

• 1、创建事物

• 2、开发对他人有用的东西

• 3、组装的魔力

• 4、学习的乐趣

• 5、工作的介质易于驾驭

职业的苦恼

• 1、追求完美

• 2、无法控制的目标、资源和信息

• 3、琐碎的BUG

• 4、易于陈旧

人月神话

项目滞后的最主要原因：

缺乏合理的时间进度

• 1、缺乏有效的估算技术

• 2、误以为人和月可以互换

• 3、难以持续耐心地估算

• 4、对进度缺少跟踪和监督

• 5、单纯增加人力只会火上浇油

乐观主义：所有的

编程人员都是乐观主义者

• 原因：介质易于驾驭，我们期待在实现过程中不会碰到困难；然而我们的构思是有缺陷的

人月

• 用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间可以相互替换。实际上，添加人手需要更多的交流成本，反而延长了时间进度。

• Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后

软件任务进度安排

• 1/3 计划

• 1/6 编码

• 1/4 构件测试和早期系统测试

• 1/4 系统测试（不为系统测试安排足够的时间简直就是一场灾难）

贯彻执行

文档化的规格说明-手册

• 手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样，它也是结构师主要的工作产物

形式化定义

会议和大会

• 周例会：每周半天，所有结构师、硬件和软件实现人员代表和市场计划人员参与，由首席系统结构师主持

  • 在会议之前，任何人可以提出问题和意见，以书面形式

  • 对详细的变更建议作出决策

  • 卓有成效的原因

    • 1、数月内，相同小组的结构师、用户和实现人员每周交流一次，因此大家对项目内容比较熟悉，不需要安排额外时间进行培训

    • 2、上述小组十分睿智和敏锐，深刻理解所面对的问题，并且与产品密切相关。没有人是“顾问”的角色，每个人都要承担义务

    • 3、当问题出现时，在界限的内部和外部同时寻求解决方案

    • 4、正式的书面建议集中了注意力，强制了决策的制定，避免了会议草稿纪要方式的不一致

    • 5、清晰地授予首席结构师决策的权力，避免了妥协和拖延

• 年度大会：随着时间推移，一些决定没有很好地贯彻，这些问题周例会没有重新考虑，慢慢的，小问题就会积累。为了解决这些积累的问题，举行年度大会，一般持续两周

提纲挈领

为什么要有正式的文档

• 1、书面决策是必要的

• 2、文档能够作为同其他人的沟通渠道

• 3、项目经理的文档可以作为数据基础和检查列表

祸起萧墙

里程碑还是沉重的负担

• 根据进度表来控制项目，进度表上的每一件事被称为“里程碑”。好的里程碑对团队来说实际上是一项服务，可以用来向项目经理提出合理要求的一项服务，而不确切的里程碑是难以处理的负担。

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

• 必须关系每一天的滞后，它们是大灾祸的基本组成元素

地毯的下面

• 一线经理发现问题后，并不会立即向老板汇报，而是自己想办法解决。因此，所以污垢都被隐藏在地毯之下。两个把污垢展现给老板的方法：

  • 1、减少角色冲突：老板要区别行动信息和状态信息

  • 2、猛地拉开地毯：不论协作与否，了解状态真相的评审机制是必要的

胸有成竹

Portman的数据

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

Aron的数据

Harr的数据

OS/360的数据

Corbato的数据

• 对常用编程语言而言，生产率似乎是固定的，这个固定的生产率包括了编程中需要注释、并可能存在错误的情况

• 使用适当的高级语言，编程的效率可以提高5倍

干将莫邪

目标机器

• 目标机器是软件所服务的对象，程序必须在该机器上进行最后的测试

辅助机器和数据服务

• 辅助机器是那些在开发系统中提供服务的机器

高级语言和交互式编程

• 使用高级语言的主要原因是生产率和调试速度

未雨绸缪

为舍弃而计划

唯一不变的就是变化本身

为变更计划系统

• 细致的模块化、可拓展的函数、精确完整的模块间接口设计、完备的文档，可能还有调用队列和表驱动的一些技术

• 最重要的措施是使用高级语言和自文档技术，以减少变更引起的错误

为变更计划组织架构

• 设计人员不愿意为设计书写文档的原因，不仅仅是惰性或时间压力。相反，设计人员通常不愿意提交尝试性的设计决策，再为它们进行辩解

前进两步，后退一步

• 软件维护主要包含对设计缺陷的修复，而缺陷修复总会以20%-50%的几率引入新的bug

前进一步，后退一步

• 所有修改都倾向于破坏系统的架构，增加系统的混乱程度。随着时间的推移，系统变得越来越无序，修复工作迟早失去根基。每一步前进都伴随着一步后退

为什么巴比伦塔

会失败

巴比伦塔的管理教训

• 他们具有的条件

  • 清晰的目标

  • 人力

  • 材料

  • 足够的时间

  • 足够的技术

• 他们失败的因素

  • 交流

  • 组织

大型编程项目中的交流（沟通途径）

• 1、非正式的途径：清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通，从而达到对所写文档的共同理解

• 2、会议：常规项目会议，团队一个接一个地进行简要的技术陈述。这种方式非常有用，能澄清成百上千的细小问题

• 3、工作手册：在项目的开始阶段，应该准备正式的项目工作手册。

项目工作手册

• 是什么：对项目必须产出的一系列文档进行组织的一种结构。项目所有的文档都必须是该结构的一部分

• 为什么：技术说明必不可少；控制信息发布

• 处理机制：每间办公室应保留一份工作手册的拷贝。工作手册的实时性很关键，所以采用活页夹的方式，仅仅更换变更页

大型编程项目的组织架构

• 团队组织的目的是减少不必要的交流和合作的数量

• 减少交流的方法是人力划分和限定职责范围

• 树状编程队伍，为使它行之有效，每棵子树必须具备的基本要素：

  • 1、任务

  • 2、产品负责人：组建团队，划分工作及制定进度表，要求必要的资源，确保进度目标的实现

  • 3、技术主管和结构师：构思设计，识别系统的子部分，提供设计的一致性和完整性；控制系统复杂程度；提供问题解决方案

  • 4、进度

  • 5、人力的划分

  • 6、各部分之间的接口定义

• 技术作为总指挥，产品负责人充当其左右手。这是对小型团队最好的选择

另外一面

需要什么样的文档

• 使用程序

  • 1、目的：主要功能是什么？开发程序原因是什么？

  • 2、环境：程序运行在什么样的机器、硬件配置和操作系统上？

  • 3、范围：输入的有效范围是什么？允许显示的合法范围是什么？

  • 4、实现功能和使用的算法。精确地阐述它做了什么

  • 5、输入-输出格式。必须是确切和完整的

  • 6、操作指令。包括控制台及输出内容中正常和异常结束的行为

  • 7、选项。用户的功能选项有哪些？如何在选项之间进行挑选？

  • 8、运行时间。在指定的配置下，解决特定规模问题所需要的时间？

  • 9、精度和校验。期望结果的的精确程度？如何进行精度的检测？

• 验证程序

  • 1、针对遇到的大多数常规数据和程序主要功能进行测试的用例

  • 2、数量相对较少的合法数据测试用例

  • 3、数量相对较少的非法数据测试用例

• 修改程序

  • 1、流程图或子系统的结构图

  • 2、对所用算法的完整描述，或者对文档中类似描述的引用

  • 3、对所有文件规划的理解

  • 4、数据流的概要描述-从磁盘或磁带中，获取数据或程序处理的序列-以及在每个处理过程中完成的操作

  • 初始设计中，对已预见修改的讨论；特性、功能回调的位置以及出口；原作者对可能扩充的地方以及可能处理方案的一些意见。另外，对隐藏缺陷的观察也同样很有价值

流程图

• 一页纸的流程图，成为表达程序结构、阶段或步骤的一种非常基本的图示

自文档化的程序

• 将文档整合到源代码

  • 方法1、借助那些出于语言的要求而必须存在的语句，来附加尽可能多的“文档”信息

  • 方法2、尽可能地使用空格和一致的格式提高程序的可读性，表现从属和嵌套关系

  • 3、以段落的形式，向程序中插入必要的记叙性文字

贵族专制、民主政治

和系统设计

概念一致性

• 在系统设计中，概念完整性是最重要的考虑因素。即为了反应一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统

获得概念的完整性：目标是易用性，易用性需要设计的一致性和概念上的完整性

• 在语义上，应具有同样的相似性

• 在语法上，每个部分应使用相同的技巧

• 每个部分必须反映相同的原理、原则和一致的折衷机制

贵族专制和民主政治

• 贵族：结构师；人民：实现人员

• 结构师和实现人员都有创意，但创意要符合系统的概念完整性

• 只能存在少量结构师，他们处于贵族专制的地位。为了系统概念完整性，他们必须控制概念

• 外部技术说明与具体实现都富有创造性。

• 外部的体系结构实际上增强了而不是限制实现小组的创造性

外科手术队伍

问题

• 精干队伍效率非常高，但开发大型系统时仍然远远不够，只能需要大量人手。这两者矛盾需要调和

Mills的建议

• 10人的编程队伍角色分工-Mills建议项目队伍以类似外科手术的方式组建，每一部分由一个团队解决。即一个人进行问题分解，其他人给予其所需的支持

  • 外科医生：首席程序员，极高的天分，十年的经验，及其他知识

    • 定义功能和性能技术说明书

    • 设计程序

    • 编制源代码

    • 测试以及书写技术文档

  • 副手：外科医生后备，能完成一部分工作，但经验较少

    • 设计的思考者、讨论者和评估人员

  • 管理员：外科医生是老板，在人员、加薪方面具有决定权，但不能在这些事物上浪费时间，需要有人管理

  • 编辑：外科医生负责产生文档，编辑需要根据外科医生草稿或口述进行分析和重新组织

  • 两个秘书：管理员和编辑各需要一个

  • 程序职员：维护编程产品库中所有团队的技术记录

  • 工具维护人员：保证所有基本服务的可靠性

  • 测试人员：外科医生需要大量测试用例进行测试

  • 语言专家：寻找一种简洁、有效的使用语言的方法解决复杂问题

如何运作：“两人队伍”与“外科医生-副手”的区别

• 1、传统团队中每人负责一部分任务；外科手术团队中，外科医生和副手都了解所有的设计和全部代码

• 2、传统队伍人人平等，出现问题需要讨论和妥协；外科手术团队中由外科医生当方面决定

团队的扩建

• 扩建过程的成功依赖于：每个部分的概念完整性得到了彻底的提高