强制性代码审查的良好指南和做法[关闭]

我们正在尝试对每次提交进行强制性代码审查-对于几个冲刺，没有任何东西被未经过至少1个人（而不是作者）验证的主人掌握。我们从开发人员和管理层那里都买进了（这是一个令人惊奇的情况），我们希望获得一些众所周知的好处：

• 明显减少错误
• 更加了解项目周围发生的变化
• “我知道有人会看这个的，所以我不会偷懒” /反牛仔效应
• 增加项目内/项目间的一致性

但是我们正在引入一种已知的降低速度的方法，如果做错了，可能会在提交管道中创建一个愚蠢的官僚主义步骤，除了占用时间外什么也不做。我担心的事情：

• 评论只涉及尼特采摘
• （大作）人们在两行提交审查中提出了巨大的架构问题。
• 我不想在其他事情上偏answers答案。

虽然我们都是有理智的人，并且会进行大量的自我分析，但我们可以肯定地使用一些赢得战争的见识，以了解我们应该在审查会议中尝试完成哪些事情才能真正使评论对我们有用。您发现可以使用的一些准则和政策是什么？

1. 简短评论。

   长时间很难集中精力，尤其是在代码审查期间。此外，冗长的代码审查可能表明代码上有太多话要说（请参阅接下来的两点），或者审查成为对较大问题（例如体系结构）的讨论。

   同样，评论应该是评论，而不是讨论。这并不意味着代码的编写者不能答复，但不应变成长期的意见交换。

2. 避免检查太糟糕的代码。

   审阅低质量的代码对于审阅者和代码作者而言都是令人沮丧的。如果一段代码很糟糕，那么代码审查就没有用。相反，应该要求作者正确地重写代码。

3. 在检查之前，请使用自动检查器。

   自动化的检查器可以避免浪费宝贵的时间，这些错误会自动发现。例如，对于C＃代码，运行StyleCop，代码指标尤其是代码分析是在检查之前发现一些错误的好机会。然后，代码审查可能会花在机器上很难完成的工作上。

4. 仔细选择进行审核的人员。

   两个不能互相忍受的人不会很好地检查另一个人的密码。当一个人不尊重另一个人（顺便说一句，无论是审稿人还是作者）时，也会出现相同的问题。

   另外，有些人只是无法看到他们的代码经过审查，因此他们需要进行特殊的培训和准备工作，以了解他们没有受到批评，也不应将其视为负面的东西。毫无准备地进行审核将无济于事，因为他们将始终处于防御状态，不会听取对其代码的任何批评（将所有建议视为批评）。

5. 进行非正式和正式审查。

   拥有检查清单有助于将精力集中在一组精确的缺陷上，避免陷入挑剔的状态。此清单可以包含以下几点：

   • SQL注入
   • 对一种语言的错误假设会导致错误，
   • 可能导致错误的特定情况，例如操作员优先级。例如，在C＃中，var a = b ?? 0 + c ?? 0;对于想要添加两个可合并为零的空值的人可能看起来不错，但事实并非如此。
   • 内存的重新分配，
   • 延迟加载（有两个风险：一次加载同一件事，完全不加载），
   • 溢出，
   • 数据结构（例如，带有简单列表而不是哈希集的错误），
   • 输入验证和防御性编程，
   • 线程安全
   • 等等

   我在这里停止列表，但是根据精确作者的薄弱点，清单中可能包含数百个要点。

6. 逐步调整清单。

   为了长期保持建设性和有用性，应根据发现的错误随时间调整正式审核中使用的清单。例如，第一次非正式审核可能会发现SQL注入的一定风险。SQL注入检查将包含在清单中。几个月后，似乎作者现在对动态查询和参数化查询非常小心时，可以从清单中删除SQL注入。

我们几乎像一个清单：

• 给我看任务说明。
• 引导我浏览结果，并显示其效果。运行不同的方案（无效的输入等）。
• 告诉我通过测试。什么是测试覆盖率？
• 给我看代码-这就是我们寻找明显低效率的地方。

效果很好。

我认为，只要是对他人有控制权的人，管理员或主持人就可以删除不相关的评论，加快对需要快速审阅的事物的审阅。单一决策者。

这样做的缺点是该人必须将其作为主要任务，而他可能还要做其他事情，并且可能您想让最有经验的人担任该职位。

第二件事是尽可能地自动化！

• 控制空格
• 风格控制软件
• 代码审查之前自动构建
• 代码审查之前的自动化测试

这些东西将至少删除一些人们可能不需要真正评论的东西。如果它没有建立或有尾随空格，则不足以进行审查，请对其进行修复，然后再次申请审查。如果它没有构建或某些测试失败，那么显然它不够好。

它很大程度上取决于您的技术，但是发现可以自动检查的内容越多越好。

我们尚未赢得这场战斗，但这就是我们发现有用的东西。