人月神话读后感

人月神话都后感

中国科学技术大学软件-王香港-原创作品转载请注明出处

以下评价或对或错，仅仅代表个人看法，文中较多引用了书本语言，并对此作了简单的评注。

这两天刚读完了《人月神话》这本软件工程相关书籍，这里写下自己的读后感！

人月神话为什么能够盛行如此之久：

        软件工程向来被评价为较为“水”的一门计算机科学的书籍，因其大都设计工程管理科学方面的知识，并未涉及新鲜的技术供读者学习，可能学习起来过于枯燥，很难获得成就感吧。不建议那些没有软件开发经验的人员精读这本书（愿意的略读还是可以的）。

       翻看本书你会惊奇的发现，本书作者Brooks并未避开上面提到的“不利”书籍推广的因素~~。反而将这个方面发挥到了极致！！！通篇近乎不涉及代码知识的解释、更谈不上新知识的普及了，而是通过近乎随笔的方式（哈哈 发下它就是个随笔），大都采用了类比的方式来讲解。若非本书涉及OS/360等案例的解释，本书更像是设计学方面的书籍。包括人员的分配、设计、工程的实施、测试等各方面的知识。

有必要提下 本书作者视角：项目管理者的角度（重温了一遍，作者也是类似建议的）

首先我们对个人最感兴趣的章节进行简要的介绍

1.焦油坑

    “焦油坑”巨兽在中垂死挣扎的场面令人震撼，作者以此类比大型软件开发中出现的“软件危机”的现象。表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。---编程--- 一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。

2.人月神话

     向一个已经延后的项目中投入更多的人力资源只会让它更延后 。这里还给出了个"孕妇和宝宝的例子"。缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。所有的编程人员都是乐观主义者。系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间。系统工作量不能简单的用人月衡量，人员不断地增加后，交流等费用不仅仅是线性增加这么简答。系统开发过程中“1/3计划 1/6编码 1/4构件测试和早期系统测试 1/4系统测试”是一个较为合理的进度安排。因为不为系统测试安排足够的时间简直就是一场灾难。

3.外科手术队伍

    --精英--团队--程序员--之间的权衡。精英即工作效率是平通程序员10倍的程序员（事实证明是存在的）。需要协作沟通的人员的数量影响着开发成本，这一点，也暗示系统应该由尽可能少的人员来开发。精干的团队往往能更迅捷的设计更好的产品。然而小型、精干队伍对于真正意义上的大型系统太慢了。对于效率和概念的完整性来说，最好由少数干练的人员来设计和开发，而对于大型系统，则需要大量的人手，以使产品能在时间上满足要求。Brooks给出了磊外科手术整容的人员组织建议。这方面将在后面的内容中详细介绍。

4.贵族专制、民主政治和系统设计

    如何获得概念完整性。处于大型项目进度的压力，由非常少数互有默契的人员来实现是不现实的。有两种方法可以解决这种矛盾。第一种是仔细地区分设计方法和具体实现。第二种是前一章节中所讨论的”外科手术队伍“。