-
你将一个包含大约 1000 行新代码的 Pull Request 提交评审;
-
你收到两条关于 code style 的评论,以及一个关于评审人表示他看不懂这些代码用途的问题;
-
你修复 code style 并回答评审人的问题,然后评审人通过你写的代码;
-
你把代码分支合并到 Master,双眼紧闭,紧握着拳头,紧咬牙关等待着结果。几分钟后,CI 完成。幸好,Master 没有崩溃。然而…
-
此后 6 个月,你一直战战兢兢,不知道代码何时会崩溃,以及以什么方式崩溃。
你可能经历过上述噩梦般的经历,那我们谈谈怎样改进这个流程吧!
实用的 Code Review 实践
在 Shopify,我们看重交付速度、学习以及长期发展。这些价值观虽然有时会产生冲突,但却引导我们不断尝试许多新技术,并推动团队变革。
我在本文总结了一系列 Shopify 内部使用的实用技巧。借助这些技巧,我们能交付经得起时间考验的有价值的代码。
术语说明:我们将 Pull Requests(PR)定义为合并到基础分支前进行 code reviews 的一个工作单元。Github 和 Bitbucket 的用户对这个术语很熟悉。
将 Pull Request 拆分为较小的代码段
这个方法很简单,可以成为提高 code reviews 工作流程最有用的技术。它之所以有效,主要有两个原因:
-
评审人心理上更容易接受开始和完成一小块代码的评审工作。更大的 PR 自然会让评审人推迟和拖延评审,并且在评审过程中被打断的可能性更大。
-
作为一名评审人,如果 PR 太长,就很难深入进去。要检查的代码越多,我们越需要耗费更多脑力来理解整个代码块。
将 PR 拆分为更小的代码段,让你有更多机会在更短时间内得到更深入的评审。
目前,我们无法设置一个适用于所有编程语言和所有类型工作的通用标准。对于内部的数据工程项目,我们原则上是要将 PR 控制在 200-300 行代码。如果超过这个阈值,我们一般会将它拆分成更小的块。
当然,我们也要注意不要将 P