Code Review 常见的5个错误模式

Code Review 的时候，每个人都会关心最佳实践，但最坏的实践有时可能会更有启示意义。

Code Review是研发团队必不可少的，但并不总是正确的。这篇文章指出了所有开发者在Code Review时或提交拉取请求时可能都会遇到的一些常见的错误模式，并对这些错误模式进行了总结：

错误模式：挑毛病
想象一下下面的场景。代码作者花了几个小时，甚至几天的时间来创建他们认为最有效的解决方案。他们考虑了多种设计方案，并选择了看起来最相关的路径。他们考虑了现有应用程序的架构，并在适当的地方进行了修改。然后，他们将自己的解决方案以拉动请求的形式提交，或者开始了代Code Review 过程，他们收到的专家反馈是：

“你应该使用标签，而不是空格。”
“我不喜欢这部分的大括号在哪里。”
“你的文件末尾没有空行。”
“你们的词库是大写的，应该用句子大写。”
虽然新的代码要与现有代码的风格保持一致是很重要的，但这些东西几乎不需要人工审核员来完成。人工审核员的成本很高，而且可以完成计算机无法完成的事情。检查是否符合风格标准是计算机可以轻松完成的事情，这就分散了代码审核的真正目的。

如果开发人员在代码审核过程中看到很多这样的注释，说明这个团队要么是没有风格指南，要么是有了风格指南，但检查风格还没有实现自动化。解决的办法是使用checkstyle等工具来确保风格指南已经被遵循，或者使用sonarqube来识别常见的质量和安全问题。而不是依靠人工审核员来警告这类问题，持续集成环境可以做到这一点。

有时，如果没有代码指南，或者内部代码风格随着时间的推移而变化，在不同的部分有不同的风格，那么这种自动检查可能会很困难。在这种情况下，有一些方法可以应用自动检查。例如，一个团队可以同意做一个单一的提交，应用约定的代码风格，并且不包含其他的更改。或者一个团队可以约定，当一个文件因为bug或功能而被更改时，该文件也会被更新到新的样式，而自动工具可以被配置为只检查更改过的文件。

如果一个团队有多种代码样式，而它没有办法自动检查样式，也容易落入下一个陷阱。

错误模式：不一致的反馈
每一个被邀请审阅代码的开发者，至少要多邀请一个意见，而且可能更多。每个人都可以同时持有不止一种意见。有时，Code Review 可能会陷入审查者之间关于不同方法的争论，比如说是使用流还是经典的for循环最好。如果团队成员对同一段代码有不同的意见，那么开发人员应该如何进