HarmonyOS鸿蒙Next中在团队里是怎么做代码 Review 的？有专属 Checklist 吗？

在HarmonyOS Next开发中，代码Review是保障质量的关键环节。虽然没有一个官方发布的、放之四海皆准的“专属Checklist”，但成熟的团队通常会根据HarmonyOS Next的技术特性和最佳实践，建立自己的审查清单。以下是一个典型的团队Review Checklist核心要点，涵盖了您提到的方面：

一、ArkTS语言与声明式UI规范

1. 状态管理：
   • @State：检查是否仅用于组件内部的状态，作用域是否最小化。避免滥用导致不必要的UI刷新。
   • @Prop、@Link、@ObjectLink、@Provide/@Consume：检查使用场景是否准确，父子组件或跨组件数据流是否清晰、高效。
   • @StorageLink、@StorageProp：检查持久化状态的使用是否必要，数据量是否可控。
2. 组件与装饰器：检查@Builder、@BuilderParam、自定义组件的复用性。@Styles和@Extend的使用是否符合样式复用规范。
3. 渲染控制：检查if/else、ForEach的使用是否高效，键值生成是否稳定唯一，避免列表渲染性能问题。

二、Ability与生命周期

1. Ability生命周期：检查onCreate、onWindowStageCreate、onForeground、onBackground、onDestroy等回调中，资源申请与释放是否成对、及时。避免内存泄漏。
2. UIAbility与界面：检查UIAbility与WindowStage、Window的关联管理是否规范。页面路由(router)跳转参数传递是否安全。
3. ExtensionAbility：检查特定场景Ability（如FormExtensionAbility、ServiceExtensionAbility）的使用是否符合其设计目的，后台任务管理是否合理。

三、工程与架构

1. 模块化与依赖：检查oh-package.json中模块依赖是否清晰，Har/HSP动态共享包的划分是否合理。
2. 资源管理：检查字符串、颜色、尺寸等是否定义在资源文件中，支持多设备适配。媒体资源是否经过优化。
3. 权限与隐私：检查敏感权限（如位置、相机）的申请是否必要，声明是否准确，用户隐私数据（如设备ID）的处理是否符合规范。

四、性能与安全

1. 性能：检查是否有耗时操作阻塞主线程，是否合理使用异步任务（TaskPool、Worker）。列表滚动、动画是否流畅。
2. 安全：检查输入验证、数据存储（Preferences、数据库）是否安全，日志中是否避免输出敏感信息。

五、基础质量

1. 代码风格：遵循ArkTS官方风格指南，保持命名、格式统一。
2. 注释与文档：关键逻辑、复杂算法应有清晰注释。公共API需有文档说明。
3. 单元测试：新增或修改的逻辑是否配有相应的单元测试用例。

团队实践建议：

• 流程化：将Review作为提交流程的强制环节，利用Git平台（如Gitee、GitLab）的Merge Request/Pull Request功能。
• 工具辅助：结合静态代码分析工具（如ArkTS Lint）进行自动化检查，减少人工审查低级错误。
• 聚焦重点：Review应重点关注设计合理性、架构清晰度、性能与安全，而非仅仅代码风格。
• 知识共享：通过Review沉淀常见问题案例，形成团队知识库，持续优化Checklist。

总之，一个有效的Checklist应源自团队在HarmonyOS Next项目中的实际经验积累，并随着版本迭代和技术演进不断更新。核心目标是确保代码符合框架设计哲学，实现高性能、高可靠的应用。