1509_人月神话阅读笔记_整体与部分

全部学习汇总： GitHub - GreyZhang/The_Mythical_Man_Month: My reading notes of The Mythical Man-Month.

如同我在这一章的封面上标注的，我把整体部分改成了整体与部分用到了我这一份笔记的标题。因为整体部分可能会让人只会想到整体而忘记了部分，然而这不是书的本意。这本书的翻译，充斥了大量的类似问题，我估计可能会是老师带着几个学生翻译出来的。这本不是什么问题，但是校对又可能没有做到那么多的检查，也就出现了这样的局面了。

这里面有一个针对夸夸其谈的人的答复，我觉得很让人觉得透气。其实，我觉得现在流行的linus的评价也可以用来作为一个替代的回答：说都可以说，给我看看你的代码！

模块之间的交互可能会是bug的重灾区，而这种现象在于模块化设计以及分工合作的团队中肯定是如此。而减少这样问题发生的有效手段就是减少模糊性。

这里提出来了一个模式化的开发流程，其实在现在的软件开发行业中依然是奏效的。然而，这样的流程化的开发模式可能不见得在所有的团队中都适用。尤其是，很多团队的项目管理人员对此认识不够，而结构师又没有足够多的经验，就很可能只是放一个框架的说法在这里，实质上还是工程师信马由缰。

减少bug发生的有效手段，其实可以做一个精简的总结：1，架构设计明晰； 2，功能描述明确（需求） 3，细节属性到位 4，测试提前。

设计不能够总是看细节，也要有一定的大局观。

做什么之前先进性充分的思考，其实我觉得这个即使是现在计算机资源充足的条件下也是适用的。过去的多年的工作中，我从一些老牌程序员的故事中学到了这一点而且在我自己的实践中贯彻执行。而这些，都成了我成长的法宝。

曾经，软件调试是一个成本特别高的过程。而现在，虽然我们手头的资源有时候还是看似不足，但是已经好了太多。别的不说，看看曾经的电脑设备，16K的存储都得纠结，而我们现在单片机也都有超过这样资源的存储。

之前软件调试比较麻烦，很大的一个局面是一群人守着一台电脑设备，而这个电脑设备不支持分时复用，兴许也就不支持多用户同时使用。打破这个局面的方式可能是后来的unix的问世吧？

这里给出来了两种方法，其实，我觉得没有绝对的优劣。就我个人的理解来说，独立的开发人员开发一个项目，前面的方法好。而合作开发的时候，后面的方法好一些。

这种方法我自己感觉用不起来，但是这个是KEN老爷子的成名绝技。我尝试过做类似的调试，但是几次尝试都是失败的，还是没有获取到其中的精髓要点。

项目管理得感谢现在出现的一些优秀工具，其中就包括版本管理工具。其实，同时需要感谢这些工具的还有软件工程师，这些工具给软件工程师提供了时光机，有了可以后悔的机会。

软件究竟该一点点的逐步增长还是一次若干个模块一起增加？我觉得这个也是没有绝对的答案的，从开发者的角度考虑，至少局部开发的时间阶段逐步增加是好的。但是，不管如何处理，只要是有多人合作的开发的团队这种模块之间的交互耦合问题的产生以及面对是迟早的事情。

根据上面的信息，在版本升级的时候应该规划合理的变更条目。保证整个软件发布效率的同时也得有足够好的稳定性。如果，能够做到相对稳定，给出已经知道bug让用户能够合理避开，很多时候也不失为一种阶段性合理的选择。