阅读 72

《人月神话》读书笔记摘抄(上)

前注

1、引用部分表示是该内容引用原文。

由于篇幅所限,引用的原文会摘抄、省略部分语句、或补充一部分以增加表达性。但会确保尽可能和原文保持一致。

2、引用部分后的 Pxx 表示是书籍的第 x 页。

3、页码之后是我个人评论。

4、书籍采用的是《人月神话》四十周年纪念版。

5、本文包含第二~第六章节。

第二章节:人月神话

系统编程的进度安排背后,第一个错误的假设是:一切将运转良好,每一项任务仅花费它应该“花费”的时间。

P15。

结果就是所有由没有丰富开发经验的人所评估的工期,都会导致项目比预期时间 delay。

结果,要么就是团队成员疲于加班,要么就是项目延期。


第二个谬误的思考方式是在估计和进度安排中,使用的工作量单位:人月

P16

这里的人月,指的是工时计算 m 人 * y 月(日) 的工作量。

该公式的成立,仅限于可以完全分解的任务,并且他们之间不需要相互交流。

实际上,当需要更多的沟通交流时,2 个人每日的工作效率并不是 2 人日,而是 1.8 人日,如果人数继续上升,人均效率还会再次下降。甚至可能会出现 5 个人的开发效率,反而不如 2-3 个人的开发效率高。


某些任务的计划进度,可能受限于顾客要求的紧迫程度,但紧迫程度完全无法控制实际的完成情况。就好像约好在两分钟之内完成一个煎蛋……(略)一面已经焦了,而另一面还是生的。

P21

甲方的要求是很难拒绝的,但无底线的接收甲方的要求,结果只可能是毁灭性的——交付一个非常糟糕的项目。

一个又能合理应对甲方,又可以保证项目工期不至于被无止境的压缩的解决方案是:

【在项目中做一个看起来技术含量比较高,但实际开发工期并不久的功能。然后告诉甲方,我们有一个非常 cool 的东西,他非常先进,是业内最先进的技术,但需要更多的工期。】

也就是说,我们预期 3 个月的工期,报给甲方的是四个月~五个月(实际并不需要那么久),在甲方要求压缩工期后,时间变回我们预期的 3 个月的工期。于是项目顺利的按期完成了。

当然,这需要公司有水平比较高的开发人员,可以跟进比较潮流的技术,并运用到项目里。

第三章节:外科手术队伍

这些研究表明,效率高和效率低的实施者之间个体差异非常大,经常能够达到数量级的水平(差异)。

P29

xxxx(三个外国人,名字略),曾对一组具有经验的程序人员进行测量,在该小组中,最好的和最差的表现在生产率上平均为 10:1;在编程速度和空间上具有 5:1 的惊人差异!简言而之,2万美元的程序员的生产率,可能是 1万美元的程序员的 10 倍。

P30

根据我的经验来看,假如初级开发人员的效率是 1,那么中级开发人员在 3-5,而高级开发人员 从 10~50 都是存在的。并且某些功能,只有高级开发人员有办法实现。

这也就是为什么,各种互联网大厂,宁愿花 2w~3w/月,甚至更多的薪资去请一个高级开发人员,而不是选择用 8-10k/月的薪资,去请更多一般程序员。


(跳着节选一部分)Milss 的建议。一个团队以类似外科手术的形式组件:

外科医生:首席程序员;

副手:首席程序员的副手,能完成任何一个工作,但经验不如首席;

管理员:外科医生的老板,负责决定人员、薪酬、办公空间。通常不需要全职负责;

工具维护人员:负责管理工具,确保基本服务的可靠性(这个类似运维);

测试人员:搭测试平台,提出测试方案和测试用例。

P32~P34(略去了一些国内少见的人员职位,原文共 10 个角色)

简单来说,这个就是明确一个开发团队的将和兵,以及一些重要的工具人。

由首席程序员定技术方案(而不是民主讨论),其他人负责执行该技术方案,并确保项目高效率沟通交流。让不同角色的人专心于自己的任务,越专一,效率越高。

换句话说,系统是一个人或者最多两个人思考的产物,而其他专业人员负责解决问题。当人员之间出现分歧时,由外科医生(首席程序员)来决定使用什么方案,达成客观上的一致性。

这种方案是一个大概 8~20 个人的团队。当系统需要更多的开发人员时,首席程序员将在同样的团队结构里,担任专业人员的角色(即承担一个功能的开发角色),由更高级的首席程序员分配任务。

第四章节:贵族专制、民主政治和系统设计

概念的完整性:

在系统设计中,概念完整性应该是最重要的考虑因素,也就是说,为了反映一系列连贯的设计思路,宁可省略一些不规则的考虑特性和改进,也不提倡独立和无法整合的系统,哪怕它们其实包含着许多很好的设计。

P42

简单来说,秀技一时爽,整合火葬场。

软件工程开发不是一个人的事情,需要更多考虑工程的可持续性和统一性,以及长期可维护性。

切忌不能为了个人喜好,而加入一些自己觉得很 cool 的东西。这会导致不同系统在整合的时候,遇见极为复杂的问题。


概念的完整性要求设计必须由一个人,或者非常少数互有默契的人员来实现。

系统的概念完整性,决定了其使用的容易程度,不能与系统基本概念进行整合的良好想法和特色,最好放到一边,不予考虑。但如果出现了很多非常重要但不兼容的构想,就应该考虑抛弃原来的设计,对不同基本概念进行合并,在合并后的系统上重新开始。

P44

在软件开发领域,民主应该是位于受限范围内的。

具体来说,某些基础性的概念,如代码规范、接口规范、使用的基本框架和库等,应该是统一的(即专制),而在具体某个功能的实现上,可以允许民主,各人找到合适的开发方式。

也就是所谓的,戴着镣铐跳舞。

第五章节:画蛇添足

对于系统设计师来说,一种普遍的倾向是过分地设计系统,向系统添加很多修饰功能和想法。

P55

简单来说,需求负责人、产品经理、架构师以及软件开发人员,他们往往会进入一个误区,就是过度设计。

也就是说,设计了很多功能,耗费了很多工时,但实际上,相关人员使用的并不多(并且这个功能不一定是甲方提出的要求)。

解决方案其实很简单,做一个日志系统,用于记录用户对页面的访问量,以及对功能的使用率。并且以数据作为依据,提供给用户作为参考。减少用户浪费的金钱和时间,并把节约的时间,用在开发更有意义的功能上。


第六章节:贯彻执行

对于在整个设计中,保证这些看似琐碎的问题处理原则的一致性,绝对不是一件无关紧要的事情。

P63

这里的所谓的琐碎问题,指的是前文中提到的一些看似不重要的问题。例如,每次操作后,如何设置返回的条件吗。(可以理解为前后端交互时,异步请求返回的数据格式,是否格式统一)

这些问题看似没什么,也是很简单琐碎的事情。但若不统一规范,将带来额外的沟通成本,也容易产生一些无谓的 bug。无数个这样的小问题积累起来,带来的后果会超出预料的。

所以一般要统一规范,以前后端交互来说,当返回请求结果时,应该调用封装好的方法,将结果返回给用户。如此可以确保返回数据的统一。


无需多说,会议是必要的。然而,数百人在场的大型磋商会议往往需要大规模和非常正式地召集。因此,我们把会议分为两个级别:周例会和年度大会——这实际上是一种非常有效的方式。

(略)(周例会中),如果达成了共识,非常好;如果没有,则由首席架构师来决定。这需要花费时间,最终所发布的结论是正式和果断的。

周例会的决策会给出迅捷的结论,使工作继续开展下去。

(略)(5)明确地授予首席架构师决策的权力,避免了妥协和拖延。

P66

原文里指的大型会议是数百人级别的,然而我们并不会去做这种需要几百人共同协作的软件开发。

对我们来说,更适用的是第二段所提到的周例会,从几个人到十几个人的单个小组,到几十人的跨部门小组协同开发时,需要举办的李慧。

周例会负责抛出问题,然后达成一致(或者由负责人定下一致的解决方案),然后解决问题,减少沟通成本。


电话日志:

对于存有疑问的实现人员,应鼓励他们打电话询问相应的架构师,而不是一边猜测一边工作。这是一个很基本的措施。(略)

一种有用的机制是,由架构师保存电话日志。日志中,记录了每一个问题和相应的回答。

P68~P69

本文初版比较久远。现在取代电话日志的是邮件日志。也就是说,对于一些问题,应该由邮件提出来,并通过邮件正式的回答。

邮件的机制有几个好处:

  1. 更正式,避免不停的变动导致带来的额外开发时间;
  2. 每个人都应该对自己提出的问题和做出的解答负责,减少了撕逼扯皮的成本;
  3. 可以存档,可以过一段时间回来查询当时的反馈是什么;

所以推荐对于简单问题,电话、钉钉、微信或者 QQ 沟通。

而对于复杂,又可能产生撕逼扯皮的问题,应该以邮件形式进行沟通,并抄送给相关负责人员,作为留存依据,降低沟通成本。

关注下面的标签,发现更多相似文章
评论