人月神话（1）

光看名字，《人月神话》就是一部小说。一开始我也被它的名字吸引，想要探索一个奇幻的传奇故事，但是刚看了两页，我就发现了这本书的主角竟然是开发系统，哦不，是程序员。和有趣八竿子打不着。后来我就放弃了读它，因为我觉得除非是深入这个领域的专业人员，否则不会对它提起多少兴趣。后来每次它从我的阅读目录中出现的时候我都自然地忽略而过。直到一次上课时，讲的是计算机导论，最后下课，我在迷迷糊糊中看见老师的ppt上出现了它的名字。并且我听见了老师对我们说，这是一本很厉害的书。这时我才重新提起了对它的兴趣，决定把它当做一本并非消遣而读的书。

再次翻开《人月神话》，说实话还是索然无味的。因为它描绘的世界似乎离我很遥远。作者Brooks(不知道)用自己在IBM（不知道）公司任System计算机系列（不知道）以及其庞大的软件系统Os(不知道)经理时的实践经验为材料，真真实实地写出来的程序员们的”日常生活“。对啊，这么陌生的环境，就像首次面对高等数学一个感觉。

我理解标题是在我阅读了二十分钟后，虽然这个解释在不到10%的位置就有了，但是我不得不反复地看前几页来理解它到底在说什么。首先的问题就是，什么叫编程？其实就是写代码而已，没有什么复杂的定义。我想说的是如何来有效率地编程？其实我小的时候曾幻想过一个人做出一个游戏，让很多人玩，以此来获得快乐。现在想想报酬还得要金钱。不过我想说的也不是这个。对计算机稍有了解以后，尤其是高中的必修课中学了VB以后（顺便也学了c），每次回忆起我儿时的梦想我都觉得头疼。嗯，现在流行玩什么游戏？虽然各个地区游戏各异，但大多数都是moba吧。试问，让操纵的角色平A一下需要怎么编写程序？我简略地思考了一下，花的时间不多，也就五分钟。首先，先不提环境，要把这个角色的形象录入系统，包括从静止到动作结束的形态。帧数自定吧，经费多就多弄几帧。然后是攻击范围的程序，角色移动的程序，击中目标的程序，目标受伤减血的程序，还要加上效果音之类的，当然大环境还是最难的等等这诸如此类的问题。好了，完成了不知道多少分之一了。剩下的问题还有几个？我已经不想想了。说了这么多，只想证明一件事:在现在的信息社会中，除非你精通各领域的基础，而且能以一当百，否则程序员团队合作才是主流。这么一来，每个部分由多人来合作完成，工作量大大的减少，问题也大大地增多了。

我以前是没听说过焦油坑是什么东西，焦油倒是听说过。我的理解就是强力502。以前听到过这样一个问题：一个人搬一堆砖要八个小时，那么十个人要多长时间？就搬砖这个运动来说，人数变为原来的十倍，时间缩短到原来的十分之一貌似是理所应当的事。但是编程则不然。假设把一个庞大的程序分给三个个组来做，没问题啊，正常情况，就是应该分开做各个部分，这样毫无疑问，时间将会大大缩短，似乎完成得更有效率了。要是分给十个组呢？本书阐述了这个问题，增加的时间是呈指数增长的。原因是因为人数一多，互相沟通弥补程序上的漏洞的时间增多了。各个部分的人员由于互相不够了解，以及任务的不可分解性，最终会导致整个任务就像焦油坑一样，纠缠的越来越紧，以至于再也解不开了。其实我很难想象会有这种情况发生。程序员交流竟然比编程的时间长，这不是本末倒置了吗？实际上，一个项目中用时最短的就是编写源代码，剩下的大把的时间用在提前的计划和最后的调试上，这两项几乎要占掉整个过程四分之三的时间。当项目时间紧迫的时候，经理眼看着计划延时，这时候会怎么办？增加人手是最普通也是最符合常理的方法了。然而人增加的越多，所耗费的时间就越长，最后只能重复着一些无谓的进程，把最后的时间耗费掉。老实说，如果真的是来不及完成任务了，即使大多数经理了解这个事实，估计也仍会抱着可能会有奇迹发生的幻想增加人手，最终的结果不会改变。面对这种状况，理智而谨慎地消减部分非必要的任务，放弃一些细节才有可能把将要出界的球拉回来。由于不合理的计划，导致整个任务失败，是开发系统中最常见的案例。所以，不要再相信分配较多的人手，就能短时间内完成任务了，这是属于神才能涉及的领域，人月神话。

                                                                                                                        to be continue