别怠慢代码审查

在我工作过的许多软件商店里，代码评审的话题总是引起很多争论。经常有人问我对代码评审的看法，我的回答可能会让你大吃一惊。我不喜欢。为什么呢？让我说得更具体一点，我不喜欢在工作完成之后进行代码评审。

我确实喜欢在工作过程中不断进行的代码评审，这叫做成对编程。

配对编程=连续代码审查？

是的，这正是我要说的

想想看，你真的能比成对编程提供更好、更诚实、更具交互性的代码评审吗？如果两个开发人员共同开发代码的一部分，那么在编写代码的过程中会对其进行检查

我将转移一点时间来讨论代码评审中发生的一些常见问题，然后我将讨论成对编程如何解决这些问题

代码评审问题

1.不说真话

在代码评审中，没有人说他们认为代码有什么问题，而是挑选一些没有冒犯性的小东西，比如没有遵循的命名约定，这是没有价值的

很多时候，代码审查都被一种害怕侮辱正在审查的人的代码的恐惧所支配。这种弱代码审查没有任何好处。我甚至可以说它加强了编写坏代码的实践，因为坏代码是橡皮图章

2.自我

要想成功地进行代码审查，每个人都必须在门口检查自己的自我。这种情况很少发生。代码是经过创造性设计的东西；没有太多人能够对自己的劳动进行批评，对自己的艺术更是少之又少

没有谦虚和开放的精神，代码评审就没有任何价值，指出问题是一回事，解决问题是另一回事

3.对焦错误

代码评审中最常见的错误之一是关注格式、编码样式或命名约定，这些主题根本不属于代码评审

工具可以自动格式化代码，并静态分析编码样式或命名约定的问题。让人工审阅者审阅这些内容完全是浪费时间。

说真的，如果有人在代码评审时，没有对代码运行自动代码格式化程序，也没有运行静态分析工具，也没有修复在那里发现的问题，不要太粗鲁，只是善意地告诉他们，他们的代码还没有准备好进行评审

旁注：关于我们是否应该强制执行代码格式，或者强制执行编码样式，或者强制执行命名约定，经常有争论。是的！对！对！一致性非常重要！代码比书面代码更容易阅读，一致的代码更容易阅读。进行一次讨论，将自动工具放在一起自动格式化代码，并自动检查需求

不要花几个月的时间来编写你的特殊编码标准文档。使用任何数量的静态分析工具中的一些规则集，并开始强制执行它们。将它们作为构建的一部分，使签入因格式问题而失败，使IDE在保存时自动格式化。决定花括号和空格的完美位置远不如保持一致重要。只需选择一些内容并强制执行即可

代码评审应该关注代码的设计、结构和可理解性。代码评审永远不应该关注任何可以自动检查或强制执行的东西……永远！

4.匆忙和不一致

团队很少有时间或腾出时间进行代码评审。如果他们这样做了，代码评审就不一致，而且不适用于所有代码，这会导致代码值丢失。如果你在一个周界周围有一个巨大的围栏，而在一个大洞里人们只能爬进去，那么围栏就毫无价值了

如果代码没有经过深入的检查，那么代码检查是没有意义的。只需浏览代码并在这里选择几个变量名就没有好处了。如果你还没有准备好完全沉浸在正在检查的代码中，并深入了解它到底在做什么，那就不用麻烦了

配对编程来进行救援

成对编程就像即时代码评审一样，它通过有一个共同的目标并在代码中创建一个共同的所有权来解决许多问题

当您与团队中的不同成员配对时，您可能会更诚实，更少自大，关注问题而不是惯例，并深入研究代码

毫无疑问，我的首选操作方法是不进行代码检查，而是成对编程，每个监控人员都致力于源代码管理，如果发现问题，可以标记一些内容并进行讨论

如果配对编程不是一个选项怎么办？

好吧，试着做一个。配对编程是一个伟大的投资

但是，如果你不做配对编程，你绝对应该做代码检查。我可能会称赞代码评审中的一些问题，我提倡成对编程，但我们不要在这里含糊其辞

结对编程是进行连续或即时代码评审的更好方法。不进行任何形式的代码评审都是愚蠢的。

如果你有一个建筑团队在建造你的房子或者你的2000万美元的刮板，他们告诉你他们没有对已经完成的工作进行工程审查，你可能会当场解雇那家建筑公司。建筑软件的复杂程度比大多数实体建筑项目要高出好几个层次。如果你称自己为工程师，而不是定期对自己的工作进行审查，那么你只是一个玩“工程师”游戏的业余爱好者。

因此，如果您必须进行老式的代码检查，以下是一些我发现很有用的提示：

• 通过做一些练习来鼓励人们诚实，每个人都会检查一些不是您团队中任何人编写的代码。鼓励人们在检查代码时尽可能保持偏见。

• 设定您的期望值。代码检查不是审批流程，它们是一个改进过程。确保团队意识到这一点。代码评审是一个让代码变得更好、提高技能的地方。培养这种思维。

• 自动化所有挑剔的东西，设置编码标准、格式标准和样式标准。决定它们将结合在一起，或者让你有经验的人来做，但要做到，让合规性成为非选择性，并使之自动化。

• 制定一致的标准和实践来进行代码检查。留出足够的时间深入研究代码。制定和实施代码检查时间和方式的标准。

• 以身作则。主动要求团队成员查看代码并告诉您如何改进代码。询问是否有这样的问题可以做得更好。对反馈和改进表现出真正的兴趣，这种态度就会流行起来。