在过去的三年中，我已经审查了1000多个拉（合并）请求。在那段时间里，我学到了很多东西–主要是关于如何不审阅代码，如何减轻过程的痛苦，使高质量的代码产生什么等等。
拉取请求只需要做一件事
最好的办法是将请求合并成有意义的部分–一个请求只能解决一件事。
在进行代码审查时，您需要牢记很多事情。“这背后的意图是什么？” ，“这如何与其余代码保持一致？” 和“效果会很好吗？”。
当您有一个集中的拉式请求试图解决一个问题时，其中一些问题将变得更容易回答。
另一个重要方面是拉取请求的大小。更大的请求需要成倍增加的时间来审查。当我知道需要花15分钟以上的时间时，您将不得不等待几个小时。
较大的拉取请求也会有更多的错误，因此获得批准的时间也会大大增加。这意味着您可能需要等待几天才能获得批准的代码。而且，如果您的公司敏捷，那将增加合并痛苦的机会，而这仅仅是痛苦的。
自动化尽可能多的检查
审阅者必须牢记很多事情，其中还包括检查代码格式，是否存在适当的文档，可通过的测试等。我记得当时我不得不考虑所有这些因素，那是分散时间和精力的时间。
解决方案非常简单–将所有检查集成到CI管道中。基本上，每当有人提交拉取请求时，它就会运行所有检查，并且不允许在所有检查通过之前合并。作为审阅者，您将不必担心再次格式化。
自动化测试有助于确保作者没有破坏任何东西，并且测试仍在通过中。根据您的测试方法，这很容易成为您的拉取请求CI中最重要的检查。
与作者坐在一起检查代码
因为您能够与作者一起快速遍历代码并分享您的观点，所以它使审核过程更快。作者还可以更好地解释其方法背后的原因，例如是否尝试过某些东西以及为什么它不起作用。
因为您能够与作者一起快速遍历代码并分享您的观点，所以它使审核过程更快。作者还可以更好地解释其方法背后的原因，例如是否尝试过某些东西以及为什么它不起作用。
写评论时要体谅
如果您比代码的编写者更有经验，则需要考虑您怎么说的事情很重要。写得很好的批评可以使开发人员在将来变得更好，但也可能破坏某人的梦想。
我发现最有效的方法是提出开放性问题–这不是激进的，甚至鼓励开发人员进行批判性思考。这是否会比告诉别人解决方案花费更多时间？是的，短期的。但是从长远来看，您正在帮助他们成长，他们重犯错误的可能性较小。
因此，下次有人在for循环中而不是在循环之前打开文件时，没有明确指出，而是问“您如何在这里降低复杂性？”。这将意味着很多。
添加一个名为我在本地运行此代码的标志
最让我感到困扰的是，在一些小的请求中发现了一个错误，因此该功能根本无法正常工作。这意味着开发人员甚至没有运行代码-可能认为没有必要，因为更改很小。
发生几次之后，我添加了一个标记，称为“ 我在本地运行此代码”，从而完全解决了问题。我停止审查不在本地运行的代码。
这是我们的模板，每个开发人员在创建拉取请求时必须填写：
合并请求说明
- 有什么新东西？
- 已实施...
- 有什么变化？
- 变了...
检查清单
- []我在本地运行此代码
- []我写了必要的测试
- []我用类型提示覆盖了我的代码
- []我更新了CHANGELOG
Trello卡
https://trello.com/c/
应该知道
- 还有什么应该知道的吗？
- 有部署说明吗？
- 还有其他文件吗？