软件工程毕业，在北京工作两年后再来理解《人月神话》软件工程毕业，在北京工作两

软件工程毕业，在北京工作两年后再来理解《人月神话》，高中很向往信息技术，在高考填报志愿时，就以第一志愿，报考了成都一所高校的软件工程专业，幸运录取。《人月神话》这本软件工程领域经典书籍在我上大一时，就接触过，是院长给我们上第一节课的推荐。但当时读的并不是很明白，因为软件工程是一门，强调工程实践的学科，不进入企业参与完整的软件开发流程，积累丰富的软件开发经验，是难以理解这门工程学科。我在北京的一家互金公司，数据运营部门担任研发工程师两年后，再来重读，回顾这本《人月神话》，顿觉豁然开朗，感觉作者在这本书里记录的开发过程中所遇见的坑，也正是自己身边发生的事情。
背景介绍《人月神话》是作者FrederickP.Brooks.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而获得图灵奖还有冯诺依曼奖，他们在软件开发做出了伟大的贡献。
备注：《人月神话》中忽略的问题这本书忽略了，团队中成员的流动性，在今天这个高速发展的互联网时代，软件工程师的离职率往往很高，这在互联网公司很普遍，项目中工程师这样高的离职率，又有谁能保障项目质量，更何况谈项目进度，迭代开发等。
其次，传统的软件公司的产品，往往在研发过程中已经有了客户会为其产品买单，但在互联网公司的产品，面向市场，存活多久都是未知数，产品经理们，只希望工程师们把需求全部实现，能尽快上线，就上线。至于软件质量，软件的鲁棒性，健壮性，低耦合高聚合等，省省吧，老板需要的这个能什么挣钱，请记住，技术往往是不能盈利的，盈利的是产品。
说了这么多，软件工程这门学科，充满着魅力和神奇。在这里也应用布鲁克斯的一句话。