人月神话读后感

第二章就已经输出了作者的核心观点——Brook法则：向进度落后的项目中增加人手，只会使进度更加落后。
因为从三个方面增加了项目必要的总体工作量，这里的理论支撑也就是来自这三个方面：

首先，任务重新分配本身和所造成的工作中断；
其次，需要培训新人员工；
最后是需要引入额外的沟通成本。
从以往我的课设经验来说，Brook法制的确诚不欺我，囿于身边环境，大部分课设一般都是一带多的情况，而如果那个“一”发生意外，即使其他人想帮助推进进度，受制于他们的知识、能力的枷锁，反而进度只会越来越慢，最后留下一地狼藉展示给老师。“我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。”

这一句话初看比较晦涩，但只要把人员数量和时间当作一次函数的y和x 变量就非常简单了，人员数量的不断增大，所耗费的工期工时一定能减少吗？如果真是这样，中国14万万人民群众，何愁不能快速实现社会主义的现代化，抵达共产主义的彼岸呢？答案当然是否定的。

第三、四、五、六章，是一些实际项目的系统设计准则，知晓即可。第七章和第八章分别阐述了交流的必要性和实践中学的重要性。巴比伦塔会失败？这是第七章的开篇发问，巴比伦塔项目的失败是因为缺乏交流，以及交流的结果——组织。“因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。”由于对其他人的各种假设，团队成员之间的理解开始出现偏差。交流是我一直以来比较欠缺的能力，一方面是个人性格，另一方面则是每每表述完后，仍然存在的误解和割裂打击着我再次交流的想法。

第八章中提到实践是最好的老师，但如果不能从中学习，再多的实践也没有用。估算有三个要素。一是实践。二是量化指标。三是根据量化的指标建立模型。而名言的意思是，实现->量化指标->估算模型->实现->量化指标->重新建立模型。是一个不断实践和学习的循环。编程是一个多敲代码总有收获的活动，初学C语言编程老师也反复强调代码量是关键，之后的数据结构课老师也把“敲个百遍，其意自现”类似的语句反复告诫。这两章的内容放之四海而皆准，无论哪个专业哪门学科，都是值得学习于参考的。

后面的章节我就草草翻过去了，一方面有些书中内容已经过时了，譬如第九章在讲解程序占用资源的控制、第十二章干将莫邪讲解辅助机器与工具，另一方面部分章节的思想在软件工程的课上也有所涉猎，如第十三章整体部分防范bug的方法：1、防范bug要从产品定义开始。2、先让各个部分都能够单独工作，再进行整体联调。就是软件测试的自顶向下和自底向上的测试方法。