【软件工程】人月神话

编程语言学习中，人月神话(The Mythical Man-Month: Essays on Software Engineering)是一本关于“软件工程”和“项目管理”的书，由Fred Brooks写于1975。有趣的是，在1995的版本中，作者增加了对自己之前观点的评价。希望对大家编程语言的学习有所帮助，下面是书中各章节的主要观点。

1. 焦油坑

· 系统产品的开发工作量是个人产品/构件程序的工作量的9倍。

· 编程行业在于创造，在于学习。

2. 人月神话

· 缺乏合理的时间进度是造成项目滞后的主要原因。

· 关于进度安排，我的经验是：1/3计划，1/6编码，1/4构件测试，1/4系统测试。

· Brook法则：向进度落后的项目增添人手，只会使进度更加落后。

3. 外科手术队伍

· Sackman、Erikson和Grand：同样有两年经验而且在收到同样培训的情况下，优秀的专业程序员的工作效率是较差程序员的10倍。

· 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法——既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。

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

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

· “对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。”[同样适用于小型项目。]

· 体系结构（architecture）、设计实现（implementation）、物理实现（realization）的许多工作可以并发进行。[软件和硬件设计同样可以并行。]

5. 画蛇添足

· 尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。

· 牢记是开发人员承担创造性的实现责任；结构师只能提出建议。

· 时刻准备着为所指定的说明建议一种实现的方法，准备接受任何其他可行的方法。

· 为功能分配一个字节和微秒的优先权值是一个很有价值的规范化方法。（笔者：我觉得这是对汇编编程有效的，高级语言编程请进行类比。）

6. 贯彻执行

· 即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的。

· 必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致。

· “项目经理最好的朋友就是他每天要面对的敌人——独立的产品测试机构/小组。”

7. 为什么巴比伦塔会失败

· 巴比伦塔项目的失败是因为缺乏交流，以及交流的结果——组织。

· 交流 

· 由于对其他人的各种假设，团队成员之间的理解开始出现偏差。

· 团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。

· 组织 

· 团队组织的目标是为了减少必要的交流和协作量。

· 为了减少交流，组织结构包括了人力划分（division of labor）和限定职责范围（specialization of function）。

· 传统的树状组织结构反映了权力的结构原理——不允许双重领导。

· 组织中的交流是网状，而不是树状结构，因而所有的特殊组织机制（往往体现成组织结构图中的虚线部分）都是为了进行调整，以克服树状组织结构中交流缺乏的困难。

8. 胸有成竹

· IBM的Aron数据显示，生产率是系统各个部分交互的函数，在1.5K千代码行/人年至10K千代码行/人年的范围内变化。

· Harr的Bell实验室数据显示对于已完成的产品，操作系统类的生产率大约是0.6KLOC/人年，编译类工作的生产率大约为2.2KLOC/人年。

· Brooks的OS/360S数据与Harr的数据一致：操作系统0.6～0.8KLOC/人年，编译器2～3 KLOC/人年。

9. 削足适履

· 除了运行时间以外，所占据的内存空间也是主要开销。特别是对于操作系统，它的很多程序是永久驻留在内存中。

· 规模预算不仅仅在占据内存方面是明确的，同时还应该指明程序对磁盘的访问次数。

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

· 精炼、充分和快速的程序。往往是战略性突破的结果，而不仅仅技巧上的提高。这种突破常常是一种新型算法。

10. 提纲挈领

· “前提：在一片文件的汪洋中，少数文档形成了关键的枢纽，每个项目管理的工作都围绕着它们运转。它们是经理们的主要个人工具。”

· 对于计算机硬件开发项目，关键文档是目标、手册、进度、预算、组织机构图、空间分配、以及机器本身的报价、预测和价格。

· 对于软件项目，要求是相同的：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。

· 项目经理的主要日常工作是沟通，而不是做出决定；文档使各项计划和决策在整个团队范围内得到交流。

11. 未雨绸缪

· 系统的丢弃和重新设计可以一步完成，也可以一块块地实现。这是个必须完成的步骤。

· 将开发的第一个系统——丢弃原型——发布给用户，可以获得时间，但是它的代价高昂——对于用户，使用极度痛苦；对于重新开发的人员，分散了精力；对于产品，影响了声誉，即使最好的再设计也难以挽回名声。

· 高级语言的使用、编译时操作、通过引用的声明整合和自文档技术能减少变更引起的错误。

· 程序维护基本上不同于硬件的维护；它主要由各种变更组成，如修复设计缺陷、新增功能、或者是使用环境或者配置变换引起的调整。

· 所有修改都倾向于破坏系统的架构，增加了系统的混乱程度。即使是最熟练的软件维护工作，也只是放缓了系统退化到不可修复混乱的进程，从中必须要重新进行设计。

12. 干将莫邪

· 同天文工作者一样，系统调试总是大部分在夜间完成。

· 主程序库应该被划分成（1）一系列独立的私有开发库；（2）正处在系统测试下的系统集成子库；（3）发布版本。正式的分离和进度提供了控制。

· 自顶向下、彻底地开发一个性能仿真装置。尽可能早地开始这项工作，仔细地听取“它们表达的意见”。

· 有限的数据表明了系统软件开发中，交互式编程的生产率至少是原来的两倍。

13. 整体部分

· V.A.Vyssotsky提出，“许许多多的失败完全源于那些产品未精确定义的地方。”

· 系统测试期间，一次只添加一个构件。

14. 祸起萧墙

· “项目是怎样延迟了整整一年的时间？⋯一次一天。”

· 根据一个严格的进度表来控制项目的第一个步骤是制订进度表，进度表由里程碑和日期组成。

以上就是老司机们对我们的谆谆教导。话说回来，又一个20年(2016)过去了——开源运动如火如荼，各种框架你来我往，摩尔定律开始放缓；下一个20年，又会是在哪儿？

如有问题请加微信号：Iotek666，本微信号会不定期推送技术相关优质文章、热点资讯、视频资源及生活趣事，也很乐意与您一起交流IT知识，让我们在闲暇之余巩固一下自己的知识体系 ，扩充一下自己的知识面。快利用琐碎时间给自己充电吧！

希望这篇文章可以帮助到你，总之同学们，it资讯尽在职坐标。