代码审查清单

此清单主要针对审查者，因为它列出了审查补丁时需要检查的重要事项。

它对于补丁作者也很有用：如果更改符合这些指南，则更有可能获得审查批准。

Bug 状态和补丁文件

  • Bug 状态已分配，且指派人已正确设置。

  • 提交标题和消息遵循 约定。

  • 提交消息说明 更改内容以及更改原因。

  • 补丁可以应用到当前源代码的本地版本，无需合并。

  • 检查补丁引入的每个新文件是否都具有正确的 Mozilla 许可证标头：https://www.mozilla.org/en-US/MPL/headers/

手动测试

  • 验证

    • 如果这是一个新功能，则补丁已实现该功能。

    • 如果这是一个修复，则补丁已修复它所解决的 bug。

  • 在全局审查评论中报告您发现的任何问题。

  • 确定这些问题中的任何一个是否应该阻止更改的落地，或者是否可以作为后续的 bug 提交，以便稍后修复。

自动化测试

  • 运行新/修改后的测试，启用和禁用 e10s。

  • 注意通过但记录异常或在处理协议请求之前结束的测试。

  • 注意缓慢/长时间的测试：建议使用许多小的测试而不是单个长时间的测试。

  • 注意以集成测试而不是单元测试形式编写的新的测试：如果可能，单元测试应该是首选选项。

代码审查

  • 代码更改

    • 仅审查贡献者更改的内容。

    • 代码格式遵循 我们的 ESLint 规则 和 编码标准。

    • 代码已正确注释，JSDoc 已更新，所有新的“公共”方法都具有 JSDoc，请参阅 注释指南。

    • 如果添加/修改了 Promise 代码，则使用正确的 promise 语法并处理拒绝。请参阅 异步代码。

    • 如果添加/修改了 CSS 文件，则它遵循 CSS 指南。

    • 如果添加/修改了 React 或 Redux 模块，则它遵循 React/Redux 指南。

    • 如果添加/修改了应在 worker 中运行的 DevTools 服务器代码，则它不应使用服务

  • 测试更改

  • 用户界面更改

    • 如果添加/修改了任何用户界面，请在有可用的情况下，使用 UX 模型或规范仔细检查更改。如果有任何疑问，请向 UX 设计师询问信息。

    • 如果添加了用户界面字符串，则已将其本地化并遵循 本地化指南。

    • 如果用户界面字符串的含义已更改，密钥已更新。

    • 如果添加了新图像，则它是一个 SVG 图像，或者有理由不使用 SVG。

    • 如果添加/修改了 SVG，则它遵循 SVG 指南。

    • 如果修改了已记录的功能，则 bug 上存在关键字 dev-doc-needed。

完成审查

  • R+：代码应尽快落地。

  • R+ 附带评论：有一些评论，但它们都很小，或者在解决后不需要重新审查，请信任作者。

  • R 取消 / R- / F+：代码存在问题，需要重新审查。