《人月神话》读后感

《人月神话》读后感

中国科学技术大学软件学院

朱怡良

原创作品版权所有转载请注明出处

        一件事你不了解它存在的乐趣在哪里，是不能创造出惊人的美感的，人月神话就是告诉你如何去爱上编程，如何像反思自己人生一样去反思编程，从而在这之外获得更大乐趣，取得更大的成就。

（1）它是一种创建事物的纯粹快乐。

（2）其次，快乐来自于开发对其他人有用的东西。内心深处，我们期望其他人使用我们的劳动成果，并能对他们有所帮助。
（3）它在整个过程体现出魔术般的力量——将相互啮合的零部件组装在一起，看到它们
精妙地运行，得到预先所希望的结果。比起弹珠游戏或点唱机所具有的迷人魅力，程序化的
计算机毫不逊色。
（4）它的乐趣体现在学习的乐趣上，来自于这项工作的非重复特性。人们所面临的问题，在某个或其
它方面总有些不同。因而解决问题的人可以从中学习新的事物：有时是实践上的，有时是理
论上的，或者兼而有之。
（5）乐趣还来自于工作在如此易于驾驭的介质上。

        编程最初对我来说，只是一项工作，从没想过编程的乐趣在哪里，不是没有感受到过，只是那些感受从没有把它当做一件事情来想，在《人月神话》中，让我看到编程不为我所知的一面，我开始更深刻了解它。了解它的乐趣所在。从而明白编程的整个意义所在，我想在开始我为编程奋斗的全部动力。

        编程，是一门艺术。艺术家创造杰出艺术作品的过程中，无不是怀着饱满的人情、昂扬的斗志、坚定的信念，有些著名的艺术家甚至为了一个作品而奉献出自己一生的时光。当然，如今快节奏、高效率的生活方式要求我们要用最快的速度完成一个程序的编写，而不用在一些微不足道的细节上反复雕琢，但是这些艺术家的精神是程序编写者应该效仿的。只有以积极的心态去面对自己的工作，才能更快、更好的完成。

        而有趣的是，软件工程项目的管理者们往往更关注的是程序员们的工作成果，而不是工作的过程。管理者只能通过工作结果去判断谁做的好、谁做的不好但不关注过程的他们不知道为什么这些人有的做的好、有的做的不好，于是他们只能批评甚至是开除那些工作做的不好的、表扬那些工作做的好的。这种做法实在太过被动，因为当工作正在进行之中时，管理者们是无能为力，他们无法预测结果的好坏，无法改变结果的好坏，项目的进展是处于一个不可控的状态的。管理者们不知道上次做的好的人，这一次是不是会做的差，也不会知道如果留下那个因为没有做好工作而被自己开除的人，会对这次工作的结果产生什么影响。

        所以，管理者需要注重过程。注重过程当然不能是在跟着程序编写者，看他们每个时刻的程序是否编写的好。既然无法通过对技术的考校而提高效率，那么就只有关注编写程序的那些“人”了。《人件》一书就对如何管理软件开发的人员进行了详细的阐述，比如提供良好的工作环境改善程序员的工作心态，更加注重程序员们对工作的态度如何，是否热爱他们的工作、是否追求质量的最佳、是否想成为团队中技术最好的人，这样就可以保证团队以一个积极饱满的态度去完成工作。态度决定一切，当一个人用十二分的热情去干一件事的时候，他就可以化不可能为可能，他就可以创造奇迹。

       技术，都是靠人去掌握的，所以关注技术的本质是去关注掌握技术的人。一个好的管理者，首先要做的不是对技术的追求，而是维持一个积极友善的团队环境，处理好团队人员之间的关系。如果能做好这一步，可以说这个项目就已经成功了一半了。

书开始就形象有有趣的把软件危机比作：

焦油坑

 

========== 

史前史中

,

没有别的场景

比巨兽在焦油坑中垂死挣扎的场面更令人震撼。

上帝见证着恐龙、

猛犸象、

剑齿虎在焦油中

挣扎。它们挣扎

...

让我感觉到，软件开发过程中所遇到困难是多么的多，开发多么艰难。

           但人在整个软件开发过程中，人数并不决定开发的质量和时间，因此热情是前提，但并不是人越多越好。人月神话描述道人力（man）和时间（month）并不体现线性关系。以大量人员和较短的时间，并不能缩短软件的开发进度。一窝蜂的作业方式无助于软件生产，且会制造麻烦，产生出更差的软件。向进度落后的项目追加人力，只会使进度更加落后。因为新进的人员需要时间了解整个项目，而增加额外的沟通消耗。当有 N 个人必须在这群人之中进行沟通时（无阶级关系），当 N 增加，其输出 M 将抵消其效益，甚至倒退（最后几天所完成的进度，远不如刚开始几天所完成的进度。像是发现了许多错误）。 可以软件开发的多少人参与和完成时间不成正比，过多的人参与并不一定能缩短开发时间。

     在《人月神话》中提到的《设计模式》、《原型设计》、《灵活软件开发》、《面对对象思维》、只不过是冰山一角。都是《人月神话》整个软件项目管理的经典思想，堪称软件领域的《孙子兵法》。

      《人月神话》中感触最深的观点是：

 （1）编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。 

（2）缺乏合理的时间进度是造成项目滞后的最主要原因， 它比其他所有因素加起来影响
还大。
（3） 良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。
（4）所有的编程人员都是乐观主义者： “一切都将运作良好” 。
（5）由于编程人员通过纯粹的思维活动来开发， 所以我们期待在实现过程中不会碰到困难
（6）但是，我们的构思是有缺陷的，因此总会有 bug。
（7）我们围绕成本核算的估计技术， 混淆了工作量和项目进展。 人月是危险和带有欺骗
性的神话，因为它暗示人员数量和时间是可以相互替换的。
（8）在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。
（9）关于进度安排，我的经验是为 1/3 计划、1/6 编码、1/4 构件测试以及 1/4 系统测
试。
（10） 作为一个学科，我们缺乏数据估计。
（11） 因为我们对自己的估计技术不确定， 所以在管理和客户的压力下， 我们常常缺
乏坚持的勇气。
（12） Brook 法则：向进度落后的项目中增加人手，只会使进度更加落后。

（13）项目工作手册 “不是独立的一篇文档， 它是对项目必须产生的一系列文档进行组织
的一种结构。 ”
（14）“ 项目 所有 的文档都必须是该（工作手册）结构的一部分。 ”

（15） 需要 尽早 和 仔细 地设计工作手册结构。
（16）事先制订了良好结构的工作手册“可以将后来书写的文字放置在合适的章节中” ，
并且可以提高产品手册的质量。

       编程是一门艺术，管理也是一门艺术，关于人月的神话也是编程与管理的神话。这些神话需要我们更多在实践中去理解，去体会。