进行了1000多次代码评审的经验分享 - DEV

20-06-09 banq

在过去的三年中,我已经审查了1000多个拉(合并)请求。在那段时间里,我学到了很多东西–主要是关于如何不审阅代码,如何减轻过程的痛苦,使高质量的代码产生什么等等。

拉取请求只需要做一件事

最好的办法是将请求合并成有意义的部分–一个请求只能解决一件事。

在进行代码审查时,您需要牢记很多事情。“这背后的意图是什么?” ,“这如何与其余代码保持一致?” 和“效果会很好吗?”。

当您有一个集中的拉式请求试图解决一个问题时,其中一些问题将变得更容易回答。

另一个重要方面是拉取请求的大小。更大的请求需要成倍增加的时间来审查。当我知道需要花15分钟以上的时间时,您将不得不等待几个小时。

较大的拉取请求也会有更多的错误,因此获得批准的时间也会大大增加。这意味着您可能需要等待几天才能获得批准的代码。而且,如果您的公司敏捷,那将增加合并痛苦的机会,而这仅仅是痛苦的。

自动化尽可能多的检查

审阅者必须牢记很多事情,其中​​还包括检查代码格式,是否存在适当的文档,可通过的测试等。我记得当时我不得不考虑所有这些因素,那是分散时间和精力的时间。

解决方案非常简单–将所有检查集成到CI管道中。基本上,每当有人提交拉取请求时,它就会运行所有检查,并且不允许在所有检查通过之前合并。作为审阅者,您将不必担心再次格式化。

自动化测试有助于确保作者没有破坏任何东西,并且测试仍在通过中。根据您的测试方法,这很容易成为您的拉取请求CI中最重要的检查。

与作者坐在一起检查代码

因为您能够与作者一起快速遍历代码并分享您的观点,所以它使审核过程更快。作者还可以更好地解释其方法背后的原因,例如是否尝试过某些东西以及为什么它不起作用。

因为您能够与作者一起快速遍历代码并分享您的观点,所以它使审核过程更快。作者还可以更好地解释其方法背后的原因,例如是否尝试过某些东西以及为什么它不起作用。

写评论时要体谅

如果您比代码的编写者更有经验,则需要考虑您怎么说的事情很重要。写得很好的批评可以使开发人员在将来变得更好,但也可能破坏某人的梦想。

我发现最有效的方法是提出开放性问题–这不是激进的,甚至鼓励开发人员进行批判性思考。这是否会比告诉别人解决方案花费更多时间?是的,短期的。但是从长远来看,您正在帮助他们成长,他们重犯错误的可能性较小。

因此,下次有人在for循环中而不是在循环之前打开文件时,没有明确指出,而是问“您如何在这里降低复杂性?”。这将意味着很多。

添加一个名为我在本地运行此代码的标志

最让我感到困扰的是,在一些小的请求中发现了一个错误,因此该功能根本无法正常工作。这意味着开发人员甚至没有运行代码-可能认为没有必要,因为更改很小。

发生几次之后,我添加了一个标记,称为“ 我在本地运行此代码”,从而完全解决了问题。我停止审查不在本地运行的代码。

这是我们的模板,每个开发人员在创建拉取请求时必须填写:

合并请求说明

  • 有什么新东西?

    • 已实施...
  • 有什么变化?

    • 变了...

检查清单

  • []我在本地运行此代码
  • []我写了必要的测试
  • []我用类型提示覆盖了我的代码
  • []我更新了CHANGELOG

Trello卡

https://trello.com/c/

应该知道

  • 还有什么应该知道的吗?
  • 有部署说明吗?
  • 还有其他文件吗?

 

         

1

猜你喜欢