初读《人月神话》浅谈

中国科学技术大学软件学院 罗晓波 原创作品转载请注明出处        

        最近一段时间，由于课程要求，就开始捧起了一本软件工程领域的一本神作，人月神话。

        本书中所介绍的人与月的关系，是描述了一个软件工程项目的实施需要多少人以及多长时间（月），有时候人越多，对于一个软件项目来说，可能是一个灾难，最后有可能陷入一个焦油坑之中。项目初始时，人月是成反比的，人越多，需要的月就越少。随着时间的推移，人越多，交流成本上升，需要的时间大大增加，月增加，新的成员的加入对项目的知识的培训和了解都是需要花费月的。而且一个大型的软件项目，如果人数很多的话，在控制上是不好把握的，在效率上是低下的，试想如果团队之中都是高效率的程序员，他们的生产效率可能是一群低效程序员的数十倍，这样给我们的启示便是项目团队少而精是项目成功的一大捷径。

        给我在精神层面上非常共鸣的一个观点就是文中所提到的：苦恼来自于追求完美，学习编程最困难的部分就是将做事的方式向追求完美的方向上调整。这也是在近期的一个项目中深有体会的一处，对完美的架构，完美的UI，完美的编码，完美的测试case的追求等等。这些才是一个项目完美的保障。我对于完美的追求自认为还没有到偏执的那一步，但我觉得，对完美的苛求是一个程序员的必备的。

        书中还提到一个非常适用的软件任务的进度安排：1/3的计划，1/6的编码，1/4的构建测试以及早期系统测试，1/4的测试系统，所有的构建已完成。这对于我来说又是一个在项目进度安排上的一个启发点，对于计划的时间安排足足占了三分之一，这个时间允许去做一个合理合适的架构分析，结合近期的一个运用scrum方法的项目，前期的设计或者说计划对于整个项目的重要性是不言而喻的。但是对于测试，在项目周期中得时间也许因项目而议，不一定每一个项目在测试上面花费的时间都要是整个进度安排的二分之一。

        有关于文档，对于软件编程产品来说，程序向用户所呈现的面貌，文档，与提供给机器识别的内容同样重要。即使对于完全开发给自己使用的程序，描述性的文字也是必须的，因为他们会被作者所遗忘。还有为了使文档易于维护，将它们合并到源程序之中也是至关重要的，而不是将其单独作为一个文件保存。反观我们项目中对于文档的重视程度，显然是不够的，甚至有时候存在项目都已经临近结束才开始编写相关文档，这对于设计，编码的意义就小多了，但对于产品后期的维护，运营或许是一个比较好的参考依据。

        没有银弹，在未来的十年内，没有可以保证十年内可以大幅提高软件生产率、可靠性、简洁性的一种进步，这种进步不管在技术上还是在管理方法上都是不存在的。现代软件系统中无法规避的一些内在特性诸如：复杂度，一致性，可变性，不可见性都从一定程度上造成了没有银弹这个现实情况，但是我们可以采取一些更为有效的开发模式比如增量迭代开发，快速原型开发，测试驱动开发等等。

        时间仓促，第一次读人月神话，以后一定会再好好拜读这部神作。