《人月神话》读书笔记

 

焦油坑

1.

 “要成为通用的编程产品，程序必须按照普遍认可的风格来编写，特别是输入的范围和形式必须广泛地适用于所有可以合理使用的基本算法。接着要对程序进行彻底测试，确保它的稳定性和可靠性，使其值得信赖。。。。此外，还需要有完备的文档。”

 

阅读了这里对于编程产品的特性的描述，可见一个程序要真正成为一个编程产品，还需要一些特别的注意点：第一，程序必须按照普遍认可的风格来编写；第二，必须对程序进行彻底的测试；第三，还要有完备的文档。这些注意点我在以后去实际编写真正的编程产品时也会注意。

 

 

 

人月神话

2.

 “用人月作为衡量一项工作的规模是一个危险和具有欺骗性的神话。”“向进度落后的项目中增加人手，只会使进度更加落后。”

 

第一句话可以说是这本书的点题之笔，“人月神话”由此而来。确实，很多情况下，特别是对于无法分解的任务，增加人手并不会减少完成任务所需要的时间。这在以后的项目进度安排中要特别注意。

而第二句话则是对Brooks法则的简化，但也非常明确地说明了在进度落后时盲目增加人手的危害，必须要考虑到因增加人手而引发的培训、任务划分、交流的问题。

 

 

 

3.

“理论上，缺陷的数量应该为零。但是，由于我们的乐观主义，通常实际出现的缺陷数量要比预料的要多得多。”

 

这一点，作为一名程序员可以说是深有体会。很多时候，当我们完成一个项目的编码过程之后，由于乐观主义，总是会祈祷不会出现缺陷。然后，大部分甚至说所有的情况下，都会出现多得多的缺陷，甚至很多时候消除缺陷需要花费的时间比之前编写项目代码的还要多。

 

 

 

外科手术队伍

4.

”外科医生。Mills称之为首席程序员。他亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档。““副手”“管理员”“编辑”“两个秘书，管理员和编辑每个人需要一个秘书”“程序职员”“工具维护人员”“测试人员”“语言专家”

 

此处非常详细地描述了一个完备的程序开发团队应该包括的人员及各自的角色，给我们以后组建程序开发团队提供了很好的借鉴。当然，这是非常理想化的情况，如果在成本允许的情况下能做到这样是最好的，但其中比如管理员和编辑都要配秘书、要有专门的工具维护人员，这些可能在实际情况下要做到还是挺难的。

 

 

 

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

 

5.

“概念完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。”“体系结构同实现必须仔细地区分开来。”

 

这解释了为什么要让少数所谓的“贵族”来“专制统治”，让他们来进行整体的体系结构等的设计，让他们来指导可怜的实现人员如何工作。并不是说不能“民主”，难道员工中就不会有好的创意吗？肯定是有的。但是为了保证系统概念上的完整性，就必须控制解决用户问题，实现用户利益的这些概念，把这些概念控制在少数精英手中，避免出现很多不错但是不兼容的构想。因此，这是一种无需歉意的贵族专制统治。

 

 

 

 

画蛇添足

6.

“结构师必须牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配；时刻准备着为指定的说明建议一种实现的方法，同样准备接受任何能达到目标的方法；对上述的建议保持低调和平静；准备放弃坚持所做的改进建议。”

 

这段话对结构师做出了中肯的提醒，必须要牢记真正承担实现责任的师开发人员，自己只能建议，而不能支配，毕竟你没有亲手去做。通常情况下开发人员对体系结构上修改建议的反对是对的，当正在实现产品时，某些特性修改会产生意想不到的成本开销。

 

 

 

贯彻执行

文档化的规格说明——手册

手册、或者书面规格说明，是一个非常必要的工具。手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节;同样的，它也是结构师主要的工作产物。

规格说明也不断地被重复准备和修改。

在进度表上应该有带日期的版本信息。

手册不但要描述包括所有界面在内的用户可见的一切，它同时还要避免描述用户看不见的事物。后者是编程实现人员的工作范畴，而实现人员的设计和创造是不应该被限制的。体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该试图支配具体的实现过程。

规格说明的风格必须清晰、完整和准确。

为什么巴比伦塔会失败?

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

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

产品负责人的角色是什么?他组建团队，划分工作及制订进度表。他要求，并一直要求必要的资源。

产品负责人和技术主管是同一个人。

第二，大型项目中，每个角色都必须全职工作，甚至还要加班。

产品负责人作为总指挥，技术主管充当其左右手。”

 

巴比伦塔失败的根本原因就在于缺乏交流和了合理的组织，我们在软件项目开发过程中要特别注意这两点。

 

胸有成竹

编译器的复杂度是批处理程序的三倍，操作系统复杂度是编译器的三倍。

 

削足适履

空间技能

用功能交换尺寸。

设计人员必须决定用户可选项目的粗细程度。

考虑空间-时间的折衷。

提纲挈领

计算机产品的文档

报价、预测、价格:这三个因素互相牵制，决定了项目的成败。

为什么要有正式的文档

首先，书面记录决策是必要的。      

第二，文档能够作为同其他人的沟通渠道。

最后，项目经理的文档可以作为数据基础和检查列表。

 

未雨绸缪

为变更计划系统

如何为上述变化设计系统，它们包括细致的模块化、可扩展的函数、精确完整的模块间接口设计、完备的文档。另外，还可能会采用包括调用队列和表驱动的一些技术。

最重要的措施是使用高级语言和自文档技术。

变更的阶段化是一种必要的技术。

 

干将莫邪

“项目经理应该制订一套策略，并为通用工具的开发分配资源。”

 

看了这个部分，更加意识到通用工具的重要性。

辅助机器和数据服务

这有两个重要的理念。首先是受控，即程序的拷贝属于经理，他可以独立地授权程序的变更。其次是使发布的进展变得正式，以及开发库与集成、发布的正式分离。

 

没有银弹-软件工程中的根本和次要问题

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

所有软件活动包括根本任务——打造由抽象软件实体构成的复杂概念结构，次要任务——使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。

即使全部次要任务的时间缩减到零，也不会给生产率带来数量级上的提高。

介绍

大家熟悉的软件项目具有一些人狼的特性(至少在非技术经理看来)，常常看似简单明了的东西，却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。

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

这样的畸形并不是由于软件发展得太慢，而是因为计算机硬件发展得太快。

根本的——软件特性中固有的困难，次要的——出现在目前生产上的。

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

现代软件系统中这些无法规避的内在特性:复杂度、一致性、可变性和不可见性。

复杂度

没有任何两个软件部分是相同的。

软件实体的扩展也不仅仅是相同元素重复添加，而必须是不同元素实体的添加。

软件的复杂度是必要属性，不是次要因素。

上述软件特有的复杂度问题造成了很多经典的软件产品开发问题。由于复杂度，团队成员之间的沟通非常困难，导致了产品瑕疵、成本超支和进度延迟;由于复杂度，列举和理解所有可能的状态十分困难，影响了产品的可靠性;由于函数的复杂度，函数调用变得困难，导致程序难以使用;由于结构性复杂度，程序难以在不产生副作用的情况下用新函数扩充;由于结构性复杂度，造成很多安全机制状态上的不可见性。

复杂度不仅仅导致技术上的困难，还引发了很多管理上的问题。它使全面理解问题变得困难，从而妨碍了概念上的完整性;它使所有离散出口难以寻找和控制;它引起了大量学习和理解上的负担，使开发慢慢演变成了一场灾难。

一致性

他必须控制的很多复杂度是随心所欲、毫无规则可言的，来自若干必须遵循的人为惯例和系统。

可变性

系统中的软件包含了很多功能，而功能是最容易感受变更压力的部分。另外的原因是因为软件可以很容易地进行修改——它是纯粹思维活动的产物，可以无限扩展。

软件必须与各种新生事物保持一致。

不可见性

软件是不可见的和无法可视化的。

软件的客观存在不具有空间的形体特征。

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

高级语言。

大多数观察者相信开发生产率至少提高了五倍，同时可靠性、简洁性和理解程度也大为提高。

分时。

统一编程环境。提供集成库、统一文件格式、管道和过滤器。

银弹的希望

Ada和其他高级编程语言。

面向对象编程。

抽象数据类型的概念是指对象类型应该通过一个名称、一系列合适的值和操作来定义，而不是理应被隐藏的存储结构。

层次化类型，是允许定义可以被后续子类型精化的通用接口。这两个概念是互不相干的——可以只有层次化，没有数据隐藏;也可能是只有数据隐藏，而没有层次化。

人工智能。

专家系统。专家系统是包含归纳推论引擎和规则基础的程序，它接收输入数据和假设条件，通过从基础规则推导逻辑结果，提出结论和建议，向用户展示前因后果，并解释最终的结果。

如何把它应用在软件开发工作中?可以通过很多途径:建议接口规则、制订测试策略、记录各种bug产生的频率、提供优化建议等等。

最优秀和一般的软件工程实践之间的差距是非常大的，可能比其他工程领域中的差距都要大。

“自动”编程。

图形化编程。

程序验证。程序验证不意味着零缺陷的程序。

环境和工具。特定语言的智能化编辑器在现实中还没有得到广泛应用，不过它们最有希望实现的是消除语法错误和简单的语义错误。

工作站。

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

工作的创造性部分占据了大部分时间，那么那些仅仅是表达概念的活动并不能在很大程度上影响生产率。

购买和自行开发。构建软件最可能的彻底解决方案是不开发任何软件。

需求精炼和快速原型。开发软件系统的过程中，最困难的部分是确切地决定搭建什么样的系统。

软件开发人员为客户所承担的最重要的职能是不断重复地抽取和细化产品的需求。事实上，客户不知道他们自己需要什么。

计划任何软件活动时，要让客户和设计人员之间进行多次广泛的交流沟通，并将其作为系统定义的一部分。这是非常必要的。

原型的目的是明确实际的概念结构，从而客户可以测试一致性和可用性。

增量开发——增长，而非搭建系统。

卓越的设计人员。

    低劣设计和良好设计之间的区别可能在于设计方法中的完善性，而良好设计和卓越设计之间的区别肯定不是如此。卓越设计来自卓越的设计人员。软件开发是一个创造性的过程。完备的方法学可以培养和释放创造性的思维，但它无法孕育或激发创造性的过程。

非常卓越的设计者产生的成果更快、更小、更简单、更优雅，实现的代价更少。卓越和一般之间的差异接近于一个数量级。

可以着手的最重要工作是寻求培养卓越设计人员的途径。

 

20年后的人月神话

7.

“软件项目管理更加类似于其他类型的管理。”

 

这给我们学习、研究软件项目管理提供了一个很好的思路，我们可以通过挖掘它与其他类型的管理之间的相似点，通过学习其他类型的管理来对软件项目的管理提供帮助。

 

 

8．

“体系结构的递归。”“”有必要由一位主结构师把系统分解成子系统，系统边界应该划分在使子系统间接口最小化和最容易严格定义的地方。“

 

这是非常有价值的体系结构的分解思路，把大的系统分解成子系统，并且值得注意的是子系统的边界如何划定是一个很关键的点。这对我们以后分解系统进行体系结果设计提供了指导性思想，这也是《人月神话》这本书20年后还依然如此毫不过时的重要原因，它其中的思想放到现在仍然适用。