有效的代码审查

原文：https://medium.com/hackernoon/effective-code-reviews-e8ac466b9a2e

我登录 Github，注意到我有一个漂亮的蓝色徽章，表明我有一个未读通知。我团队的一名成员为我们的一个项目创建了一个拉请求，并请求进行代码审查。

我仔细检查了拉取请求，似乎没有任何问题。没有任何明显的安全问题，所有的代码都是正确格式化的，代码利用了我们正在使用的 React 和 Redux 设计模式。我对拉请求进行了评论，对我们将来可能需要考虑的事情进行了一些小的思考，批准了拉请求，并将分支合并到主服务器中。

我对合并更加有信心，因为 CI 服务器已经表示它通过了所有 lint 规则，通过了所有单元测试，并且所有故事书故事仍然有效。我在不到 5 分钟的时间内检查并合并了 pull 请求，因为我知道我不必检查琐碎的空白问题、函数名或许多其他小问题。我保持高水平，确保代码清晰、简洁，并且边缘情况得到处理。

但这不是一夜之间发生的。我确保当我们开始发展前端团队时，我们会一直进行代码审查——即使我们很忙，而且只是快速浏览。这有助于新团队成员对他们编写的代码充满信心。我们都理解进入系统的新代码。它还让人们分享他们在编写新功能或修复错误时的见解。

那么，如何让代码评审顺利进行呢？

开始进行代码评审

最难的部分是刚刚开始。首先，代码审查将是非常非正式的。如果你不是远程办公，我建议你亲自和他们见面，让他们浏览他们的代码，他们做了什么，为什么要这么做。不过，这不是审讯。确保心情放松。代码被评审的人不应该觉得他们是在为自己辩护，而是在分享写代码时做出的决定。

但是，开始的问题是，如果你以前没有进行过代码审查，可能会有很多关于编码风格、使用的设计模式或许多其他事情的争论。

如果你发现自己在争吵，停下来把它写下来，因为你会想要:

当你第一次开始做代码评审的时候，你可能会发现自己在走回头路。代码评审员要求清理一些代码行。编码员去清理这些线。评论者然后评论说他们没有修复它只是对了。

这些检查和修复的循环只是在浪费时间。它们浪费了可能正在编写新特性的评审者的时间，也浪费了只想继续前进的被评审者的时间。这种类型的评论似乎很武断，他们不会与任何人分享任何有意义的见解。

使用一个 CI 工具来自动检查和失败琐碎的事情:编码风格，失败的测试，错误的函数名，“禁止的”函数(比如 eval)。当您可以获得一个 CI 工具来自动查找这些内容时，不要浪费时间。

一旦你建立了你的 CI 工具，当你发现你自己和你的团队在为 BEM 和 OOCSS 风格名称这样的琐事争吵时，开始添加新的检查。

让代码评审成为创建新特性所必需的过程和文化的一部分。让每个人都去做。让初级开发人员审查高级成员的代码。有时，他们对语言特性有独到的见解，可以节省时间或更具性能。

记住，代码评审不是对另一个人的代码吹毛求疵。用电脑吹毛求疵。相信我，他们真的很擅长。你同事的时间很宝贵，所以要明智地使用它。关注安全问题、边缘案例、优化和架构。

你的代码评审的文化和做代码评审一样重要。确保你关注的是重要的事情，而不是 bikeshedding 并且你的团队将代码评审作为学习、改进和创造惊人特性的机会。

感谢阅读！如果你喜欢这篇文章，欢迎在 Twitter 上关注我。