人月神话这个名字对我来说很有吸引力，我以为它会是一本讲述计算机历史神话的故事。当我看到第二章我才知道原来这个“人月“是我们项目工程中估计和进度安排中使用的工作量单位：人月。全书共分为以下几个部分：
焦油坑
人月神话
外科手术队伍
贵族专制、民主政治和系统设计
画蛇添足
贯彻执行
为什么巴比伦塔会失败？
胸有成竹
削足适履
提纲挈领
未雨绸缪
干将莫邪
祸起萧墙
另外一面
没有银弹
焦油坑依然存在
对于所有的程序员来讲，都有乐观主义，总是相信自己的代码是肯定能运行的。所以在安排项目的进度的时候就会是假设在代码能够在正常运行时因该花费的时间。而现实往往不是
乐观，在项目的进展过程中会存在各种不可预知的问题。在这个时候项目经理就会为项目增加人员，然而增加人员反而导致项目进度越来越慢。因为新增加的人员还需要培训，需要
时间去了解项目的内容和进展情况。在投入了更多的人力的时候，经理发现项目进度反而更慢他就会投入更多的人力，这种恶行循环导致项目的失败。
虽然0S/360失败了，但是它在开发的过程中解决了很多技术难题。它的开发过程成就了这本“人月神话“。这也让我想明白为什么大家都会觉得在项目实践中我们才可以学到更多。
没有项目，你不会去想有什么问题。但是在项目中遇到问题的话，你最好的求助方式是网络和书籍，而且如果在遇到问题的时候能深入研究书籍的话你才会进步的比较快。
对于这本书，给我最大印象的就是贯彻执行：
1. 即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的。
2. 必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致。
3. 出于精确性的考虑，需要形式化的设计定义，同样，需要记叙性定义来加深理解。
4. 允许体系结构师对实现人员的询问做出电话应答解释是非常重要的，并且必须进行日志记录和整理发布。
5. 项目经理最好的朋友就是他每天要面对的敌人——独立的产品测试机构/小组。
文档的重要性
看完整本书我看到作者一直再强调文档的重要性，他曾经很勤奋的向软件工程师们讲述文档的必要性以及优秀文档所具有的特点方面的讲座。但是效果都非常的的不好，他们知道如
何来写出优秀的文档，但是他们缺乏热情。所以作者采用向马车搬收银机的方法向他们展示如何来完成这项工作。结果显示这种方法的效果还是挺好的。那我们在开发的过程中需要
什么样的文档呢？
不同用户需要不同级别的文档。 某些用户仅仅偶尔使用程序， 有些用户必须依赖程序，还有一些用户必须根据环境和目的的变动对程序进行修改。使用程序。 每个用户都需要一段对程序进行描述的文字。可是大多数文档只提供了很少的总结性内容，无法达到用户要求，验证程序。 除了程序的使用方法， 还必须附带一些程序正确运行的证明， 即测试用例。修改程序。 调整程序或者修复程序需要更多的信息。显然，这要求了解全部的细节，并且这些细节已经记录在注释良好的列表中。 和一般用户一样， 修改者迫切需要一份清晰明了的概述。
总结巴比伦的失败
1. 巴比伦塔项目的失败是因为缺乏交流，以及交流的结果的组织。
2. 因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。由于对其他人的各种假设，团队成员之间的理解开始出现偏差。
3. 团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。
巴比伦塔可能是第一个工程上的彻底失败，但它不是最后一个。交流和交流的结果—组织， 是成功的关键。 交流和组织的技能需要管理者仔细考虑， 相关经验的积累和能力的提高同软件技术本身一样重要。
软件工程的隐患之处：祸起萧墙
1. 一天一天的进度落后比起重大灾难，更难以识别，更不容易防范和更加难以弥补。
2. 根据一个严格的进度表来控制项目的第一个步骤是制订进度表，进度表由里程碑和日期组成。
3. 里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。
4. 如果里程碑定义得非常明确，以致于无法自欺欺人时，程序员很少会就里程碑的进展弄虚作假。
其核心思想就是防微杜渐，重大灾害是比较容易处理的，它往往和重大的压力、彻底的重组、新技术的出现有关，整个项目组通常可以应付自如。 但是一天一天的进度落后是难以识别、不容易防范和难以弥补的。
技术与思想，银弹
作者将软件开发比作人狼，而将提高软件开发效率的方法比作银弹。作者预言未来十年，想要试图通过寻找一种有效地银弹将软件开发效率提高一个甚至几个数量级，这种银弹不可能出现。
没有银弹这篇文章里作者列举出了当时一些非常先进的技术或思想理念，例如Ada和其他高级编程语言、面向对象编程、人工智能、专家系统、“自动”编程、图形化编程、程序验证、环境和工具、工作站等。虽然这些先进技术在一定程度上提高了软件开发的效率，但是始终没有达到银弹的效果。距离作者的预言已经过去有20多年了，纵观现在的软件开发领域，虽然新技术层出不穷，但是还是没有一种银弹能够让软件开发产生一次革命。对此产生的思考：
1.现在有很多快速开发平台，但是真正能够不写代码就完成业务功能的开发平台基本上没有成功的，特别是在业务场景比较复杂情况下，编程自动化基本是不可能的事情。
2.不要在追求自动编程平台上下功夫，可以在加强组件复用和技术平台建设上下功夫。
3.要多从开发模式的改进上来解决没有银弹所提出的各种实际问题，虽然不能够彻底解决，但是可以通过努力来改进。
焦油坑依然存在
软件工程的焦油坑在将来很长一段时间内会继续困扰着人们。由于软件系统多变性和错综复杂性，这个行业只能是一步一个台阶的往上爬，而出现银弹的希望在我们可以想象的时间范围内是非常渺茫的。软件工作者还需要长期与焦油作斗争。