模板
教程
环境
性能
功能
管理
送给你的代码审查问题手册
代码审查列表，是代码审查的明确规则和指导手册，它可以使代码审查为你的团队带来更多好处，并且能够显著提升代码审查的速度。
研究表明，使用代码审查列表的审阅者的表现要优于不使用的审阅者。所以不管你是新手开发者还是经验丰富的开发者，开始考虑使用代码审查列表吧。
代码作者应该关注的列表
作为代码的作者，你应该保证：
除此之外，作为代码作者，也应该在提交审查之前，按照审查者的列表对自己的代码进行审查。
代码审查者应该关注的列表
作为代码审查者，你的任务是寻找最重要的问题。评论会要对代码的结构性或逻辑性问题更有价值，即使有时候会显得挑剔。
你应该知道什么是好的代码反馈。另外需要注意，最好的代码审查反馈不是点评，而是建议。所以不要说“变量名称应该是removeObject“，最好说”调用变量removeObject怎么样？“。
下面这份列表足够帮助你提出好的代码审查反馈了。
实现
-
此代码更改会执行它应该做的事情吗？
-
这种解决方法是最简单的吗？
-
这个更改有引入一些不需要的编译时或运行时的依赖吗？
-
是否使用了不应该使用的框架、API、库、服务？
-
是否存在可以提升解决方法的未使用的框架、API、库、服务？
-
代码是否处于正确的抽象级别？
-
代码是否的模块化做的是否足够好？
-
是否已经存在类似功能的函数？如果有，为什么不复用？
-
是否有最佳实践、设计模式或特定语言模式可以优化代码？
-
代码是否遵循面向对象的分析和设计原则，例如单一责任原则，开闭原则，里氏替换原则，接口隔离，依赖注入？
逻辑错误或Bug
-
你能想到代码不按预期运行的任何用例吗？
-
你能想到任何可能破坏代码的输入或外部事件吗？
错误处理和日志
-
错误都被正确处理了吗？
-
是否有需要增加或删除的日志/debug信息？
-
错误消息对用户是否友好？
-
是否有足够的日志，它们的编写方式是否是易于调试的？
可用性和可访问性
-
从可用性角度出发，所提出的解决方案是否设计合理？
-
API文档是否足够好？
-
提出的解决方案是否具备可访问性？
-
API/UI是否直观易用？
测试与可测试性
依赖
-
如果这个修改需要更新代码以外的文件，例如更新文档，配置，readme文件。是否完成了这些更新？
-
这个修改是否会对系统其他地方造成影响？是否能够向后兼容？
安全和隐私数据
-
这段代码是否打开软件的安全漏洞？
-
权限和身份验证是否被正确处理？
-
是否安全处理了敏感数据，例如用户数据、信用卡信息等？是否正确使用加密方法？
-
代码更改是否显露了一些私密信息（如迷药，用户名等）？
-
如果代码处理用户输入，是否解决了跨站点脚本，SQL注入等安全漏洞，是否进行了输入清洗和验证？
-
从外部API或库中获得的数据是否进行了相应的检查？
性能
-
这段代码修改是否会对系统性能产生负面影响？
-
是否可以进一步提升代码性能？
可读性
-
代码是否容易理解？
-
哪一部分使你困惑，为什么？
-
可以通过减小方法来提高代码可读性吗？
-
可以通过使用不同的函数/方法或变量名称来提升代码可读性吗？
-
代码是否存放在正确的文件/目录/包？
-
你是否认为方法应该重构以拥有更直观的控制流程？
-
数据流是否可理解？
-
是否有多余的注释？
-
某些注释是否可以更好的传达信息？
-
是否更多的注释会使你的代码更容易理解？
-
是否可以移除一些注释，通过提升代码可读性来理解代码？
-
是否存在注释掉的代码？
专家意见
-
你是否认为特定专家（如安全专家或可用性专家）应该先检查代码，然后再提交代码？
-
这个代码修改会影响其他团队吗？他们也应该发表意见吗？
好了，以上就是最为紧迫的一些问题列表。
代码风格和约定
您的团队或公司必须拥有清晰的编码风格指南，这一点很重要。因为这是在代码库中实施唯一性的唯一方法。并且一致性会使代码审查更快，使人们可以轻松地更改项目，并保持您代码的可读性和可维护性。
Google是做到这一点的很好的例子，无疑，这使Google可以进行快速的代码审查。
首先，我建议使用现成的编码样式来支持Google提供的多种语言。设定基本规则很重要，但要确保一劳永逸。不要持续争论。
尽可能自动化
确定了代码风格以后，请花一些时间正确安装和配置工具，以便一键格式化代码。
另外还有很多事情可以做。例如使用静态检查来代替部分人工审核。这是值得为之努力的。
完整问题列表
原文转自：https://www.michaelagreiler.com/code-review-checklist/
