开学时软件工程的老师推荐了我们一本关于课程的书——《人月神话》，听这个玄幻的名字当时我就产生了浓厚的兴趣，上网查阅相关资料之后我了解到这本书已经流传了30年，那个周末我便下单购买了这本书。不过后来事情较多一直放着没读，直到最近才开始拜读这本大作，就来随便写写简单讲讲这本书吧。
刚翻开书看了前言就感到这本书的不同，整个语言风格和以往看的专业书完全不同，语言风格十分轻松朴实。看到目录我更加不禁笑出声——焦油坑，人月神话，外科手术队伍……第一章——焦油坑的第一段文字：史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。第一反应这都是些什么鬼。随着慢慢的阅读，才意识到这事把软件危机比作了焦油坑。随着加深阅读，我不禁感叹到这本书语言的精巧，或者可能归功于译者深厚的文学功底。这本书对于软件工程中各种问题都有着自己独特的见解，精确的总结，以及恰到好处的比喻。让人一旦读起来就停不下来。
虽然这本书还没有完全看完，不过也看的七七八八了从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是人月神话、外科手术队伍、贵族专制、民主政治这几章。这本书里面为了论证某一观点，会举出许多实际的项目作为证据，我觉得这可能也是这本书传播如此之久的原因之一——事实胜于雄辩嘛！不过也许这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。下面就来简单介绍几段我印象深刻的部分吧。
书中指出，以大量人员和较短的时间，并不能缩短软件的开发进度。一窝蜂的作业方式无助于软件生产，且会制造麻烦，产生出更差的软件。向进度落后的项目追加人力，只会使进度更加落后。因为新进的人员需要时间了解整个项目，而增加额外的沟通消耗。当有 N 个人必须在这群人之中进行沟通时（无阶级关系），当 N 增加，其输出 M 将抵消其效益，甚至倒退（最后几天所完成的进度，远不如刚开始几天所完成的进度。像是发现了许多错误）。就好比现代战争相较于古代战争，过多的人力并不代表更强的战斗力，先进的技术手段才是胜利的根本条件。
软件工程是一门复杂的艺术,往往一个微小的功能，背后可能是许多程序员多日工作的结果，顾客眼前简单的一段段文字，可能是经过无数次的错误与修正得来的。然而只有在背后维护的人才知道这些工作的艰难，其他人认为这只是简单的工作。这也不是责怪那些误会的人，但是可以肯定的说，合理的软件工程计划对于整个团队来讲是多么重要。