人月神话读后感

《人月神话》读后感

焦油坑章提出了一个观点“编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的9倍。”但是在实际条件下，除了真正做产品的科技公司，很多非科技公司希望的是只花个人程序的成本来得到编程产品的质量，而且还会反复抱怨，为什么别人买的产品只需要这边点成本，而我们自己开发却要提高这么多倍。

人月神话章，很经典，最常听到的一个观点“Brooks法则，为进度落后的项目增加人手，只会使进度更加落后。”其实我个人更认可的一个观点是，人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。

不可否认，如果人员具备非常高的素质，在项目进度遇到瓶颈的时候，增加这类人员可以加快进度，但是实际条件下，更多的还是牺牲现有人员的生命时间来换取项目进度的推进。

外科手术和贵族专制两章，我比较认可的观点是概念完整性对后续的项目进度会有促进的效果。但是他提到的外科手术式队伍，和一个人来统筹整个项目的概念完整性这点，我持保留意见，就想文后的其他教授的留言一样，实际中这样操作是会让主刀人的工作加大的很夸张的地步的，另外就是一个人来考虑概念完整性，这样的人才，至少在国内来说，很少，并且也没有一个公司或者团队愿意以一个人的想法来做一套产品，最后总是会发生一定的偏移或者改变。

还有就是如果是组建外科手术式的队伍，那对于团队中的其他人来说，他们如何获得自己的成长，也是一个问题，那样人人都想当主刀医生，不想配合。软件行业要形成像医疗行业那样的体系，他必须得整个行业来做变革，让行业中形成这样的分类，才能很顺利的组建这样的队伍。

不记得具体是哪章了，但是后续的内容中都提出了团队沟通，项目手册，组织架构这些点。也很切实际。

项目手册我相信是国内各个公司都会面临的问题，写代码的程序员可以很快乐，但是写手册的程序员一定不开心。像外科手术式队伍，或者组建新的组织架构，确实可以解决这种问题，但是问题来了，对于项目中庞大的文档资料，我们国内有几家公司愿意真的花费成本进行管理？我在招聘软件上有搜索过这个岗位，我也只是很短暂的在一线城市的某个软件公司搜到过，后面再也没有见过。

所以现在普遍行业对于项目文档的不重视，不是某一个公司或者某一个城市能改变的，需要整个行业都重视起来，大家都觉得不就是文档嘛，随便找个程序员进行管理，或者项目经理代为管理就好了。

除了代码，软件占用内存这些也需要考虑。深以为然。

我发现因为计算机硬件技术的飞速提高，现在很多程序员在开发设计软件的时候是完全不考虑内存占用，访问这些信息的。

我就碰到过一个项目，存储在服务器上大量没有用的图片，占用了打量资源，后来直到服务器报错才被发现，这时候距离程序上线已经过去了2年。那在这2年中没有任何人关注过这个慢慢膨胀的肿瘤，直到他发病。

另外，我始终最认可的一个观点，是认为，软件行业发展的桎梏在于概念的多变。后面无论是提升硬件，使用更高级的语言，或者更先进的开发方式，都没有解决最根本的问题。我很认可，在我实际接触的项目中，人的想法或者行业的转变都太快了，我们现在需要的是一个非常高的工具，能快速将这种虚拟的概念具象化，快速展示和修改。但是很遗憾，现在出现的敏捷编程，phython，java等等语言或者编码方式，都还是在整个软件工程的后部分进行改善。

就像本书的作者所说的，我们需要银弹。