江苏龙网

  1. 首页 > 人文 > >

InfoQ|个实用的 Code Review 实践技巧，6( 二 )


在Shopify ， 一般用WorkInProgress(WIP)PRs来获得早期反馈 ， 其目标是验证方向（算法、设计、API等等选择） 。 尽早变更可以避免在细节、修饰、文档等方面浪费精力 。
作为一名写代码的人 ， 这意味着你要对变更工作方向持开放态度 。
在Shopify ， 我们信奉的原则是允许大家有自己的理解 ， 但不固执己见 。 我们希望大家能在有充足理由的情况下自信地做出决定 ， 但同时也能乐于学习其他更好的新方案 。 在实际工作中 ， 我们使用Github的DraftPRs ， 它们明确表明这项工作仍在流程中流转 ， Github不允许你合并一个DraftPR 。 其他工具可能有类似的功能 ， 至少你创建正常PR时可以加上一个WIP标签 ， 以明确表示该工作还处于前期阶段 。 这将帮助你的评审人专注于适当的领域 ， 提出适当的反馈 。
OnePRPerConcern除了行数外 ， 需要考虑的另一个维度是你的工作单元试图解决的问题数量 。 一个关注点可以是一个特性、一个错误修复、一个依赖项升级、一个API变更等等 。 你是否在重构的同时引入一个新特性？一次修复了两个错误？同时引入了类库升级和新的服务？
把PR分解为一个个单独的关注点 ， 它会产生下列影响:
更独立的评审单元 ， 这意味着更好的审查质量；
受影响的人更少 ， 因此可以聚集在更少的几个专业领域中；
原子性回滚 ， 可以回滚小的commit或PR 。 这是很有价值的 ， 因为如果出了问题 ， 就更容易确定错误是在哪里引入的 ， 以及回滚哪些部分 。
将易事和难事分开 。 假设有一个新特性 ， 需要重构一个频繁使用的API 。 你可以更改这个API ， 升级十几个调用的站点 ， 然后实现这个特性 。 你的变更中有80%不是功能上的变更 ， 明显可以忽略掉 ， 而20%是需要仔细注意测试覆盖率、预期行为、错误处理等等的新代码 ， 并且可能要经过多次修订 。 对于每一个修订 ， 评审人都需要浏览所有的修改以找到相关的部分 。 通过将其分成两个PR ， 很容易就可以快速完成大部分工作 ， 并优化评审工作 ， 将主要精力投入到难点上 。
如果你最终拿到手的PR包含多个关注点 ， 那么你可以将其分解为多个单独的块 。 这样能针对每一块进行单独的评审 ， 每次评审的迭代周期可以更快 ， 从而加速这个PR的总体评审周期 。 通常情况下 ， 有一部分工作能先快速完成 ， 避免代码烂到不能用以及引起合并冲突 。
InfoQ|个实用的 Code Review 实践技巧，6
文章图片
将PR分解成单独的关注点上例的PR包含三个不同的关注点 ， 我们将其进行拆分 。 可以看到 ， 每个评审人需要检查的上下文少了许多 。 最重要的是 ， 只要其中任何一个部分的评审完成 ， 代码作者就能一边等待其他评审反馈 ， 一边着手处理已经反馈的问题 。 在最极端的情况下 ， 代码作者会陆续收到各个部分的评审反馈 ， 几乎可以不间断地处理完这一系列PR ， 而不是完成初稿后 ， 等上几天（已经去忙其他的事） ， 然后最后再返回头来处理反馈意见 。
专注代码 ， 而不是人专注于代码 ， 而不是人 ， 这条实践谈的是人与人之间的沟通方式和关系 。 从根本上讲 ， 这是提倡我们尝试把注意力集中在如何改进产品上 ， 避免作者将评审意见当作对他个人的批评 。
以下是一些你可以遵循的技巧：
评审人可以这样想：“这是我们自己的代码 ， 我们该如何改进它呢？”
提出肯定意见！如果你看到有些代码部分写得不错 ， 就加条评论表扬一下 。 这能让代码作者继续保持好的一面 ， 并有助于他在心理上更容易接受改进建议 。
代码作者不妨这么想 ， 评审人的出发点肯定是好的 ， 不要将评论当作是对个人的批评 。
下表列出了一些存在不足的评审反馈 ， 以及如何按以上建议进行重写的建议 。


推荐阅读


上一篇：美股研究社|预计在2021年开业，沃尔玛山姆中国会员旗舰店开工建设

下一篇：江西盛赢|线上教育推广方法和渠道？