《人月神话》读后感
作者：mizuhokaga 时间：2021/06/10
《人月神话》大一的我早已在学校图书馆的二楼(计算机书籍专层)见过它的大名，可惜当时年少无知，光看名字和封面觉得像一本放错了展馆的神话史诗故事书，最终没有打开翻阅。直到大三学习了《软件工程》这门课才知晓这本书在软件工程里的地位，这才翻看了一遍。我就我看过的内容，写写自己的思绪，记录一下自己的看法。以章节为序。
第一章中，“编程系统产品（Programming Systems Product）开发的工作量是供个人使用的、独立开发的构件程序的九倍。我估计软件构件产品化引起了3倍工作量，将软件构件整合成完整系统所需要的设计、集成和测试又强加了3倍的工作量，这些高成本的构件在根本上是相互独立的。”就现在的来说，无论是技术的进步还是市场的扩大，都导致了现在的工作量早已超过九倍，分布式系统、大数据和算法，这些词也被人熟知。
这一章中也有些跨越时代与时间的行业痛点击穿我的心灵,譬如：“人们通常期望项目在接近结束时，（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢”、“将做事方式调整到追求完美，是学习编程的最困难部分”。
光是读到这两句话，结合在学校的项目/大作业经历,我就觉得此次翻阅不亏。
第二章就已经输出了作者的核心观点——Brook法则：向进度落后的项目中增加人手，只会使进度更加落后。
因为从三个方面增加了项目必要的总体工作量，这里的理论支撑也就是来自这三个方面：
- 首先，任务重新分配本身和所造成的工作中断；
- 其次，需要培训新人员工；
- 最后是需要引入额外的沟通成本。
从以往我的课设经验来说，Brook法制的确诚不欺我，囿于身边环境，大部分课设一般都是一带多的情况，而如果那个“一”发生意外，即使其他人想帮助推进进度，受制于他们的知识、能力的枷锁，反而进度只会越来越慢，最后留下一地狼藉展示给老师。“我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。”
这一句话初看比较晦涩，但只要把人员数量和时间当作一次函数的y和x 变量就非常简单了，人员数量的不断增大，所耗费的工期工时一定能减少吗？如果真是这样，中国14万万人民群众，何愁不能快速实现社会主义的现代化，抵达共产主义的彼岸呢？答案当然是否定的。
第三、四、五、六章，是一些实际项目的系统设计准则，知晓即可。第七章和第八章分别阐述了交流的必要性和实践中学的重要性。巴比伦塔会失败？这是第七章的开篇发问，巴比伦塔项目的失败是因为缺乏交流，以及交流的结果——组织。“因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。”由于对其他人的各种假设，团队成员之间的理解开始出现偏差。交流是我一直以来比较欠缺的能力，一方面是个人性格，另一方面则是每每表述完后，仍然存在的误解和割裂打击着我再次交流的想法。
第八章中提到实践是最好的老师，但如果不能从中学习，再多的实践也没有用。估算有三个要素。一是实践。二是量化指标。三是根据量化的指标建立模型。而名言的意思是，实现->量化指标->估算模型->实现->量化指标->重新建立模型。是一个不断实践和学习的循环。编程是一个多敲代码总有收获的活动，初学C语言编程老师也反复强调代码量是关键，之后的数据结构课老师也把“敲个百遍，其意自现”类似的语句反复告诫。这两章的内容放之四海而皆准，无论哪个专业哪门学科，都是值得学习于参考的。
后面的章节我就草草翻过去了，一方面有些书中内容已经过时了，譬如第九章在讲解程序占用资源的控制、第十二章干将莫邪讲解辅助机器与工具，另一方面部分章节的思想在软件工程的课上也有所涉猎，如第十三章整体部分防范bug的方法：1、防范bug要从产品定义开始。2、先让各个部分都能够单独工作，再进行整体联调。就是软件测试的自顶向下和自底向上的测试方法。
“没有银弹”是一个很酷的概念!
在没有银弹与人月与再论没有银弹章节中提到：软件开发的根本困难是搭建什么样的系统既需求，次要问题是搭建系统的技术和编码过程。根本困难的复杂性、一致性、可变性和不可见性，决定了10年内开发效率不会有量级的提升。但可用的改进方法是：购买软件产品包、需求精炼与快速原型、增量开发——增长而非搭建系统、面向对象、重用（重用会带来词汇量增加的问题）。没有任何技术或管理上的进展，能够独立地许诺在生产率、可靠性或简洁性上取得数量级的提高。这是软件本身的性质所带来的缺陷，但随着时代的进步，技术的不断发展，包括面向对象技术和软件复用等等，这些便利的新技术是否就是软件业界在寻找的银弹呢？
上述就是本人对人月神话的刍荛之见
扫一扫
281
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
