代码整洁之道--读书笔记(10)
代码整洁之道
简介：
本书是编程大师“Bob 大叔”40余年编程生涯的心得体会的总结，讲解要成为真正专业的程序员需要具备什么样的态度，需要遵循什么样的原则，需要采取什么样的行动。作者以自己以及身边的同事走过的弯路、犯过的错误为例，意在为后来者引路，助其职业生涯迈上更高台阶。
本书适合所有程序员阅读，也可供所有想成为具备职业素养的职场人士参考。
第十章 预估
预估是软件开发人员面对的最简单、也是最可怕的活动之一了。预估影响到的商业价值巨大，关乎声誉，也给我们带来了很多的苦恼和挫折。预估是业务人员和开发人员之间最主要的障碍，横亘在双方之间的种种不信任，几乎都由它引发。
10.1 什么是预估
不同的人对预估有不同的看法。业务方觉得预估就是承诺。开发方认为预估就是猜测。两者相差迥异。
承诺：
既然承诺了，就必须兑现。承诺是必须做到的。如果你承诺在某天做成某事，就必须按时完成。即便它意味着你必须每天工作12小时，放弃周末的休假，也不得不如此。
承诺是关于确定性的。其他人会把你的承诺当真，据此拟定计划。如果不能兑现承诺，他们的损失，以及你的声誉受到的影响，都是巨大的。不能兑现的承诺也是一种欺骗，只不过比明目张胆的欺骗好一点。
10.2 预估：
预估是一种猜测。它不包含任何承诺的色彩。它不需要做任何约定。
预估不是个定数，预估的结果是一种概率分布。
专业开发人员能够清楚区分预估和承诺。只有在确切知道可以完成的前提下，他们才会给出承诺。此外，他们也会小心避免给出暗示性的承诺。他们会尽可能清楚地说明预估的概率分布，这样主管就可以做出合适的计划。
PERT:
PERT的一部分内容就是对预估的计算方法。这种技术包含了一个非常简单而有效的办法，把预估变成概率分布，让主管们看懂。
通过对项目开发进度的三种不同角度预估，即乐观预估、标称预估、悲观预估。 然后求其期望值。
10.3 预估任务：
在预估时，最重要的资源是你周围的人。他们可以看到你看不到的东西。相比自己单干，他们可以帮你更精确地预估任务。
德菲尔法：
办法非常简单。一组人集合起来，讨论某项任务，预估完成时间，然后重复“讨论－预估”的过程，直到意见统一。
具体操作：
-
亮手指
大家围坐在桌旁。每次讨论一项任务。针对每项任务，都必须讨论这个任务涉及什么，什么因素会把它搞复杂，它应该如何实现。然后所有参与者把手埋到桌底下，根据自己的判断，伸出0～5个手指。这时候，主持人数1－2－3，所有人都把手亮出来。如果大家伸出的手指数相同，就开始讨论下一个任务。否则，就开始讨论为什么有分歧。如此重复，直到意见统一。
-
规划扑克
规划扑克的玩法非常简单。向参与预估的每位成员发出不同点数的牌。如果发给每个人的牌的张数在0到5之间，那么从逻辑上说，这就是亮手指游戏。挑一个任务进行讨论。到某个时候，主持人要求每个人出一张牌。团队成员根据自己的预估选出一张牌，背面朝外，保证其他人都看不到牌的点数。然后主持人让每个人亮牌。剩下的就和亮手指一样。如果达成共识，就表示认可了预估。否则把牌收回去，继续讨论这项任务。
-
关联预估
在关联预估中，所有任务都写在卡片上，卡片上没有任何关于预估的信息。让参与预估的人围成一圈站在桌子边或是墙边，把卡片打乱铺开。大家保持静默，只是卡片按照任务所需时间的长短排序，需要时间长的放右边，短的放左边。任何时候，任何人，都可以移动任何卡片，不需要关心之前是否有人移动过。如果哪张卡片移动过超过η次，就需要抽出来单独讨论。最终，静默的排序终止。大家开始讨论，详细了解排序意见的分歧所在，也可以通过简短的设计讨论或者手绘的线框草图来帮助取得共识。
-
三元预估
如果为单个任务做标称预估，德尔菲法是不错的办法。但是之前说过，大多数情况下需要做3种预估，才能得出概率分布。不论使用德尔菲法的哪种形式，都可以迅速得到每个任务的乐观预估值和悲观预估值。举例来说，如果选择使用规划扑克，可以要求大家根据悲观预估亮出纸牌，然后选择点数最大的那张。乐观估计也是如此，只不过是选出点数最小的那张。
10.4大数定理
预估是非常容易出错的，所以才叫预估。控制错误的办法之一是使用大数定律。该定律的意思是：把大任务分成许多小任务，分开预估再加总，结果会比单独评估大任务要准确很多。这样做之所以能提高准确度，是因为小任务的预估错误几乎可以忽略，不会对总的结果产生明显影响。
坦率地说，这也是比较乐观的想法。预估中的错误通常会被低估而不是高估，所以拆分再加总很难做到完美。不过，把大任务拆分成小任务分开预估，仍然是个好办法。有些错误会被忽略，而且拆分成小任务也更利于理解任务本身及其他意外因素。
10.5 结论
- 专业开发人员懂得如何为业务人员提供可信的预估结果，以便做出计划。如果做不到，或者不确定能做到，专业开发人员不会给出承诺。
- 专业开发人员一旦做了承诺，就会提供确定的数字，按时兑现。但是大多数情况下，他们都不会做这种承诺，而是提供概率预估，来描述期望的完成时间及可能的变数。
- 对需要妥善对待的预估结果，专业开发人员会与团队的其他人协商，以取得共识。
