江苏龙网

  1. 首页 > 人文 > >

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

作者|AlejandroLujan
本文最初发布于Shopify博客 ，
经原作者授权由InfoQ中文站翻译并分享 。
Codereviews是打造高效团队的重要方面 ， 这已经成为共识 。 关于这个主题 ， 有许多文章曾经讨论过 ， 比如这篇论文——《AnEmpiricalStudyoftheImpactofModernCodeReviewPracticesonSoftwareQuality》 。 现实中 ， 许多企业的无数团队都进行过某种形式的codereviews 。
而实际情况是 ， codereviews刚开始时 ， 人们的激情高涨 ， 之后 ， codereviews则流于形式 ， 或者要么反馈不清晰、要么让人难以执行 。 长久以往 ， 这让团队错失了加快学习、分享知识的机会 ， 最终难以提高代码的质量 。
在Shopify ， 我们不仅立足长远 ， 而且希望追求发展更快 。 以我们的经验来看 ， 优秀的codereviews实践对工程师的成长和我们所打造的产品质量有着巨大影响 。
噩梦般的编码经历这样一个场景相信很多人都很熟悉：
你刚刚加入一个新团队 ， 领导很快给你分配了一个编码任务 。 作为新人 ， 你特别想表现自己 ， 因为你想秀一下自己的编码水平 。 于是 ， 你接下来做了这些事：
你为了完成任务疯狂地敲了三周代码；
你将一个包含大约1000行新代码的PullRequest提交评审；
你收到两条关于codestyle的评论 ， 以及一个关于评审人表示他看不懂这些代码用途的问题；
你修复codestyle并回答评审人的问题 ， 然后评审人通过你写的代码；
【InfoQ|个实用的 Code Review 实践技巧，6】你把代码分支合并到Master ， 双眼紧闭 ， 紧握着拳头 ， 紧咬牙关等待着结果 。 几分钟后 ， CI完成 。 幸好 ， Master没有崩溃 。 然而…
此后6个月 ， 你一直战战兢兢 ， 不知道代码何时会崩溃 ， 以及以什么方式崩溃 。
你可能经历过上述噩梦般的经历 ， 那我们谈谈怎样改进这个流程吧！
实用的CodeReview实践在Shopify ， 我们看重交付速度、学习以及长期发展 。 这些价值观虽然有时会产生冲突 ， 但却引导我们不断尝试许多新技术 ， 并推动团队变革 。
我在本文总结了一系列Shopify内部使用的实用技巧 。 借助这些技巧 ， 我们能交付经得起时间考验的有价值的代码 。
术语说明：我们将PullRequests（PR）定义为合并到基础分支前进行codereviews的一个工作单元 。 Github和Bitbucket的用户对这个术语很熟悉 。
将PullRequest拆分为较小的代码段这个方法很简单 ， 可以成为提高codereviews工作流程最有用的技术 。 它之所以有效 ， 主要有两个原因：
评审人心理上更容易接受开始和完成一小块代码的评审工作 。 更大的PR自然会让评审人推迟和拖延评审 ， 并且在评审过程中被打断的可能性更大 。
作为一名评审人 ， 如果PR太长 ， 就很难深入进去 。 要检查的代码越多 ， 我们越需要耗费更多脑力来理解整个代码块 。
将PR拆分为更小的代码段 ， 让你有更多机会在更短时间内得到更深入的评审 。
目前 ， 我们无法设置一个适用于所有编程语言和所有类型工作的通用标准 。 对于内部的数据工程项目 ， 我们原则上是要将PR控制在200-300行代码 。 如果超过这个阈值 ， 我们一般会将它拆分成更小的块 。
当然 ， 我们也要注意不要将PR拆分得过小 ， 因为这意味着评审人可能需要检查好几个PR才能理解整体逻辑 。
使用DraftPRs你听过造一辆汽车与画一辆汽车的比喻吗？这个比喻是这么说的：
用户要你造一辆车；
6个月后 ， 你造了一辆漂亮的保时捷；
你向用户展示这辆车后 ， 他们问你这辆车能不能放得下他们的5个孩子和冲浪板 。
显然 ， 这里的问题在于目标不清晰 ， 团队没有收集到足够的反馈就直接构建解决方案 。 如果在第一步后 ， 我们先画一幅汽车的草图 ， 并将其展示给用户 ， 他们会问相同的问题 ， 这样就可以进一步了解客户需求 。 如此 ， 就为我们节省了6个月的工作量 。 软件也不例外 ， 我们可能会犯同样的错误 ， 在用户不需要的特性或模块上投入大量工作 。


推荐阅读


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

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