6 个实用的 Code Review 实践技巧
共 4589字,需浏览 10分钟
·
2020-08-26 14:30
你为了完成任务疯狂地敲了三周代码;
你将一个包含大约 1000 行新代码的 Pull Request 提交评审;
你收到两条关于 code style 的评论,以及一个关于评审人表示他看不懂这些代码用途的问题;
你修复 code style 并回答评审人的问题,然后评审人通过你写的代码;
你把代码分支合并到 Master,双眼紧闭,紧握着拳头,紧咬牙关等待着结果。几分钟后,CI 完成。幸好,Master 没有崩溃。然而…
此后 6 个月,你一直战战兢兢,不知道代码何时会崩溃,以及以什么方式崩溃。
评审人心理上更容易接受开始和完成一小块代码的评审工作。更大的 PR 自然会让评审人推迟和拖延评审,并且在评审过程中被打断的可能性更大。
作为一名评审人,如果 PR 太长,就很难深入进去。要检查的代码越多,我们越需要耗费更多脑力来理解整个代码块。
用户要你造一辆车;
6 个月后,你造了一辆漂亮的保时捷;
你向用户展示这辆车后,他们问你这辆车能不能放得下他们的 5 个孩子和冲浪板。
更独立的评审单元,这意味着更好的审查质量;
受影响的人更少,因此可以聚集在更少的几个专业领域中;
原子性回滚,可以回滚小的 commit 或 PR。这是很有价值的,因为如果出了问题,就更容易确定错误是在哪里引入的,以及回滚哪些部分。
将易事和难事分开。假设有一个新特性,需要重构一个频繁使用的 API。你可以更改这个 API,升级十几个调用的站点,然后实现这个特性。你的变更中有 80% 不是功能上的变更,明显可以忽略掉,而 20% 是需要仔细注意测试覆盖率、预期行为、错误处理等等的新代码,并且可能要经过多次修订。对于每一个修订,评审人都需要浏览所有的修改以找到相关的部分。通过将其分成两个 PR,很容易就可以快速完成大部分工作,并优化评审工作,将主要精力投入到难点上。
评审人可以这样想:“这是我们自己的代码,我们该如何改进它呢?”
提出肯定意见!如果你看到有些代码部分写得不错,就加条评论表扬一下。这能让代码作者继续保持好的一面,并有助于他在心理上更容易接受改进建议。
代码作者不妨这么想,评审人的出发点肯定是好的,不要将评论当作是对个人的批评。
下表列出了一些存在不足的评审反馈,以及如何按以上建议进行重写的建议。
谁具备你正在构建的特性或组件的上下文?
谁精通你正在使用的语言、框架或工具?
谁对这一主题知之甚深,有自己的理解?
谁关心你所写代码的结果?
谁应该学习这些东西?或者,如果你是一名正在评审“老鸟的菜鸟程序员”,不妨抓住这个机会多多提问学习。别怕你的问题太幼稚,一个强大的团队会找时间来分享知识。
为什么这个 PR 是必要的?
谁会从中受益?
可能会出什么问题?
你还考虑过其他方法吗?你为什么决定采用这种方法?
这对其他系统有什么影响?
团队将达成共识。团队会更了解你的工作,除你之外,其他团队成员可以完善代码库的这一部分。
团队将共同承担责任。如果出现问题,不只是某个人的代码需要修复,而是整个团队的代码都需要修复。
最近热文
• 朋友入职中软一个月(外包华为)就离职了! • 川大 NLP 博士生被华为以 200 万年薪录用!分享以下科研及论文写作经验... • 程序员因接外包被判坐牢 456 天!两万字长文揭露心酸真实经历... • 为什么很多公司都不招大龄码农? 最近整理了一份大厂算法刷题指南,包括一些刷题技巧,在知乎上已经有上万赞。同时还整理了一份6000页面试笔记。关注下面公众号,在公众号内回复「刷题」,即可免费获取!回复「加群」,可以邀请你加入读者群!
明天见(。・ω・。)ノ♡