读《Software Engineering at Google》（07）

🤔☕️🤔☕️🤔

• 读《Software Engineering at Google》（07）—— Measuring Engineering Productivity

• 📖：@Google，搭建一支队伍，有软件工程研究领域的人、有技多不压身的软件工程师、有认知心理学家、有行为经济学家，专门研究和理解所谓的工程生产力。

  🤔：度量工程生产力，按时完工，算是其中一个维度嘛？在建筑类工程，在桥梁类工程，在基础设施类工程，说几个月、说几年，那基本上都是大差不差。可是在软件行业，在 IT 行业，预估几个月就完成，如果真按期完成，甚至提前完成，得到的可能不是喝彩，反而可能是疑惑。这件事情好罕见，莫非故意把工作量估少，再看一眼产物，还真不少，真是稀奇罕见。当然，还有一种按时交付，那就是死命催赶，交付时还带着点不屑，就这么点活还要干这么久至于嘛。为何在其它类工程，按时交付是如此可预期，在 IT 软件类工程，按时交付确实稀奇事。有点模糊的思路和想法。软件要边思考边生产，而其它类工程，一般都是思考和生产分离，即软件是脑和手一起动，而其它却是先动脑、再动手。那软件外包，算不算已经达到脑和手的分离，有点这个意思。也就是说，脑和手一起的软件工程，更可能是工程化的成熟度不够导致。如果老天再给软件行业五十年，是否都会进入脑手分离的工程模式。到那时候如果还在边思考边敲代码，就是在家里自己玩耍，不太可能是在规模型工程，会是如此嘛？不过脑手分离，是否也有必要条件，那就是最终手要做的部分，提前在脑思考阶段就有完整的信息和确定性。而实际上，需要编程解决的问题，并非都能满足这样的条件。这是否会让脑手不分离成为软件的宿命，也让软件工程的工期成为永远的不稳定性。

  🤔：从谷歌搭建队伍的组成来看，这的确是个难题，我那点粗浅的想法，真的就是点想法而已。这么多专家和高手，居然以“可读性（readability）”作为度量工程生产力的抓手，着实让我感到意外。不过回头想，软件工程里，最具有展现力的代表，可不就是代码，代码携带着解决问题的具体方法，代码更是兼具人和机器都能读懂，重点还是在于人能读。也就是说，代码的可读性，同时能代表工程的产量和品质，即所谓的生产力。

• 📖：GSM（Goal/Signal/Metric），先定目标（Goal），目标要好，再定信号（Signal），信号要明确，表示目标达成的信号，最后再考虑衡量（Metric）。先别考虑怎么验收，能够避免灯下黑。

  🤔：我要做个东西，估计吧，做成那样就算成了，然后咱们再看看，这么成了算不算好。这不是自己做好，然后夸自己好嘛。的确有这个嫌疑。可是，如果我一开始就知道怎么衡量，似乎是个确定的好事。实际上，这是一个认知上的短视。我现在就知道怎么衡量，一个致命的问题在于，未来的东西，在我现在的知识框架内。也就是所谓在路灯下找钥匙，我只会在路灯光线范围内找。可是，没人告诉我，钥匙到底在哪里，而我却用现有的认知认为它在我看得到的光线范围内。做好再说好不好，固然有它的缺陷。但是作为能在黑暗中找到钥匙，跟在路灯下找不到钥匙相比，必须选择勇敢跨入黑暗，去点亮后再看情况到底如何。

    —— By 术子米德 @2022.04.15