人月神话(1)
光看名字,《人月神话》就是一部小说。一开始我也被它的名字吸引,想要探索一个奇幻的传奇故事,但是刚看了两页,我就发现了这本书的主角竟然是开发系统,哦不,是程序员。和有趣八竿子打不着。后来我就放弃了读它,因为我觉得除非是深入这个领域的专业人员,否则不会对它提起多少兴趣。后来每次它从我的阅读目录中出现的时候我都自然地忽略而过。直到一次上课时,讲的是计算机导论,最后下课,我在迷迷糊糊中看见老师的ppt上出现了它的名字。并且我听见了老师对我们说,这是一本很厉害的书。这时我才重新提起了对它的兴趣,决定把它当做一本并非消遣而读的书。
再次翻开《人月神话》,说实话还是索然无味的。因为它描绘的世界似乎离我很遥远。作者Brooks(不知道)用自己在IBM(不知道)公司任System计算机系列(不知道)以及其庞大的软件系统Os(不知道)经理时的实践经验为材料,真真实实地写出来的程序员们的”日常生活“。对啊,这么陌生的环境,就像首次面对高等数学一个感觉。
我理解标题是在我阅读了二十分钟后,虽然这个解释在不到10%的位置就有了,但是我不得不反复地看前几页来理解它到底在说什么。首先的问题就是,什么叫编程?其实就是写代码而已,没有什么复杂的定义。我想说的是如何来有效率地编程?其实我小的时候曾幻想过一个人做出一个游戏,让很多人玩,以此来获得快乐。现在想想报酬还得要金钱。不过我想说的也不是这个。对计算机稍有了解以后,尤其是高中的必修课中学了VB以后(顺便也学了c),每次回忆起我儿时的梦想我都觉得头疼。嗯,现在流行玩什么游戏?虽然各个地区游戏各异,但大多数都是moba吧。试问,让操纵的角色平A一下需要怎么编写程序?我简略地思考了一下,花的时间不多,也就五分钟。首先,先不提环境,要把这个角色的形象录入系统,包括从静止到动作结束的形态。帧数自定吧,经费多就多弄几帧。然后是攻击范围的程序,角色移动的程序,击中目标的程序,目标受伤减血的程序,还要加上效果音之类的,当然大环境还是最难的等等这诸如此类的问题。好了,完成了不知道多少分之一了。剩下的问题还有几个?我已经不想想了。说了这么多,只想证明一件事:在现在的信息社会中,除非你精通各领域的基础,而且能以一当百,否则程序员团队合作才是主流。这么一来,每个部分由多人来合作完成,工作量大大的减少,问题也大大地增多了。
我以前是没听说过焦油坑是什么东西,焦油倒是听说过。我的理解就是强力502。以前听到过这样一个问题:一个人搬一堆砖要八个小时,那么十个人要多长时间?就搬砖这个运动来说,人数变为原来的十倍,时间缩短到原来的十分之一貌似是理所应当的事。但是编程则不然。假设把一个庞大的程序分给三个个组来做,没问题啊,正常情况,就是应该分开做各个部分,这样毫无疑问,时间将会大大缩短,似乎完成得更有效率了。要是分给十个组呢?本书阐述了这个问题,增加的时间是呈指数增长的。原因是因为人数一多,互相沟通弥补程序上的漏洞的时间增多了。各个部分的人员由于互相不够了解,以及任务的不可分解性,最终会导致整个任务就像焦油坑一样,纠缠的越来越紧,以至于再也解不开了。其实我很难想象会有这种情况发生。程序员交流竟然比编程的时间长,这不是本末倒置了吗?实际上,一个项目中用时最短的就是编写源代码,剩下的大把的时间用在提前的计划和最后的调试上,这两项几乎要占掉整个过程四分之三的时间。当项目时间紧迫的时候,经理眼看着计划延时,这时候会怎么办?增加人手是最普通也是最符合常理的方法了。然而人增加的越多,所耗费的时间就越长,最后只能重复着一些无谓的进程,把最后的时间耗费掉。老实说,如果真的是来不及完成任务了,即使大多数经理了解这个事实,估计也仍会抱着可能会有奇迹发生的幻想增加人手,最终的结果不会改变。面对这种状况,理智而谨慎地消减部分非必要的任务,放弃一些细节才有可能把将要出界的球拉回来。由于不合理的计划,导致整个任务失败,是开发系统中最常见的案例。所以,不要再相信分配较多的人手,就能短时间内完成任务了,这是属于神才能涉及的领域,人月神话。
to be continue