一句话简介：
上着软件工程的课看这么出名的书，略深涩望日后结合实践拜读。
我看的是《人月神话》20周年的纪念版，按出版年头来算，其实2015年它就是一本出版40年（1975年至今）的书了，之所以能火这么久，首先来看看作者来头——
弗雷德里克·布鲁克斯（Frederick P. Brooks, Jr.）-北卡罗莱纳大学Kenan-Flagler商学院的计算机科学教授。他曾荣获图灵奖，美国计算机协会（ACM）称赞他“对计算机体系结构、操作系统和软件工程做出了里程碑式的贡献。”
布鲁克斯被认为是** IBM 360系统之父，他曾担任360系统的项目经理、360操作系统项目设计阶段的经理。因在这两个项目中的杰出贡献，布鲁克斯和Bob Evans、Erich Bloch在1985年获得美国国家技术奖（National Medal of Technology）。布鲁克斯早期还曾担任IBM公司Stretch和Harvest计算机的体系结构设计师。布鲁克斯创立了北卡罗莱纳大学的计算机科学系，在1964-1984年期间担任系主任。他还曾任职于美国国家科技局和国防科学技术委员会。他目前的教学和研究方向是计算机体系结构、分子模型绘图和虚拟环境设计**。
全书内容即布鲁克斯在IBM公司System 360家族和OS 360中的项目管理经验。
说来惭愧，本女子每次接触到如此大牛国外名书，都看得有点云里雾里也不能怪到翻译上，不过整本书看完印象最深，最理解的莫过于标题中的** “人月”** ——用来度量工作量的单位，就是一个人一个月能干完的工作量。
有一个很恶俗的例子解释一个人做十个月完成的，十个人做一个月就完成了，即神话——10月怀胎，但如果10个人同时做，一个月就生完了？！hh。
第七章 巴别塔为何失败
让我印象最深的是巴比伦塔的管理教训里面的一句总结为** 什么巴比伦塔为什么是一个失败的工程：那为什么项目还会失败呢？他们还缺乏些什么？ 两个方面——交流， 以及交流的结果——组织**。 他们无法相互交谈， 从而无法合作。 当合作无法进行时， 工作陷入了停顿。这样的问题我相信每一个做过项目的团队都有经历，在我们最初进行2014年广东工业大学女生节许愿墙的时候，3个UI自己都来了一套，结果工期拖延一套都不能用。下面讲3条我所想到可能的交流途径：
- 非正式：电话（加速对文档的共同理解）
- 常规会议： 直接面对面交流解决问题
- 工作手册：开始阶段准备正式的项目工作手册。
第十章 文档先行
从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。
文中作者也强调了，许多软件工程师对于文档编写缺乏激情，并且对于不同的用户在文档也要有详细针对性的描述，除了程序的使用方法， 还必须附带一些程序正确运行的证明， 即测试用例。修改程序。 调整程序或者修复程序需要更多的信息。除此之外，项目实战中最好是需要一个进度表由里程碑及完成时间组成，并且记录时写明是否百分百达到？不可模棱两可。
第十三章 整体和局部
这一章主要从消除Bug的设计，构件单元测试和系统集成调试三个方面来谈，大而无当的笼统见地并不能表现你真正地理解了一个软件系统，应该具体而系统地深入了解各个局部的技术。良好的自顶向下的设计，不仅能保证概念完整性，也能及早消灭许多隐患。及早在软件项目中引入测试， 错误发现得越早，修复错误的代价越小。
V.A.Vyssotsky提出许许多多的失败完全源于那些产品未精确定义的地方。
因此从最开始需求设计，我们要高度集中，设计也要自顶向下精益求精，根据结构的设计方法和思路，详细的需求规格说明书完成后要求测试小组编写测试用例并且小组也要起到最后一步对需求说明书把关的作用。
对于大型软件系统，产品集成和集成测试具有重要的地位，为了系统的有计划的降低系统集成调试的困难性我们需要采取多种方法和措施。其中包括了首先对于单个构建必须经过充分的单元测试，否则单元测试的问题将遗留到集成测试阶段导致问题复杂化；其次是搭建充分的测试平台，测试平台往往需要编写测试代码，特别是还可能开发各种伪构件来验证数据集成的正确性。最后是在集成期间要严格控制变更，最好是阶段化的定期变更。
第十四章 潜伏的祸患
软件项目的经理应该尽量建立可以明确量化的阶段性目标，定期进行严谨而规范的项目阶段性验收，了解项目的进展状况，并及时进行计划、资源和人力的调整。关键路径图等技术有助于观察项目的进度。
其实可能很多阅读这本书的读者称不上项目经理，但必须要在整个团队中树立这种观念，就是要尽可能早的完成相关的任务，而不是拖到了最后在来做。类似于关键链进度管理中始终强调的一个重点内容就是要压缩前面的开发周期而在项目后期预留缓冲。
万一出现了严重的时间偏差，也不必过于惊慌失措，进行一些诚实的汇报，积极主动地承认错误，或许会有更多的人来帮助你！
第十六章 没有银弹――软件工程的必然和偶然
没有任何技术或管理上的进展， 能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。
天知道为什么《没有银弹》这名字取成这样，文章最初发表于1985年的IFIP第十届世界计算机大会上，此时距《人月神话》初版发行已有十年，其间计算机技术领域的变化令人振奋，但作者在此提出，由于软件的复杂性，一致性，变化性和不可见性，解决软件危机的银弹并不存在。
== 突然觉得他们都好无聊这么戏剧味的名字赤果果地竟是软件工程的经典论文，其中银弹宝宝特意去google了一下—
能杀死狼人的利器.在古老的传说里,狼人是不死的,想要杀死狼人有几种方法：
1.像杀死吸血鬼那样用木桩钉住狼人的心脏。
2.将月光遮住
3.用银子做的子弹射穿狼人的心脏或头
(●'◡'●)简单来说，狼人可以是一个棘手的项目，或者一件不可能的事。而“银弹”就是指能解决这些事的方法，或者技术手段。
- 复杂性： 软件系统与计算机、建筑或者汽车大不相同，后者往往存在着大量重复的部分。
- 一致性：在某些情况下，因为是开发最新的软件，所以它必须遵循各种接口。另外一些情况下，软件的开发目标就是兼容性。在上述的所有情况中，很多复杂 性来自保持与其他接口的一致，对软件的任何再设计，都无法简化这些复杂的特性。
- 可变性：系统中的软件包含了很多功能，而功能是最容易感受变更压力的部分。所有成功的软件都会发生变更。
-
不可见性：除去软件结构上的限制和简化方面的进展，软件仍然保持着无法可视化的固有特性，从而剥夺了一些具有强大功能的概念工具的构造思路。这种缺憾不仅限制了个人的设计过程，也严重地阻碍了相互之间的交流。
而人们苦苦寻找的银弹，是否就是现今我们常提的加强组件复用和技术平台建设从开发模式的改进上解决问题呢？嗯，我也不太明白。
第十九章 人月神话二十年
尽管再版20年后，计算机领域有了相当大的变化，《人月神话》体现出深远的影响力，初版中的许多观点依然经常被人们谈论和引用，其中有些断言至今仍被软件开放人员奉为指点迷津。作者结合当前软件工程领域的发展现状重新梳理了初版中的各核心观点，强调了概念完整性，重新评议了第二个系统效应，反省了瀑布模型的局限性，结合初版中的观点，作者评述了图形桌面系统、信息隐藏、面向对象高级语言等技术的发展，以及近年来软件工程领域的重要成果。
人月神话的结论:人力（人）和时间（月）之间的平衡远不是线性关系，使用人月作为生产率的衡量标准实际是一个神话。
我想到的
直到现在还是很难以相信这本书已经在世40余年了，尽管开篇的项目最终失败了，但开发的过程中解决了很多技术难题。它的开发过程成就了这本“人月神话“。这也让我想明白为什么大家都会觉得在项目实践中我们才可以学到更多。没有项目，你不会去想有什么问题。有了问题，我通过网络或是书籍吸收掉的知识远远超出单看。
总体来看这本书涉及到团队，人和沟通以及大型软件工程项目人的重要性。在开篇讲开发人员的职业乐趣，后面又通过巴比塔的沟通重要性，在外科手术队伍中的组件和分工最终提到“没有银弹”的观点，再次强调开发项目并非一件易事。
不得不说，这本书还是需要都，希望有机会看到50周年纪念版。
自左向右：Fred Brooks, Larry Breed, Joey Tuttle, Arthur Whitney, Eugene McDonnell, Paul Berry。
