令人头大的代码审核
作者 | Tyler Cipriani
原文链接 | https://tylercipriani.com/blog/2022/03/12/code-review-procrastination-and-clarity/
People think they lack motivation, what they really lack is clarity
– James Clear, Atomic Habits
代码审核一脸无辜地提出了一个扎心的问题:「这段代码写得怎么样? 」这让人甚至搞不清楚从何谈起 —— 也就自然很容易导致代码审核遭到推迟。
在有这么多决定要做的情况下,审核者能做出最简单的决定就是选择退出 —— 等我精力好的时候再审。
这篇文章探讨了代码审核中各种头大的决策问题,之后探寻个人和制度层面对抗它们的策略。
代码审核是对我意志力的考验
对于不合理审核请求的混乱邪恶回应
即使只是针对一个很小的改动,代码审核也是一个相当大的任务。如果你的补丁 (patch) 又大又难搞,那么你是在要求我拿出多到足以移山填海的意志力。
当一次审核需要消耗过多份额的意志力时,我通常有几种回应方式:
守序善良:在还有足够能量完成审核的情况下尽量挤出时间。
中立:推迟审核代码 —— 并虔诚地焚香,祈祷它以某种方式消失。
混乱邪恶:爱谁谁吧 (YOLO),直接把它投入到产品中,你(开发者)自己处理后果。
这几种方式对开发者和审核者都不公平。
代码审核究竟从何下手
即使是非常基础的代码审核问题通常也需要审核者自己进行决策。
最近,Hacker News 上的一系列主题贴提出了一个关于代码审核的基本问题:你是否把「运行代码」作为审核中的一部分?这些回答给了我很大启发,总结如下:
没有,但我会如此这般诱导开发者们自己进行代码运行
是的,因为忽视运行代码这一步给我留下过心理阴影
很少,因为我指望着自动测试
看情况,而且需要有一个确定的标准
谷歌的代码审核指南对这个问题表现得十分淡定:
如果你想的话,可以验证CL[审核中的代码]。
- 在代码审核中要注意什么,https://google.github.io/eng-practices/review/
谷歌的工程实践文档陆续提出了一些「必须确保已经进行代码运行」的情境:UI变化和并行 —— 在这些地方,个人很容易(或者说很可能)犯一个明显的(事后看来的)错误。但是其他情况下的代码审核呢?
对于优化代码审核过程提出要求
我们应该优化代码审核过程,以减轻审核人的决策疲劳。
这里有几个减轻他们精神负担的小技巧,供开发者们借鉴:
拆分你的合并请求 (merge request) ,把它变成相互独立、小体量的多个合并请求
添加一些测试和 linting 来预演代码
撰写更清楚的提交信息
在代码中添加注释
要求他们进行更聚焦的审核 —— 例如设计审核 (design review) 或架构审核 (architecture review)
写出更好的代码
有些工具可以帮助你记录还有哪些积压的审核没有完成 —— Automattic 有 The Stick,微软有 Nudge。研究表明,这类代码审核提醒工具可以提升 60% 的审核速度。
不过说到底,不存在什么灵丹妙药。代码审核中最残忍的回应就是沉默。有时你会眼睁睁看着自己的代码腐烂,等待最后的审判。这对每个人来说都很糟心。
为了加速这个过程,我们必须努力减轻审核者的负担 —— 可以从对审核的范围达成共识入手。也许从「审核者是否需要运行代码」这个基本问题开始。这一问题的答案对于不同团队和不同类型的软件可能是不同的,但既然我们都在做审核,也许我们也都该有一套审核标准。