人月神话读书笔记_frederickp.brooks.jr、人月神话、狼人、银弹、没有银弹根据所列关键词,写一

 

这篇博客是在阅读了北卡罗莱纳大学Frederick P.Brooks,Jr.教授的The Mythical Man-Month之后所写。

 

"编程：一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动"。

虽然我们还没有真正到步入软件开发这个行业，但是作为软院的学生，我已经深深感受到了软件开发的乐趣和苦恼。特别在一个团队中进行开发时，刚开始的设计和编码，总是一种创造的乐趣，可是老师开始催进度，或者是课程一多起来，这时压力也大了起来，如果在进度可能不能按时完成时又遇到一个瓶颈，这种沮丧是无法言表的。或许这就是类似作者所说的焦油坑，而这就是编程。

 

"向进度落后的项目增加人手，只会使进度更加落后"。

这是众所周知的人月神话中最著名的一个法则。当任务由于次序上不能被分解的时候，人手的添加对进度没有帮助，”无论多少个母亲，孕育一个生命都需要十个月“。在相同人月的前提下，采用增加人手来减少时间得到的最好情况，也比未调整前要差一些。在添加了人手之后需要对新进人员进行培训，而且组员之间的交流也需要花费更多时间。这样很可能会导致二次滞后，再增加人员只会形成恶性循环，这个项目经理应该也要走人了。"项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量"。这与流水线的设置有点类似，这样可以推算出项目的进度时间表。不过大部分软件都会存在的一个风险就是在项目完工时可能就过时了。因此需要一个人月折中。

 

"如果一个200 人的项目中，有25 个最能干和最有开发经验的项目经理，开除剩下的175 名程序员，让项目经理来编程开发"。

总有人偏好小型、精干的队伍，这样具有更高的效率，而不是那些几百人的大型团队，但是对于大型项目来说，太慢了。想象下在OS/360开发的巅峰时期，有1000个人在为它工作，团队中的沟通交流成本得多高？这样的团队要怎么组织？Mills提供了一个外科手术队伍的概念：

•  外科医生：团队需要一个能够从上至下统领所有的外科医生，也就是首席程序员；
•  副手：再能干的外科医生也需要有个副手协助，作为外科医生的后备；
• 管理员：管理员充当与组织中其他管理机构的接口；
• 编辑：由于文档在软件开发的重要性，所有需要有专门的编辑；
•  两个秘书：编辑和管理员每个人都需要一个秘书；
•  程序职员：再好的设计也要付诸实践才能体现价值，程序职员挑起了重担；
• 在开发中肯定会使用到工具，实现的产品也要测试，可能还会涉及专业难题，所以还需要工具维护人员、测试人员、语言专家等角色。

总的来说，外科医生队伍这种思路是可行的，但是实际操作过程中，上述角色到底要怎么划分协调，需要多少人员参与，这还需要丰富的经验来决策。

 

"概念完整性是系统设计中最重要的考虑因素"。

继续说团队组成的角色和分工。我们已经知道了大型项目可能会有很多人参与，那么到底由谁来进行设计，由多少人来进行实现呢？在设计阶段时，实现人员又要干些什么呢？

总是把软件架构与建筑进行类比，就像一个城市的建筑风格总是统一的，软件概念完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现，贵族系统结构师扮演了重要角色。而进度压力却要求很多人员来开发系统，这时需要详细地区分设计方法和具体实现，或者组织像外科医生队伍那样的新型队伍来解决这个矛盾。

在设计阶段，大量的平民实现人员只能等待着。但如果划分的合理的话，软件开发活动其实是有很多重叠的部分。把整个系统划分为三个独立阶段：体系结构、设计实现、物理实现，发现开发变的更快而不是更慢。所需要的测试时间将更少。同工作的水平分割相比，垂直划分从根本上大大减少了劳动量，结果是使交 流彻底地简化，概念完整性得到大幅提高。

 

"保持对特殊诱惑的警觉"。

在开发第一个系统的时候，结构师倾向于精炼和简洁，但是他总是经不住诱惑，向第二个系统中添加很多修饰功能和想法，尽管很多都是没有用的，这就是画蛇添足了。结构师可以有意识关注那些系统的特殊危险，运用特别的自我约束准则，来避免那些功能上的修饰；根据系统基本理念及目的变更，舍弃一些功能。

 

"巴比伦塔可能是第一个工程上的彻底失败，但它不是最后一个"。

巴比伦塔失败不是因为时间不够、材料不够，而是因为缺乏两个方面——交流，以及交流的结果——组织。他们无法相互交谈，从而无法合作。一个团队的沟通方式有多种：非正式途径、会议、工作手册等，团队的组织又可以参考外科医生队伍的组织。这个例子可以看出团队交流的重要性，即使交流的成本很高，但是这是无法避免的。

口头的交流是一种方式，正式的文档也是一种重要形式。只有书面记录下决策，分歧才会明朗，矛盾才会突出，也为后面的上百次的细小改变创造了可能性，项目经理还可以把文档作为数据基础和检查列表。

 

"唯一不变的就是变化本身"。

用户的实际需求和用户感觉会随着程序的构建、测试和使用而变化。要做到未雨绸缪，轻松应对变化。例如：

• 在设计软件架构时要考虑到架构的易变性；
• 为变更做计划，包括模块化、可扩展的函数、接口、完备的文档等。最重要的措施是使用高级语言和自文档技术，以减少变更引起的错误。
• 前进两步，后退一步。"程序维护中的一个基本问题是——缺陷修复总会以（20－50 ）% 的机率引入新的bug 。所以整个过程是前进两步，后退一步"。
• 前进一步，后退一步。"系统软件开发是减少混乱度（减少熵）的过程，所以它本身是处于亚稳态的。软件维护是提高混乱度（增加熵）的过程，即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的进程"。

 

"在近十年内，没有任何单独的软件工程进展可以使软件 生产率有数量级的提高"。——《没有银弹》

《没有银弹》一经出版就引发了大量的讨论，直到现在还是。人月神话的作者认为软件工程中主要存在两类问题：根本问题和次要问题。现代软件系统中无法规避的内在特性包括了：复杂度、一致性、可变性和不可见性。其中复杂度是必要属性，是严重的内在困难，而不是次要因素。虽然高级语言、统一编程环境等工具的使用解决了一部分的困难，却无法改变根本内在困难。但即使在这样的困境中，任然存在一些希望：其他高级编程语言、面向对象编程、人工智能、专家系统、自动编程、图形化编程、程序验证和更强大的工作站。但是我们不能期望有魔术般的提高。针对概念上根本问题的颇有前途的方法包括：购买软件、快速原型开发、增量开发（一种鼓舞人心的开发方法）和卓越的设计人员。

程序开发人员大部分都是乐观主义，所以我相信即使根本困难也是有希望的。

 

《人月神话》一书的内涵绝不是这篇粗糙的博文可以详尽介绍的，在以后还需要反复研读才行。

 

注：双引号斜体字引自《人月神话》