【译】送给你的代码审查问题手册

代码审查列表，是代码审查的明确规则和指导手册，它可以使代码审查为你的团队带来更多好处，并且能够显著提升代码审查的速度。

研究表明，使用代码审查列表的审阅者的表现要优于不使用的审阅者。所以不管你是新手开发者还是经验丰富的开发者，开始考虑使用代码审查列表吧。

代码作者应该关注的列表

作为代码的作者，你应该保证：

• 代码编译成功并且通过静态检查（没有警告）

• 代码通过所有的测试（单元测试、集成测试和系统测试）

• 你已经仔细检查了拼写错误，并做了处理（注释、todo等）

• 概述代码修改的原因以及修改了哪些地方

除此之外，作为代码作者，也应该在提交审查之前，按照审查者的列表对自己的代码进行审查。

代码审查者应该关注的列表

作为代码审查者，你的任务是寻找最重要的问题。评论会要对代码的结构性或逻辑性问题更有价值，即使有时候会显得挑剔。

你应该知道什么是好的代码反馈。另外需要注意，最好的代码审查反馈不是点评，而是建议。所以不要说“变量名称应该是removeObject“，最好说”调用变量removeObject怎么样？“。

下面这份列表足够帮助你提出好的代码审查反馈了。

实现

• 此代码更改会执行它应该做的事情吗？

• 这种解决方法是最简单的吗？

• 这个更改有引入一些不需要的编译时或运行时的依赖吗？

• 是否使用了不应该使用的框架、API、库、服务？

• 是否存在可以提升解决方法的未使用的框架、API、库、服务？

• 代码是否处于正确的抽象级别？

• 代码是否的模块化做的是否足够好？

• 你是否有其他的解决方案，该方案在代码可维护性、可读性、性能、安全方面表现更好？

• 是否已经存在类似功能的函数？如果有，为什么不复用？

• 是否有最佳实践、设计模式或特定语言模式可以优化代码？

• 代码是否遵循面向对象的分析和设计原则，例如单一责任原则，开闭原则，里氏替换原则，接口隔离，依赖注入？

逻辑错误或Bug

• 你能想到代码不按预期运行的任何用例吗？

• 你能想到任何可能破坏代码的输入或外部事件吗？

错误处理和日志

• 错误都被正确处理了吗？

• 是否有需要增加或删除的日志/debug信息？

• 错误消息对用户是否友好？

• 是否有足够的日志，它们的编写方式是否是易于调试的？

可用性和可访问性

• 从可用性角度出发，所提出的解决方案是否设计合理？

• API文档是否足够好？

• 提出的解决方案是否具备可访问性？

• API/UI是否直观易用？

测试与可测试性

• 代码是否达到可测试标准？

• 是否有足够的自动化测试（单元测试/集成测试/系统测试）？

• 现有测试是否合理覆盖代码变更？

• 是否有额外的测试用例、输入或边界用例以供测试？

依赖

• 如果这个修改需要更新代码以外的文件，例如更新文档，配置，readme文件。是否完成了这些更新？

• 这个修改是否会对系统其他地方造成影响？是否能够向后兼容？

安全和隐私数据

• 这段代码是否打开软件的安全漏洞？

• 权限和身份验证是否被正确处理？

• 是否安全处理了敏感数据，例如用户数据、信用卡信息等？是否正确使用加密方法？

• 代码更改是否显露了一些私密信息（如迷药，用户名等）？

• 如果代码处理用户输入，是否解决了跨站点脚本，SQL注入等安全漏洞，是否进行了输入清洗和验证？

• 从外部API或库中获得的数据是否进行了相应的检查？

性能

• 这段代码修改是否会对系统性能产生负面影响？

• 是否可以进一步提升代码性能？

可读性

• 代码是否容易理解？

• 哪一部分使你困惑，为什么？

• 可以通过减小方法来提高代码可读性吗？

• 可以通过使用不同的函数/方法或变量名称来提升代码可读性吗？

• 代码是否存放在正确的文件/目录/包？

• 你是否认为方法应该重构以拥有更直观的控制流程？

• 数据流是否可理解？

• 是否有多余的注释？

• 某些注释是否可以更好的传达信息？

• 是否更多的注释会使你的代码更容易理解？

• 是否可以移除一些注释，通过提升代码可读性来理解代码？

• 是否存在注释掉的代码？

专家意见

• 你是否认为特定专家（如安全专家或可用性专家）应该先检查代码，然后再提交代码？

• 这个代码修改会影响其他团队吗？他们也应该发表意见吗？

好了，以上就是最为紧迫的一些问题列表。

代码风格和约定

您的团队或公司必须拥有清晰的编码风格指南，这一点很重要。因为这是在代码库中实施唯一性的唯一方法。并且一致性会使代码审查更快，使人们可以轻松地更改项目，并保持您代码的可读性和可维护性。

Google是做到这一点的很好的例子，无疑，这使Google可以进行快速的代码审查。

首先，我建议使用现成的编码样式来支持Google提供的多种语言。设定基本规则很重要，但要确保一劳永逸。不要持续争论。

尽可能自动化

确定了代码风格以后，请花一些时间正确安装和配置工具，以便一键格式化代码。

另外还有很多事情可以做。例如使用静态检查来代替部分人工审核。这是值得为之努力的。

完整问题列表

原文链接

https://www.michaelagreiler.com/code-review-checklist/