重点检查重要部分的代码检查清单

代码审查清单以及明确的代码审查规则和准则可以使您的代码审查实践对您的团队更加有益，并显着加快了代码审查的速度。

研究表明，使用清单的代码审阅者的表现优于不使用清单的代码审阅者。 因此，无论您是新开发人员还是已经有经验的开发人员，都可以考虑使用代码审查清单。

成为您自己的代码审阅者

代码审查清单不仅对代码审查者有用。 相反，随着代码作者的更改，请遵循代码审查最佳实践，并首先成为自己的审查者！

因此，在发送代码进行审查之前，请确保：

• 该代码编译并通过静态分析而不会发出警告
• 该代码通过了所有测试（单元测试，集成测试和系统测试）
• 您已仔细检查拼写错误，并进行了清理（注释，待办事项等）。
• 您概述了此更改的含义，包括更改的原因以及更改的内容

除此之外，作为代码作者，您应与审阅者一起执行相同的代码审阅清单。

代码审查者的代码审查清单

作为代码审阅者， 寻找最重要的问题是您的任务。 挑剔比较容易。 但是，那不好。 在Microsoft进行的一项大型研究中，我们调查了出色的代码审查反馈的外观。 我们清楚地看到，揭示较大结构或逻辑问题的评论比专注于次要问题的评论更有价值。

这是代码审查清单起作用的地方。 一份出色的清单将您的注意力转移到重要且最有价值的问题上。 在下面，您可以找到一个清单，我在代码审查研讨会中也使用了该清单。 它分为十个单独的部分。 每个部分都会引导您解决几个问题。 因此，让我们开始：

实作

• 此代码更改是否按预期执行？
• 可以简化此解决方案吗？
• 此更改是否会添加不需要的编译时或运行时依赖项？
• 是否使用了不应使用的框架，API，库，服务？
• 是否没有使用可以改善解决方案的框架，API，库，服务？
• 代码是否在正确的抽象级别？
• 代码是否足够模块化？
• 您是否将以一种在代码的可维护性，可读性，性能，安全性方面更好的方式解决问题？
• 代码库中是否已经存在类似的功能？ 如果是这样，为什么不重复使用此功能？
• 是否有任何最佳实践，设计模式或特定于语言的模式可以大大改善此代码？
• 该代码是否遵循面向对象的分析和设计原则，例如单一职责原则，开闭原则，Liskov替代原则，接口隔离，依赖项注入？
  

• 逻辑错误和错误

• 您能想到代码不符合预期的用例吗？
• 您能想到任何可能破坏代码的输入或外部事件吗？

• 错误处理和记录

• 错误处理方式正确吗？
• 是否应该添加或删除任何日志记录或调试信息？
• 错误消息是否易于使用？
• 是否有足够的日志事件，它们是否以易于调试的方式编写？

• 可用性和可访问性

• 从可用性角度出发，所提出的解决方案是否设计合理？
• API的文档是否完整？
• 提议的解决方案（UI）是否可访问？
• API / UI使用起来直观吗？

• 测试与可测试性

• 代码可以测试吗？
• 它是否有足够的自动化测试（单元/集成/系统测试）？
• 现有测试是否合理涵盖了代码更改？
• 另外还有一些测试用例，输入或边缘用例吗？

• 依存关系

• 此更改是否需要代码外的更新，例如更新文档，配置，自述文件？ 如果是这样，这样做完成了吗？
• 此更改可能会对系统的其他部分产生任何影响，向后兼容吗？

• 安全性和数据隐私

• 此代码是否会针对安全漏洞打开该软件？
• 授权和认证处理正确吗？
• 是否安全地处理和存储了敏感数据，例如用户数据，信用卡信息？
• 是否使用了正确的加密？
• 此代码更改是否会透露一些秘密信息（例如密钥，用户名等）？
• 如果代码处理用户输入，是否解决了跨站点脚本，SQL注入等安全漏洞，是否进行了输入清理和验证？
• 是否从外部API或库中检索到的数据进行了相应检查？

• 性能

• 您是否认为此代码更改会对系统性能产生负面影响？
• 您是否看到提高代码性能的潜力？

• 可读性

• 代码容易理解吗？
• 哪些部分让您感到困惑，为什么？
• 较小的方法可以提高代码的可读性吗？
• 可以通过不同的函数/方法或变量名称来提高代码的可读性吗？
• 代码是否位于正确的文件/文件夹/软件包中？
• 您是否认为应该对某些方法进行重组以拥有更直观的控制流程？
• 数据流可以理解吗？
• 有多余的评论吗？
• 一些评论可以更好地传达信息吗？
• 会有更多注释使代码更易于理解吗？
• 通过使代码本身更具可读性，是否可以删除一些注释？
• 是否有任何注释掉的代码？

• 专家意见

• 您是否认为特定专家（例如安全专家或可用性专家）应该先检查代码，然后才能提交代码？
• 此代码更改会影响不同的团队吗？ 他们也应该对变更发表意见吗？

• 好吧，就是这样。 您查看并考虑了最紧迫的问题。 恭喜你！

  现在，我在代码审查研讨会中进行的练习之一是通过回答以下三个问题来与参与者反映在代码审查清单上：

  1. 您最关注代码检查清单的哪些部分？
  2. 您倾向于忽略哪些部分？
  3. 您是否认为其中某些观点比其他观点更重要？ 为什么？
     

  但是，编码风格和约定如何？

  也许在本练习中，您意识到我没有检查代码是否遵循正确的编码风格。 所以，这不重要吗？

  简短的回答，很重要。 清晰的编码风格指南是在代码库中保持一致性的唯一方法。 并且，一致性使代码审查更快，使人们可以轻松地更改项目，并使您的代码库可读性和可维护性。

  Google是做到这一点的一个很好的例子。 无疑，这使Google拥有了斋戒的代码审查周转时间之一 。

  首先，我建议使用Google 提供的多种语言的现成编码样式 。

  设定基本规则很重要，但要确保一劳永逸。 不要持续争论。

  清晰的编码样式可以加快代码审查的速度。 但是，仅当您通过工具自动执行它们时。 （ 点击鸣叫）

  自动化什么可以自动化

  但是，一旦决定了代码库的外观，就花一些时间正确安装和配置工具，以便代码格式化成为一个按钮的问题。

  此外，您还可以做更多的事情。 使用静态分析工具可以节省人工代码审阅者的时间。 值得一开始的努力。

  不要让您的审稿人检查工具是否可以检测到更可靠和更具成本效益的问题。 （点击鸣叫 ）

  尊重，谦虚和友善

  最后，代码审查反馈的质量不仅取决于您说的是什么，还取决于您说的如何。 因此，最好的代码审查反馈如果措辞不当，谦虚友善，则毫无价值。 对于初学者，请将您的反馈作为建议而不是要求。 例如，不要写“变量名应该是removeObject”。 说“如何调用变量removeObject？”。 有关更多输入，请阅读我的文章， 该文章介绍了如何提供尊重的代码审查反馈 。

  还有更多适合您的……

  您可以将整个清单下载为PDF或使用下面的图像。 另一份对您来说可能非常有价值的资源是我的免费代码审查电子书 。

  最后，您知道我可以帮助团队进行代码审查吗？ 查看我的远程代码审查研讨会 。

  

  先前发布在https://www.michaelagreiler.com/code-review-checklist/
  
  

  From: https://hackernoon.com/a-code-review-checklist-to-focus-on-the-important-parts-au4f3ykj