读：《Google 软件工程》 之 “度量工程”

🤔☕️🤔☕️🤔

• 开书首章，如此清晰准确的、实践型谷歌软件工程概念，最架不住的质疑就是，它听起来很好，可是它不能量化，顶多算是家全球顶级优秀公司的总结陈述，成功之后只挑选好的说，然后当然就是说什么都是对的。这样的质疑，并非毫无来由，而且真的掷地有声。

  再回到目录，往后翻：“第七章 度量工程生产力”，原来早有准备不服来战，赶紧翻开读，书中案例，就跟我们刚开始聊到的代码评审有关。

  这里我们先不讲书，先离开书，做个假设：如果真有度量代码评审这回事情，如果没有书本的案例，仅知道有这么个事情，仅知道要做这么个事情，如果把这个事情移交代给我，或者就是我想去做这件事情，怎么做不搞砸、怎么做算成功、怎么做算名垂青史，就是能写到书里，让人感到古怪又神奇的案例？

  直觉上，如果要度量代码评审相关方面，那大概率就是投入要有多少、实际效果多少，而且经验上也是有点困惑，说起来代码评审会改进代码质量，可到底是提高多少，还真没有好的数据，总不能说咱们暂停评审，看看停下来后我们会问题多出多少，然后再恢复后看是否能减少多少问题，用这样的对比实验数据，来说明代码评审的效果。这样的想法，想想好像是个法子，真要操作的话，那得说服多少人，就算说服自己，估计都没那么容易。

  再退一小步，既然说到度量，我们就先对它有个共识吧，至少对它的基本概念、它的适用范围，这些方面有些共识，不至于谈了半天共识，然后忽然像水里的小鱼，游着游着忽然间问到：水是什么？那只能尴尬死机了事。

  最基本的度量，举个例子就是我花多少时间做一件事情；稍微进阶的度量，举个例子就是，有个什么难度和范围的问题、我有怎样的能力和经验、预估要花多少时间做这件事情；再高阶的度量，我能回答能力和经验的哪些部分、分别出了多少力，让我办成这件事情的概率增加多少。

  如此说来，度量的基本款就是统计型、进阶款就是评估型、高阶款就是因果型。

  所谓统计型，就是做事情有记录、有归档，用历史参考数据来度量；所谓评估型，就是做完事情有复盘、有反思，用组织记忆和经验来度量，也可以称它为专业型；所谓因果型，就是反思总结出模型和因果关系，用概率权重来度量，更可以称它为科学型。

  放到我直觉上的代码评审度量，有评审、有记录处于基本统计型，大规模改动、关键部分改动，组织专家评审处于评估性，想到这些因素跟结果有关、猜测这其中的互相影响的因子，就当做猜想因果型。

  再翻开书，谷歌的度量案例，居然是关于“可读性”，这可是代码评审里，最尺度游走的部分，最容易送命的事情，拿这样的案例来讨论，除了勇气之外，更多的现实就是，谷歌玩出真正的度量效果。

  谷歌说，度量之前问这些问题，并且答案明确：

  1、期待什么结果及为何如此期待？

  2、如果结果正向，采取什么动作？

  3、如果结果负向，采取什么动作？

  4、谁对度量这件事及其中的方法认可，

  对前面这三个问题负责、并推进行动的产生？

  我有期待的结果，我去度量，我是把箭射出去，然后画靶子，结果枪枪十环嘛？假设没有最后一条，就是首先要认可度量本身，然后无论预期的结果或正或负，都对此负责并行动，那么绝对就是这个枪枪十环的结果，除非系统性舞弊，就像高考试卷的答案由自己拟定，不满分可真的没救了，否则的话，还真得把事情一五一十给做踏实。

  谷歌又说，还有个 GSM 的模型：

  G=Goal，目标要有期待，S=Signal，信号表示目标已触达，M=Metrics，指标就是信号可度量的几个点。

  无论是度量前的问答、还是度量用到的 GSM 模型，都把期待放在首位，无论如何结果会怎样，都要有点先写上想要的答案，怎么看怎么觉得有点怪的感觉。

  细细想来，这些点里有些微妙之处，可用三个词表达：认可、期待、承诺。

  认可是用来接受，无论结果是好还是坏，要么是不得不接受，要么是坦然接受，前者不一定认可，但是后者肯定在认可的基础上自然接受。认可是全方位的认可，认可做度量的团队，他们由软件工程领域专业人员、通才型软件工程师、认知心理学、行为经济学方面的社会科学家；认可度量的方法和手段，无论看起来多复杂、多难以理解；认可这群人和这些手段方法，结合起来所做事情的过程，以及最终的结果。

  期待是用来超越，正是这样的期待，以及在此之上的超越，才会产生真正的满足感，而这也正是谷歌软件工程的精神特质，关注参与其中人的感受。一个正常的期待，等于一个正常的确认。所谓正常的确认，就是在相关性里，挑选出关键因子，确立它们的因果性。所谓超越期待，就是发现在因果性确立的因子之上，还有可影响的因素，对那些因素施加操作，还会有更可期待的新结果。

  承诺是用来行动，说出去的话，并不是泼出去的水，而是喷在墙上的涂鸦，它会留在那里很久，它时刻提醒大家，要把涂鸦补充成有意义的故事。

  对于目标，或者说期待，那我手指向的地方，就是我们要攻占的山头。不。在谷歌得符合“QUANTS=数量”的山头。

  代码质量（Quality of the code）、工程师的专注力（Attention from engineers）、认知复杂度（Intellectual complexity）、节奏和速度（Tempo and velocity）、满意度（Satisfaction），为了凑齐这“数量=QU+A+N+T+S”，谷歌真是不容易。

  我把它们叫做“5S”，它比“4S”店更容易记住。这 5 个 S 都是 State：

  1xS：核心产物的状态，就是代码代码质量；

  2xS：工程师们开工前的状态，就是认知复杂度；

  3xS：工程师们干活时的状态，就是专注力；

  4xS：工程师们推进项目的状态，就是节奏和速度；

  5xS：工程师们完工后的状态，就是满意度；

  如果画个示意图，中间圆心是代码质量，它是核心产物，它是我们价值变现的代表，围绕圆心旋转的是认知复杂度、专注力、节奏和速度、满意度，他们是人，他们是根本。在谷歌设定目标，考虑人的因素，明显多余物的因素，即使这 4 项人的因素，实际比重不超过 80%，那至少也会有 50%。

  当我听说，我们要一起攻占那个山头，就会莫名有点兴奋，不知道这算不算，看到对我恶狠狠的凶狗时，我会本能假装蹲下捡石头，而那凶狗也会重点关注我手里是否真捡到石头，做出随时闪躲和逃避的预备姿势，这样刻入基因的本能，带来的这点小兴奋，如果再得知，拿下那个山头，会关注我开始、沿途、最终的状态，会在沿途给大家补给和帮助，哪怕只关注我一点点，我都会让这点小兴奋更坚定。只要与我有关，的确容易让我喜欢。

  而这时候的谷歌软件工程度量，居然还没有开始涉及到任何量化的数字。

    — by 术子米德 @2023 年 8 月 13 日