前言
软件系统的代码工程质量和很多方面因素相关，比如代码的可读性、可维护性、性能等等，需要我们综合考虑。

虽然有强大的 Rust 编译器可以在编译期保证 Rust 代码的内存安全，但其实它也是有限制的。前提是你禁止了 Unsafe  Code 完全编写 Safe Rust 代码。哪怕只用 Safe Rust，在并发场景下，也会有死锁、lockfree内存顺序指定不当而导致的数据竞争风险。即便内存安全保证了，整个系统还可能有信息安全（Security）风险。

如果仅仅依靠 Rust 编译器、rustfmt、clippy等工具还并不足够能保证最好的工程质量。所以，实际开发中，要保证整个系统代码的工程质量，必须有一套代码审查标准。最好是有一套代码审查的 Checklist 供审查者高效审阅代码，甚至为未来的 AI 审查代码建立一个标准。

Rust 代码审查表：
正确性（Correctness）
.检查代码可以编译通过，没有警告。修复或文档化任何警告。
.检查业务逻辑,确认没有错误或边界情况被遗漏。
.验证错误处理是合适的。
.确认 Unsafe 代码是正确的，并配备规范的文档。进一步参考安全性。
可读性（Readability）
.确保代码易于阅读和理解。
.检查命名是否清晰、描述性强，检查风格和格式是否一致、符合习惯。
.验证注释解释了意图和复杂的部分。
.确认代码是合理地组织到函数和模块中的。
可维护性（Maintainability）
.检查重复逻辑,考虑合并。
.指出哪些部分可以抽象成通用、可重用的部分。
.查找抽象不当或过于复杂的情况。
.确保测试覆盖关键路径和边界情况。
.验证文档注释解释了实现细节。
.检查代码组织结构是否合理，是否符合单一指责和开闭原则等
.检查代码架构耦合性
安全性（Unsafe Safety && Security）
.Unsafe 代码的安全抽象是否规范合理，尤其是 FFI 边界。
.识别潜在的缓冲区溢出、SQL注入等漏洞。
.建议输入验证和过滤方法。
.查找并发场景的静态条件和同步不当的情况，以及Unsafe 代码或 lockfree 场景下内存顺序指定不当而造成的数据竞争风险。
.确保适当的认证和授权。
.确保供应链安全，确保使用的外部库是可靠和安全的，避免使用已经被废弃或长时间没有更新的库。
性能（Performance）
.查找明显的低效情况,如不必要的内存分配。
.如果适用,建议更优的数据结构或算法。
.指出哪些地方可以通过延迟计算、异步或并行来优化。
.确保在性能优化之前有充分的性能基准测试文档以防止性能回退
接口设计（API Design）
.考虑API的一致性、直观性,和潜在的可用性问题。
.建议改进 API 命名、接口和文档。
.指出 API 行为不明确或缺失的部分。
.识别 Unsafe 代码暴露的隐患。
可调试性（Debuggability）
.日志记录：代码中是否有足够的日志记录，特别是在关键路径和可能的错误点。日志应该是清晰的、有意义的，并且可以帮助开发者快速定位问题。
.错误消息：错误消息是否清晰、具体，并提供了足够的上下文信息来帮助定位问题。
.断言和验证：在关键点使用断言来验证假设，确保代码的行为是预期的。
.文档和注释：确保复杂的代码段有足够的注释和文档，以帮助其他开发者理解其工作原理。
可观测性（Observability）
.监控和指标：代码是否集成了监控工具，是否有足够的指标来监控系统的健康状况和性能。
.追踪：如果应用是分布式的，是否集成了分布式追踪工具，如 OpenTelemetry ，以帮助跟踪请求在系统中的流转。
.告警：是否设置了合适的告警阈值和通知机制，以便在出现问题时及时通知相关人员。
.健康检查：对于服务和应用，是否有健康检查端点，以便监控工具和负载均衡器可以检查其健康状况。
.其他
.如果代码需要在多个平台上运行，确保考虑到跨平台的兼容性问题。

.确保代码可以在 CI/CD 环境中正常编译和测试。

后续工作
目前这份 Rust 代码审查指南只是一个初稿，为了完善它，需要大家一起参与。后续我们需要为审查的每一个维度建立更加细致的标准和评分体系，以及相应的代码示例，一切以 Rust 开源生态中的项目为主。这就需要大家的共同参与了。