查看原文
其他

令人头大的代码审核

Bytebase 2022-05-27


作者 | 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 上的一系列主题贴提出了一个关于代码审核的基本问题:你是否把「运行代码」作为审核中的一部分?这些回答给了我很大启发,总结如下:

  1. 没有,但我会如此这般诱导开发者们自己进行代码运行

  2. 是的,因为忽视运行代码这一步给我留下过心理阴影

  3. 很少,因为我指望着自动测试

  4. 看情况,而且需要有一个确定的标准


谷歌的代码审核指南对这个问题表现得十分淡定:

如果你想的话,可以验证CL[审核中的代码]。

- 在代码审核中要注意什么,https://google.github.io/eng-practices/review/


谷歌的工程实践文档陆续提出了一些「必须确保已经进行代码运行」的情境:UI变化和并行 —— 在这些地方,个人很容易(或者说很可能)犯一个明显的(事后看来的)错误。但是其他情况下的代码审核呢?



对于优化代码审核过程提出要求


我们应该优化代码审核过程,以减轻审核人的决策疲劳。


这里有几个减轻他们精神负担的小技巧,供开发者们借鉴:

  • 拆分你的合并请求 (merge request) ,把它变成相互独立、小体量的多个合并请求

  • 添加一些测试和 linting 来预演代码

  • 撰写更清楚的提交信息

  • 在代码中添加注释

  • 要求他们进行更聚焦的审核 —— 例如设计审核 (design review) 或架构审核 (architecture review)

  • 写出更好的代码


    有些工具可以帮助你记录还有哪些积压的审核没有完成 —— Automattic 有 The Stick,微软有 Nudge。研究表明,这类代码审核提醒工具可以提升 60% 的审核速度。


    不过说到底,不存在什么灵丹妙药。代码审核中最残忍的回应就是沉默。有时你会眼睁睁看着自己的代码腐烂,等待最后的审判。这对每个人来说都很糟心。


    为了加速这个过程,我们必须努力减轻审核者的负担 —— 可以从对审核的范围达成共识入手。也许从「审核者是否需要运行代码」这个基本问题开始。这一问题的答案对于不同团队和不同类型的软件可能是不同的,但既然我们都在做审核,也许我们也都该有一套审核标准。


    什么是数据库 Schema Drift

    数据库代码化——黄金三镖客

    高可用性云服务怎么做?

    Bytebase - 重新定义 DBA



    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存