软件工程毕业,在北京工作两年后再来理解《人月神话》, 高中很向往信息技术,在高考填报志愿时,就以第一志愿,报考了成都一所高校的软件工程专业,幸运录取。《人月神话》这本软件工程领域经典书籍在我上大一时,就接触过,是院长给我们上第一节课的推荐。 但当时读的并不是很明白,因为软件工程是一门,强调工程实践的学科,不进入企业参与完整的软件开发流程,积累丰富的软件开发经验,是难以理解这门工程学科。我在北京的一家互金公司,数据运营部门担任研发工程师两年后,再来重读,回顾这本《人月神话》,顿觉豁然开朗,感觉作者在这本书里记录的开发过程中所遇见的坑,也正是自己身边发生的事情。
背景介绍
《人月神话》是作者FrederickP.*s.Jr.(布鲁克斯)在参与开发IBM360OS时,所记录的实践开发经验,布鲁克斯也被誉为“软件工程之父”,在1999年获得了计算机界的最高奖项——图灵奖,以表彰他在软件工程领域做出的杰出贡献。写这篇文章的目的,并不是想拾人牙慧,只是想记录,如何运用软件工程的知识,来解决工作中所遇到的问题。
项目进度落后时,加班还是加人?
当项目进度落后时,应当首先评估,项目进度落后多少,如果只是落后原定的开发周期一周的时间,应该选择加班,如果月级别以上的大落后,应该做的是重新安排进度或者削减任务。而为了追赶进度,而进行招人加人,这是最不可取的,无异于饮鸩止渴。
为什么不提倡加人?
向进度落后的项目中增加人手,只会使进度更加落后。(Adding manpower to a late software project makes it later)——《人月神话 第二章》
我们这里来看书中,引用的一个例子,原定项目A阶段需要三名工程师在一月完成,落后了一个月,落后的工作量为3人月(3人1月),横轴为月,纵轴为人,而这个时候为了追赶进度,按原定时间4月完成项目,现在剩下的工作量为原定的9人月(3人3月),需要的工程师人数为4.5个(9人月/2月),所以我们为了追赶进度,需要再招聘两个工程师,
但实际呢,在短时间内,无论招聘到的两名工程师能力再怎么优秀,他们都需要一位有当前经验的老员工(如果是结对编程,那需要的老员工就再多一倍)进行培训,如果培训需要一个月的时间,那么3个人月工作量就会被投入到原进度计划安排的工作中(按照国内的开发习惯,大部分项目交接和培训都是靠着工程师口口相传,这样可能需要培训的时间则更多),这样在第三个月的月末本应该完成的B阶段也没能完成,反而会突然激增7个人月的工作量。
加人,加什么样的人?
Sackman、Erikson 和 Grand 曾对一组具有经验的程序人员进行测量。在该小组中,最好的和最差的表现在生产率上平均为10:1;在编程速度和空间上具有 5:1 的惊人差异!简而言之20,000美元/年的程序员的生产率可能是10,000美元/年程序员的 10 倍。数据显示经验和实际的表现没有相互联系(我怀疑这种现象是否普遍成立)。——《人月神话 第三章》
在进行招聘的时候,我们应该根据岗位,来选择工程师,而不是随意根据工程师来调整岗位。假设现在需要招聘一名工程师,收到了10份简历,有的工程师能力优秀,但是要价比较高,有的人能力一般要价低。负责招聘的人,往往会根据应聘者的薪资要求,来选择招聘谁,这其实很不合理,我们来看看大厂的技术评级T1,T2,T3,每个级别的岗位薪资往往很透明,这样对来应聘的工程师,他们也会了解到从而不会提出超过岗位级别的薪资。我们现在缺少的工程师是T2级别,而应聘者的能力只有T1,即使他薪资要求再低,也不应该招聘他。因为优秀工程师与一般工程师的产出往往成几何倍。但他们的薪资差距却远远达不到。所以团队在进行招聘时,宁愿只需要3个20,000美元/年的优秀工程师,也不要6个10,000美元/年的一般工程师。
他们无法相互交谈,从而无法合作。当合作无法进行时,工作陷入了停顿。通过史书的字里行间,我们推测交流的缺乏导致了争辩、沮
丧和群体猜忌。很快,部落开始分裂——大家选择了孤立,而不是互相争吵。 ——《人月神话 第七章》
人月神话这本书无论是第三章外科手术的队伍,还是第七章 巴比伦塔为什么会失败,都提出了项目之间的交流这个重点,我们结合这两章来看看。团队成员越多,沟通成本越大,交流越困难。团队成员少,沟通更为方便,为了避免频发的落后进度,又要保障软件质量,所需要的是能力优秀的工程师。所以,项目团队应该是像外科手术团队那般,分工明确,少而精,并不是大而平庸。
没有银弹(没有一套技术栈能一劳永逸的解决所有方案)
寻求一种可以使软件成本像计算机硬件成本一样降低的尚方宝剑——《人月神话 第十六章》
在七十年代,感受到软件开发过程中,复杂性的增长,很多工程师希望找到某种方法或者技术,能一劳永逸的解决这个问题,布鲁克斯尖锐的提出这种想法不切实际,当然批评他的这种悲观观点的信件如雪花般飘来。现在在2018年来回顾,来解决所有软件开发中的“银弹”发明出来了吗。
对了,在后面的《人月神话》再版中,作者称面向对象编程思想为“铜制子弹”简称铜弹。不过在今天我看依旧很多人在批评OOP将编程变的复杂多变,但也丝毫不能掩盖奥利-约翰·达尔和克利斯登·奈加特因为提出OOP而获得图灵奖还有冯诺依曼奖,他们在软件开发做出了伟大的贡献。
备注:《人月神话》中忽略的问题
这本书忽略了,团队中成员的流动性,在今天这个高速发展的互联网时代,软件工程师的离职率往往很高,这在互联网公司很普遍,项目中工程师这样高的离职率,又有谁能保障项目质量,更何况谈项目进度,迭代开发等。
其次,传统的软件公司的产品,往往在研发过程中已经有了客户会为其产品买单,但在互联网公司的产品,面向市场,存活多久都是未知数,产品经理们,只希望工程师们把需求全部实现,能尽快上线,就上线。至于软件质量,软件的鲁棒性,健壮性,低耦合高聚合等,省省吧,老板需要的这个能什么挣钱,请记住,技术往往是不能盈利的,盈利的是产品。
说了这么多,软件工程这门学科,充满着魅力和神奇。在这里也应用布鲁克斯的一句话。
兴趣太多,令人兴奋的学习、研究和思考的机会也太多——多么不可思议的矛盾啊!这个神奇的时代远远没有结束,它依然在飞速发展。更多的乐趣,尽在将来。 ——Freder ick P.*s,Jr.