代码作者应该关注的列表

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

  • 代码编译成功并且通过静态检查（没有警告）
  • 代码通过所有的测试（单元测试、集成测试和系统测试）
  • 你已经仔细检查了拼写错误，并做了处理（注释、todo等）
  • 概述代码修改的原因以及修改了哪些地方

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

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

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

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

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

实现

  • 此代码更改会执行它应该做的事情吗？
  • 这种解决方法是最简单的吗？
  • 这个更改有引入一些不需要的编译时或运行时的依赖吗？
  • 是否使用了不应该使用的框架、API、库、服务？
  • 是否存在可以提升解决方法的未使用的框架、API、库、服务？
  • 代码是否处于正确的抽象级别？
  • 代码的模块化是否做的足够好？
  • 你是否有其他的解决方案，该方案在代码可维护性、可读性、性能、安全方面表现更好？
  • 是否已经存在类似功能的函数？如果有，为什么不复用？
  • 是否有最佳实践、设计模式或特定语言模式可以优化代码？
  • 代码是否遵循面向对象的分析和设计原则，例如单一职责原则，开闭原则，里氏替换原则，接口隔离，依赖注入？

逻辑错误或Bug

  • 你能想到代码不按预期运行的任何用例吗？
  • 你能想到任何可能破坏代码的输入或外部事件吗？

错误处理和日志

  • 错误都被正确处理了吗？
  • 是否有需要增加或删除的日志/debug信息？
  • 错误消息对用户是否友好？
  • 是否有足够的日志，它们的编写方式是否是易于调试的？

可用性和可访问性

  • 从可用性角度触发，所提出的解决方案是否设计合理？
  • API文档是否足够好？
  • 提出的解决方案是否具备可访问性？
  • API/UI是否直观易用？
  • 测试与可测试性
  • 代码是否达到可测试标准？
  • 是否有足够的自动化测试（单元测试/集成测试/系统测试）？
  • 现有测试是否合理覆盖代码变更？
  • 是否有额外的测试用例、输入或边界用例以供测试？

依赖

  • 如果这个修改需要更新代码以外的文件，例如更新文档，配置，README文件。是否完成了这些更新？
  • 这个修改是否会对系统其他地方造成影响？是否能向后兼容？

安全和隐私数据

  • 这段代码是否打开软件的安全漏洞？
  • 权限和身份验证是否被正确处理？
  • 是否安全处理了敏感数据，例如用户数据、信用卡信息等？是否正确使用加密方法？
  • 代码更改是否显露了一些私密信息（如迷药、用户名等）？
  • 代码处理用户输入时，是否解决了跨站点脚本，SQL注入等安全漏洞，是否进行了输入清洗和验证？
  • 从外部API或库中获得的数据是否进行了相应的检查？

性能

  • 这段代码修改是否会对系统性能产生负面影响？
  • 是否可以进一步提升代码性能？

可读性

  • 代码是否容易理解？
  • 哪一部分使你困惑，为什么？
  • 可以通过减小方法来提高代码可读性吗？
  • 可以通过使用不同的函数/方法或变量名称来提升代码可读性吗？
  • 代码是否存放在正确的文件/目录/包？
  • 你是否认为方法应该重构以拥有更直观的控制流程？
  • 数据流是否可理解？
  • 是否有多余的注释？
  • 某些注释是否可以更好的传达信息？
  • 是否可以补充更多的注释使你的代码更容易理解？
  • 是否可以移出一些注释，通过提升代码可读性来理解代码？
  • 是否存在注释掉的代码？

专家意见

  • 你是否认为特定专家（如安全专家或可用性专家）应该先检查代码，然后再提交代码？
  • 这个代码修改会影响其他团队吗？他们也应该发表意见吗？

代码风格和约定

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

尽可能自动化

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

另外还有很多事情可以做。例如使用静态检查来代替部分人工审核。