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

1.焦油坑

职业乐趣

首先是一种创建事物的纯粹快乐。 是上帝创造世界的折射,一种呈现在每片独特、 崭新的树叶和雪花上的喜悦 。

其次,快乐来自于开发对其他人有用的东西。 我们期望其他人使用我们的 劳动成果,并能对他们有所帮助。

第三是整个过程体现出魔术般的力量 ,自己编写的代码通过啮合可以实现一些神奇的功能。

第四是学习的乐趣,来自于这项工作的非重复特性。

第五,乐趣还来自于工作的纯粹。 程序员凭空地运用自己的想象,来建造自己的“城堡”。

职业烦恼

事务总是二元对立的,有喜悦就有烦恼。故在享受Coding的乐趣前,还得清楚的知晓行业的烦恼,这样当他出现时,才能更坦然的面对。

首先,必须追求完美。 因为计算机也是以这样的方式来变戏法:如果咒语中的一个字 符、一个停顿,没有与正确的形式一致,魔术就不会出现。 这也是编程学习最困难的阶段。

其次,是由他人来设定目标,供给资源,提供信息。 个人的权威和他所承担的责任是不相配的。

第三, 概念性设计是有趣的,但寻找琐碎的 bug 却只是一项重复性的活动。 伴随着创造性活动的,往往是枯燥沉闷的时间和艰苦的劳动。( 人们发现调试和查错往往是线性收敛的,或者更糟糕的是,具有二次方的复杂 度。 )

最后, 当投入了大量辛苦的劳动,产品在即将完成或 者终于完成的时候,却已显得陈旧过时 。这也是一种无奈。

小结

快乐与烦恼兼得, 就是编程。一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。 对于许多人而言,其中的乐趣远大于苦恼。

2.人月神话

缺乏合理的时间进度是造成项目滞后的最主要原因。

导致原因:

首先,我们对估算技术缺乏有效的研究 ,认为一切都将运作良好。

第二,我们采用的估算技术隐含地假设人和月可以互换,错误地将进度与工作量相互 混淆。

第三,由于对自己的估算缺乏信心,软件经理通常不会有耐心持续地进行估算这项工 作。

第四,对进度缺少跟踪和监督。

第五,当意识到进度的偏移时,下意识(以及传统)的反应是增加人力。 就像用汽油灭火,只会让事情更糟。

乐观主义

本书认为所有程序员都是乐观主义者。毕竟我们总是说:“这个代码肯定可以运行,它没有问题!”并且深信: 一切都将运作良好,每一项任务仅花 费它所“应该”花费的时间。

人月

谬误: 在估计和进度安排中使用的工作量单位:人月。

为用人月作为 衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互 替换的。

理由: 人数和时间的互换仅仅适用于以下情况:某个任务可以分解给参与人员,并且他们之 间不需要相互的交流。这在割小麦或收获棉花的工作中是可行的;而在系统编程 中近乎不可能。

当任务由于次序上的限制不能分解时,人手的添加对进度没有帮助。无论多 少个母亲,孕育一个生命都需要十个月。由于调试、测试的次序特性,许多软件都具有这种 特征 。

原因: 因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流 的工作量非常大,它很快会消耗任务分解所节省下来的个人时间。从而,添加更多的人手, 实际上是延长了,而不是缩短了时间进度。

系统测试

顺序限制所造成的影响,没有哪个部分比单元调试和系统测试所受到 的牵涉更彻底。

对于软件任务的进度安排,作者根据经验有如下总结:

1/3 计划

1/6 编码

1/4 构件测试和早期系统测试

1/4 系统测试,所有的构件已完成

这在许多重要的方面与传统的进度安排方法不同。

  1. 分配给计划的时间比寻常的多。即便如此,仍不足以产生详细和稳定的计划规格说 明,也不足以容纳对全新技术的研究和摸索。
  2. 对所完成代码的调试和测试,投入近一半的时间,比平常的安排多很多。
  3. 容易估计的部分,即编码,仅仅分配了六分之一的时间。

理由: 很少项目允许为测试分配一半的时间,但大 多数项目的测试实际上是花费了进度中一半的时间。它们中的许多项目,在系统测试之前还 能保持进度。或者说,除了系统测试,进度基本能保证 。

不为系统测试安排足够的时间简直就是一场灾难。因为延迟发生 在项目快完成的时候。直到项目的发布日期,才有人发现进度上的问题。因此,坏消息没有 任何预兆,很晚才出现在客户和项目经理面前。 此时此刻的延迟具有不寻常的、严重的财务和心理上的反应。 二次成本远高于其他成本。

空泛的估算

计划进度,可能受限于 顾客要求的紧迫程度,但紧迫程度无法控制实际的完成情况。

我们需要两种解决方案。开发并推行生产率图表、缺陷率、估算规则等等,而整 个组织最终会从这些数据的共享上获益。

重复产生的进度灾难

当一个软件项目落后于进度时,通常的做法是什么呢?自然是加派人手。

现实: 这可能有所帮助,也可能无法解决问题。

这就是除去了神话色彩的人月。项目的时间依赖于顺序上的限制,人员的数量依赖于 单个子任务的数量。 在众多软件项目中,缺乏合理的时间进度是造成项目滞后的最 主要原因,它比其他所有因素加起来的影响还要大。

3.外科手术队伍

这些研究表明,效率高和效率低的实施者之间具体差别非常大,经常达到了数量级的水平。

These studies revealed large individual differences between high and low performers, often by an order of magnitude.

头等人才组成精英团队,虽然有着精彩的生产率,但是往往无法应对大型系统的开发。

Mills 建议大型项目 的每一个部分由一个团队解决,但是该队伍以类似外科手术的方式组建,而并非一拥而上。 也就是说,同每个成员截取问题某个部分的做法相反,由一个人来进行问题的分解,其他人 给予他所需要的支持,以提高效率和生产力。

4.贵族专制、民主政治和系统设计

让项目和谐统一,就需要使设计得到后继者的认同。

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

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

而现实存在的进度压力却要求让许多人员来一同开发。解决这一矛盾的方法有两种,第一是仔细的区分设计方法和具体实现。第二种即是组建团队。

在整个项目的开发团队中,作者认为结构师是“新贵”,而从事程序编写的人员则是“可怜的实现人员”。从而引起如下思考:

**是否所有的创造性活动 被那些精英单独占有,实现人员仅仅是机器中的齿轮?难道不能遵循民主的理论,从所有的 员工中搜集好的创意,以得到更好的产品,而不是将技术说明工作仅限定于少数人? **

5.画蛇添足

Adde parvum parvo magnus acervus erit.

如果将制订功能规格说明的责任从开发快速、成本低廉的产品的责任中分离出来,那 么有什么样的准则和机制来约束结构师的创造性热情呢? 基本回答是结构师和建筑人员之间彻底、仔细和谐的交流。另外,还有很多值得关注 的、更细致的答案。

尽早交流和持续沟通能使结构师有较好的成本意识,以及使开发人员获得对设计的信心,并 且不会混淆各自的责任分工。

  1. 牢记是开发人员承担创造性和发明性的实现责任,所以结构师只能建议,而不能支 配;
  2. 时刻准备着为所指定的说明建议一种实现的方法,同样准备接受其他任何能达到目 标的方法;

第二个系统往往是问题最多的系统,但是结构师无法跳过二次系统。不过可以有意识的关注哪些系统的特殊危险,运用别的自我约束准则,来避免哪些系统的特殊危险,运用特别的自我约束准则,来避免哪些功能上的修饰;根据系统基本理念及目的的变更,舍弃一些功能。

6.贯彻执行

He'll sit here and he'll say, "Do this! Do that!" And nothing will happen.

不管是什么样的团队,大型的,小型的,决策必须由一个或是两个人来制定,以确保决策的一致性。

形式化定义的优点: 形式化定义是精确的,它们 倾向于更加完整;差异得更加明显,可以更快地完成。

形式化定义的缺点: 但是形式化定义的缺点是不易理解。

记叙性文字则可以显示结构性的原则,描述阶段上或层次上的结构,以及提供例子。它可以 很容易地表达异常和强调对比的关系,最重要的是,它可以解释原因。

虽然形式化定义在表达上有令人诧异的效果,但它还需要记述性文字的辅助才能易于领会和讲授。

“ 决不要携带两个时钟出海,带一个或三个 ” 这也适用于形式化定义和记述性定义。 出于精确性的考虑,我们需要形式化的设计定义,同样,我们需要记叙性定义来加深理解。

结构师应该定期召开会议,以对实现人员提出的问题或修改意见进行解答/讨论。 对详细的变更建议做出决策。 如果达成了共识,非常好;如果没有, 则由首席结构师来决定,最终所发布的结论是正式和果断的。

7.为什么巴比伦塔会失败

... make such a babble of their language that they will not understand one another's speech.

失败原因: 缺乏交流,以及交流的结果的组织。

因为左手不知道右手在做什么,从而进度灾难、功能的不合理和系统缺陷纷纷出现。由于对其他人的各种假设,团队成员之间的理解开始出现偏差。

交流手段可以是正式或非正式的。

i 非正式

清晰定义小组内部的相互关系和充分利用电话,能鼓励大量的电话沟通,从而达到对 所书写文档的共同理解。

ii 会议

常规项目会议。会议中,团队一个接一个地进行简要的技术陈述。这种方式非常有用, 能澄清成百上千的细小误解。

iii 工作手册

在项目的开始阶段,应该准备正式的项目工作手册。理所应当,我们专门用一节来讨 论它。

结论:团队间的交流必不可少,手段不必拘泥。

posted @ 2020-09-16 22:03  琦桢  阅读(300)  评论(0编辑  收藏  举报