代码走查和代码审查
我们已经进行了大约4年的代码审查 。
代码审查入门
从一开始，开发人员就会互相帮助，在有人询问时查看代码，或者有时主管或高级开发人员会介入并检查代码，如果我们发现测试存在问题，或者是否有人刚刚加入团队并且我们期望他们需要一些额外的监督。 我们还聘请了专家来进行安全代码审查 。
启动系统后，我们决定主动进行基于风险的审查：我们要求任何在高风险领域（例如框架和安全性管道，API，核心业务逻辑或以前遇到问题的领域）编写代码的人。获得代码审查。 我们可以在那里停下来，并从代码审查中获得很多价值。 但是我们决定继续前进，并将代码审查作为一种标准做法。
这并非一夜之间发生。 让团队相信代码审查可以帮上忙，这并不难–他们已经从我们所做的基于风险的审查中看到了良好的结果。 但是很难改变人们的工作方式，并确保他们有足够的时间适当地进行评论：安排和执行评论的时间，以及理解反馈并采取行动的时间。 而且还花了一段时间才能提出有效的代码审查流程。
首先，我们要求开发人员选择一个伙伴并安排审核。 结果好坏参半。 有时，开发人员会四处找一个好人，或者很忙碌的人认为他们会轻易离开。 或两个开发人员会权衡取舍（如果您愿意给我看，我会告诉您我的），这样他们才能尽快获得审核。 由于人们不知道需要多少时间才能完成评论，因此评论通常被留到很晚，直到代码已经测试并发布后才完成。
而且由于大多数人没有很多进行评论的经验，所以他们不确定应该寻找什么以及如何给出有意义的反馈 。 开发人员感到沮丧（他告诉我要这样做，但是在另一次更改中，她告诉我应该那样做），有时会受到负面批评的困扰 。
最终，我们决定由潜在客户进行大部分审核。 尽管这增加了潜在客户的工作量，并意味着他们自己不能做太多的编码，但这在某些方面有所帮助。 与另一个碰巧可用的开发人员相比，首席开发人员通常对要求和代码应该做什么有更好的理解，这意味着他们有更大的机会发现真正的错误。 而且由于同一个人正在执行大多数评论，因此开发人员会收到一致的反馈。
我们如何进行代码审查
这些年来，我们的评论方式几乎保持不变。
无论是谁编写代码或代码做什么， 都 将检查非平凡的代码更改（ 在签入之前或之后 ）。 我们没有使用投影仪或打印输出召开正式的审核会议，也没有发现有必要使用诸如Code Collaborator或Crucible之类的审核工具或Google或Facebook用于管理和跟踪审核的内部工具，尽管看起来尽早采用这种工具可能有助于团队更好地开始工作。
有时，审核是面对面进行的，但大多数情况下都是脱机完成的：审核员和开发人员通过电子邮件交换信息，甚至通过电子邮件交换补丁文件，因为我们发现这对每个人来说都更加方便快捷（尽管他们认为有必要，人们会见面以进行详细审查）。
随着时间的推移，变化是审阅者的寻找和发现。
正确性评论
似乎程序员花费更多的时间来争论在代码审查中寻找什么，而不是他们实际花费在进行代码审查上。
我们开始进行代码审查，以提高代码质量并查找在测试中未发现的问题。 这不是教无经验的开发人员如何编写更好的代码的方法，也不是在团队中传播有关代码工作原理的方法。 这些可能会带来快乐的副作用，但是复查应该确保代码正确运行。
审阅者没有使用冗长的检查清单 ，而是在查看代码时从询问一小部分问题开始：
- 该代码是否按照预期的那样工作 ，并且看起来逻辑正确？是否存在任何明显的编码错误或看上去有些混乱的代码？ 是否有明显缺失或不完整的东西？ 为确保代码正确运行而必须解决的问题。为确保正确性而进行审查是一项艰苦的工作–审查者必须花一些时间来理解需求，而要花更多的时间来思考代码并试图深入人心但是，即使没有很多时间或不熟悉，一位优秀的审稿人仍然可以看到明显的逻辑错误和疏忽，不一致（您更改了a，b和d，但您没有更改c。这是故意的吗？ ），常见的编码混淆（在比较中查找<而不是<=或有时>，出现一一错误，在计算或比较中使用错误的变量-买方代替卖方，邀请者代替被邀请者），剩下的调试代码偶然地，多余的代码和似乎不需要的检查以及其他看起来不正确或令人困惑的可疑代码。
审阅者还可以查找基本的安全问题（正确应用访问控制规则/角色，正确处理敏感数据），向后兼容以及API和语言功能的正确使用（尤其是对于团队新手而言）。
尽管我们不要求审稿人花费大量时间来审查自动化测试，但他们也可能会进行抽查以寻找测试套件中的漏洞-特别是如果他们发现明显的编码错误（这意味着某些测试要么丢失了或错误）。
- 这段代码看起来和其余代码库一样工作，是否遵循团队同意的样式和约定（缩进，标头，大写和命名约定，导入顺序...）？ 是否使用标准模板和自动格式设置规则？ 我们在这里不是在谈论完美的选择，但我们也不希望每段代码看起来都不同。 是否正确使用框架和公共库？ 它是否正确地遵循了我们希望人们理解和使用的大模式（MVC等）？我们希望开发人员尽早在团队聚集在一起并且每个人还在学习和探索的同时，就一致性和样式问题进行研究。 事实证明，这花费了更长的时间，并且造成了比我们预期更多的麻烦。 检查不仅繁琐，而且对于某些人来说，风格也可能是一种接近宗教的事情。 开发人员不会争论某事是否是错误，至少在他们了解问题所在和原因之后，再也不会争论。 而且大多数开发人员都喜欢学习如何更有效地使用框架或语言，只要这是以礼貌和尊重的方式完成的。 但是有些人在美学和风格上受到了严重的束缚，什么样的代码看起来更简洁或更优雅。
审阅者当然可以提供其他反馈，包括有关如何简化解决方案和改进代码的意见，建议和建议，但只要代码正确且遵循约定，我们便应由开发人员何时或是否根据此建议采取行动。
审查可理解性
随着时间的流逝， 您寻找的内容以及您从代码审查中获得的内容应该会发生变化。 因为代码已更改。 从事这项工作的人员（开发人员和审阅者）也发生了变化。
随着开发人员了解了更多有关如何在其IDE中使用代码检查器的信息，并且在我们找到了一些好的静态分析工具来自动检查常见的编码错误和不良的编码实践之后，审阅者更容易找到错误和不良的代码 。 这意味着审阅者可以将时间花在寻找更重要的设计错误，时序错误或序列记帐错误或并发错误（例如竞争条件和潜在的死锁）以及工具找不到的其他问题上。
随着团队在支持生产，故障排除和修复问题以及与Ops合作方面获得了更多的经验之后，审阅者开始更加仔细地研究防御性编程和运行时安全性 ：错误和异常处理（尤其是难以测试的异常条件） ），数据验证和限制检查，超时和重试，正确执行API合同以及日志记录和警报。 确保系统“ 不会崩溃 ”。
因为我们尽早解决了大多数一致性问题，所以过一会儿不再需要检查一致性 。 有很多代码，因此开发人员可以自然而轻松地在已有的代码基础上继续工作，并继续遵循现有的样式和模式。
但这也意味着还有更多的代码需要阅读和理解。 因此，代码审阅者更加关注使代码更难以阅读和理解的任何事物。 尽管对方法和变量名称之类的细节进行细微的讨论，以及是否需要注释或有意义的注释似乎并不那么重要，但所有这些都可以反馈到正确性上—审阅者不确定不确定代码是否正确，就无法判断代码是否正确理解。
审阅者还开始更多地寻找不必要的代码重复，因为当您必须进行更改时，克隆会为错误创造更多的机会 ，而那些尚未更新以使用新的库或API的代码，或不再需要的代码（尤其是如果您使用功能开关而又没有去掉它们的问题，或者没有完成或无法控制的重构。
理解而不是批评
评论是关于理解代码，并确保其工作正常， 而不是批评它 。
重要的是，不要争论“我认为好的代码是什么，而你认为好的代码是什么”。 评审永远都不应遵循“我知道好的OO代码应该是什么样子，显然您没有，所以让我向您展示。”
审查仅应涉及“我必须能够充分理解此代码，以确保其有效，并且即使我不会以这种方式编写代码，希望您没有（但我会把这部分保留给我自己）。”
当审阅者跨过这条线时，当涉及到人们的自豪感和职业自我价值感时，事情很快就会变得丑陋。
除了避免争执，浪费时间浪费时间提供反馈和建议，因为没人忙着去解决问题，或者他们不同意或者没有必要，所以没人会采取行动。 如果您想从评论中获得良好的价值，请让他们专注于重要的事情。
审阅者现在在查看代码时尝试回答的主要问题是：
- 此代码是否可以实现预期的功能？ 即使出现问题，它也会继续工作吗？审阅者一直在寻找与以前相同类型的明显逻辑和功能问题。 但是他们也问：如果遇到错误怎么办？ Ops能否分辨出问题所在？ 如果系统所依赖的其他部分发生故障，该怎么办？ 它会重试并恢复，还是会正常失败，还是会繁荣发展？ 这段代码有可能被垃圾传递给它，如果这样做会发生什么呢？ 它可以将垃圾传递到系统的其他部分吗？
- 我可以确定此代码可以实现预期的功能吗？ 我能看懂代码吗？ 我可以遵循所做的更改吗？ 代码可以维护吗？ 如果出现问题，我可以在生产中修复它吗？ 是否有任何代码太可爱或太聪明了？ 有什么明显，安全，简单的事情可以使代码更简单，更易于理解和更容易更改？
有些事情会随着时间的推移而变得更好，而另一些事情则不会
通过查看代码库随时间的变化， Michael Feathers发现大多数代码一旦编写就很少或从未更改过。 大部分更改都是一次又一次地更改到相同小的代码库百分比。
因为审阅者不断看到相同的代码被更改，所以它会更改其工作方式：
- 以前看过代码的审阅者不必花太多时间弄清楚正在发生的事情，他们了解上下文并有更好的机会了解更改以及更改是否正确完成。再次查看同一代码，审阅者可能会看到以前没有注意到的遗留问题。 他们应该能够就如何简化和改进代码提供更有价值，更简单的反馈。当然，这里也需要做出权衡。 审阅者也可能会使同一代码过时，并且不再足够仔细地查看。 随着时间的流逝，审稿人的偏见和盲点会越来越大。
- 随着审阅者与相同的开发人员反复合作，他们将彼此之间更加了解。 审阅者将了解要寻找的内容，开发者的优势和劣势是什么，开发者的倾向和偏见与盲点，他们倾向于犯的错误和疏忽的程度。更短，更简单，并且会减少误解。并且由于开发人员将对审核有更多的了解，因此他们将开始更加仔细地检查自己的代码，并尝试在审核之前进行查找。 这就是SmartBear的Jason Cohen所说的“自我效应” ：开发人员编写了更好的代码，因为他们知道有人会密切关注它，特别是如果有人尊重的话。 有人认为这是进行代码审查的最重要原因 –使开发人员更加谨慎地工作，因此在别人面前看起来并不愚蠢； 并考虑编写别人会阅读的代码 。
避免收益递减
像任何软件开发实践一样 ，您最终将看到代码审查的收益递减，尤其是如果您继续做相同的事情，以相同的方式寻找相同的问题。 您甚至可能会达到不值得花费代码或时间花费代码审查的地步。
这还没有发生在我们身上。 我们继续从评论中获得很多价值，现在也许更多。
即使我们的工具已经改进并且我们的测试能力得到了增强，我们仍会继续进行检查，因为错误检查工具，检查和测试会发现不同的问题和不同类型的问题 。 我们还发现，评审使测试更加有效和高效，因为开发人员和测试人员之间就来回发现和纠正的错误之间的来回往来较少。
现在，审查已成为人们工作方式的公认组成部分，我们不必花时间将代码审查的价值出售给团队或企业 。 只要认真对待代码审查，并且只要您关心编写好的代码， 就值得这样做 。
翻译自: https://www.javacodegeeks.com/2013/09/code-reviews-change-over-time.html
代码走查和代码审查
