我是一家小型软件公司的七个开发人员团队的一部分，我正在尝试介绍常规的组代码和设计评论。过去我们进行了一些审查，但它是零星的。我想使其变得更常规。
我已经阅读了Code Complete和其他类似的资源，他们谈论了如何进行代码审查的机制，但是我无法找到有关如何选择要审查的内容的最佳实践。我们的代码库已有八年的历史了，涵盖了多种语言，因此可以参考很多内容。
我想到了一些可能会影响选择的因素：
我知道这不是绝对确定的问题，但是任何指导都是有用的。
一些与外围设备相关的问题：
Answers:
通常，您必须检查所有内容。如果一个新的应用程序具有2000 LOC，则必须审查所有2000 LOC。
这就是为什么有关于如何选择没有最好的做法是什么来审查。
如果您使用现有的大型代码库，而以前从未审查过，那么当您必须重写现有的大型代码库并选择从哪里开始时，这是同一回事。这在很大程度上取决于：
在代码库上（单个整体代码比一组单独的组件等更难重写/查看），
您的上下文（是否可以停止所有工作，而花三个月（三年？）仅用于重写/复审，还是只有在有空闲时间的情况下，才能稍作疏忽？
审核类型（您是否有要审核的检查清单？根据检查清单的项目，您可能首先要检查某些部分）。
如果我是你我会：
请遵循您链接到的第二个问题的第一个评论中提到的80％-20％原则。
考虑到100％理想是不值得的。就像单元测试的代码覆盖率100％一样，只是这种代码覆盖率几乎是不可能的或非常昂贵的。
从您最常使用和最重要的部分开始。如果代码库中有一个可以在公司网站上进行身份验证和注册新用户的库，请先对其进行审核，因为您肯定希望先发现安全漏洞，然后再进行黑客攻击。
使用现有指标来确定哪些内容更重要。如果代码库的一部分根本没有单元测试，而同等重要的另一部分则具有85％的代码覆盖率，请首先检查第一部分。如果代码库的一部分是由经验不足的开发人员编写的，并且引入的bug比其他任何同事都要多，那么请首先检查其代码。
在将所有新更改投入生产之前，请先进行检查。安装脚本，源代码，数据库更改，应有尽有！代码审查的全部目的是阻止不良代码进入生产环境。这是一个糟糕的组织方案，还是只是因为缺少某些东西而引入的错误。
重构您正在使用的当前代码与代码审查紧密结合。例如，当我查看代码时，如果包含错误修复程序的类中存在重复的代码，即使开发人员未在其修复程序中更改该代码，我也不会通过。我希望他们回去并删除重复的代码。
如果您不懈地进行重构，那么代码审查将非常有用。否则会浪费时间。
如果您将代码审查过程作为开发过程中的步骤，则代码库会随着时间的推移变得更好。更好的是，在代码审查积压为空之前，您不应该允许开发人员进行新功能或错误修复。这样可以确保完成代码审查。
如果存在需要重构的已知区域，但是将需要很长时间（例如1周或更长时间）来进行重构。然后，为该重构本身创建一个工作项，并将其添加为要处理的项。
首先，查看所有新代码以及对现有代码的修改。
在审查对现有代码的修改时，开发人员应遵循boyscout规则。留下比他发现更好的代码。
这并不意味着您必须将整个文件修复为完美。但这不应该使事情变得一团糟，而应该使其变得更好。也许可以通过将修改移入结构正确的新类中，并保留原始代码文件的其余部分不变（毕竟它可以正常工作）。
通过查看所有新代码和修改内容开始改进代码之后，作为开发人员，您应该知道应用程序的哪些区域需要最大的更改。然后，回顾这些内容，一点一点地讨论如何加以改进。
为了回顾代码，回顾10年前编写的代码是没有意义的，开发人员应该在这10年中有所改进。因此，仅学习您所知道的知识就没有意义了。
代码审查的目的是改善和纠正您当前正在犯的错误，并在团队中分享这些知识。
在我的项目中，对于大多数正在开发的作业/用户案例/错误，在大多数情况下我们都必须包含代码审查。我们正在使用Scrum /敏捷流程，并且在编写单元测试和完成代码审查之前，不会将故障单/故事移至构建阶段（这是QA的待办事项）。
为此，我们确实将Atlassian FishEye分析与结合JIRA + SVN的坩埚代码审查一起使用。
当开发人员检入特定故事的代码时，他在FishEye中创建了一个新的代码审查，他在其中选择了团队的其他成员来进行审查。
一旦代码审查完成（工具会突出显示所提交的更改，并允许在特定代码行中留下注释），开发人员将更正所提及的问题/实现建议的改进，并将故障单移至JIRA的“已构建”列中-这意味着故事是准备进行测试，并且此特定工作项不会再有代码更改。
这也确保在代码审查后重构代码时QA不会测试任何可能更改或可能损坏的内容。
总而言之，必须检查所有代码-这支持高质量的代码，通常可以提高代码的设计，可读性，可维护性和可测试性，并从长远来看提高开发性能。