初见书名时还在奇怪为什么老师要我们看一本这书，在我刚刚见到这本书时我以为说的是人类登上月球的书籍，后来明白了本书的名字并不是人类和月球之间的神话故事，而是软件工程的一些迷思，人月是一个人一个月的人力单位。
在这本书里作者提出软件工程中各个项目的比例应该如下：
1/3 planning
1/6 coding
1/4 component test and early system test
1/4 system test, all components in hand
初始时心中还在迷惑为什么编程的时间不是花得最多，后来才明白这与我们在学校里的编程作业的不同，在公司里都有着一套严谨的流程，而计划与测试才是最花时间的。读完此书我明白系统设计中最重要的是概念的完整性。如果连概念都没有弄明白，如何完成工程的设计呢？
下面我就来说一下对我感触最深的一些章节吧：
第一章 焦油坑
史前时代的焦油坑吞噬了成千上万个力大无穷的巨兽，今天的大型软件项目则令无数庞大的开发团队陷入无从逃脱的窘境。软件程序按其规模和目标的不同，对开放过程的要求也有极大的不同，这给软件开放这一职业带来无穷乐趣，同时也是这一行业苦恼的根源。
第三章 外科手术队伍
虽然优秀的程序员的工作效率往往数倍于平庸的程序员，但若是缺乏合理的配置，优秀的成员未必能构成优秀的团队。大型软件开发项目的团队需要和外科手术组一样妥善分工，各司其职协调配合。
第五章 第二个系统效应
人们在第一个系统成功完成后，往往会在开发后续的第二个系统时犯冒进的错误。第二个系统经常成为过度设计或画蛇添足的牺牲品。要避免这种错误，必须在第二个系统开发时审慎地考查技术环境的变化，广泛进行交流和沟通，聆听各方面的建议，确立严谨的估算和规划。
第七章 巴别塔为何失败
如果缺乏良好有效的沟通和协作，成员间难以有效的配合，团队项目的目标就无法实现。清晰的工作文档，明确的组织结构，合理的职责分配，都是大型软件项目最终成功的保证。
第十一章 准备抛弃
变化是永恒的，用户的需求和期望在变化，开发者对用户需求的理解在变化，适用的技术也在变化，故而最佳的解决策略也可随之变化。软件开发团队应灵活地配置人力和资源，适应开发过程中的种种问题。程序的复杂性、用户需求的不确定性、软硬件技术环境的发展等因素导致了软件维护工作并非总是能够百分之百地获得回报。
第十六章 没有银弹――软件工程的必然和偶然
本文最初发表于1985年的IFIP第十届世界计算机大会上，此时距《人月神话》初版发行已有十年，其间计算机技术领域的变化令人振奋，但作者在此提出，由于软件的复杂性，一致性，变化性和不可见性，解决软件危机的银弹并不存在。作者点评了二十世纪80年代前期为业界寄予厚望的一些新技术，讨论了它们在克服软件危机中所具备的优势和缺憾。作者预言在近十年内，没有任何单独的软件工程进展可以使软件生产率有数量级的提高。
其中印象最深的莫过于巴别塔为何失败了。读完全书我也觉得最重要的一步就是要写计划，通过计划使时间分块来进行，提高工作效率。
总之这是一本十分好的书，虽然它诞生于几十年前，但依旧是精品，我要找时间再一次的读读它。