鸿蒙 App 开发不再踩坑：编码规范 + TDD + Code Review 全指南

网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
大家好，我是展菲！
全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

摘要

在鸿蒙 App 的开发过程中，如果没有规范的流程和机制，很容易因为代码质量问题导致频繁 Bug、返工严重，进而拖慢项目进度、影响用户体验。本文从编码规范、测试驱动开发（TDD）、代码审查三方面出发，结合实际案例与 HarmonyOS 平台，介绍一套系统性的提质降 Bug 的开发方案，帮助开发者更高效、更安全地交付代码。

引言

写代码的时候，“写得快”不代表“写得对”。很多项目上线后频繁出现崩溃、逻辑错误，大多都可以追溯到开发阶段缺乏规范与机制，尤其在像鸿蒙这样多设备协同、状态切换复杂的平台上更是如此。

本文将结合实际经验聊聊怎么从开发阶段就“避坑”，构建高质量的鸿蒙 App。

为什么规范能减少 Bug？

代码规范不是束缚，而是统一语言。鸿蒙的开发语言是 ArkTS/Java，语法上和前端类似，但组件交互、生命周期管理却有鸿蒙自己的方式。如果团队每个人写法不一致，后续维护极其痛苦，Bug 频率只会更高。

推荐做法

• 使用 lint 工具（如 ArkTS lint、ESLint for JavaScript 部分）

• 统一命名方式，例如组件以 xxxComponent, 页面以 xxxPage 结尾

• 生命周期内代码顺序统一（onInit → build → onDestroy）

• 避免匿名函数嵌套过深，逻辑拆分为子函数

代码示例

@Entry
@Component
struct LoginPage {
  @State username: string = '';
  @State password: string = '';

  build() {
    Column() {
      TextInput({ placeholder: '请输入用户名' })
        .onChange(value => this.username = value)
      
      TextInput({ placeholder: '请输入密码', type: InputType.Password })
        .onChange(value => this.password = value)

      Button('登录')
        .onClick(() => this.handleLogin())
    }
  }

  handleLogin() {
    if (!this.username || !this.password) {
      prompt.showToast({ message: '用户名或密码不能为空' });
      return;
    }
    // 登录逻辑处理...
  }
}

模块讲解：

模块	功能	说明
@Entry	标记为应用入口	鸿蒙应用启动时将默认加载该组件
@Component	定义 UI 组件	类似 React 的组件类
@State	定义响应式状态	状态变化后 UI 会自动更新
Column()	垂直布局容器	包裹多个 UI 元素
TextInput	输入框组件	用于输入用户名和密码
Button('登录')	登录按钮	点击时触发 handleLogin() 方法
prompt.showToast()	弹出消息提示	用于错误提示或反馈信息

实际开发应用点：

• 状态隔离清晰：所有状态集中在组件内的 @State 中，便于调试和测试。
• 结构清晰：UI 结构和业务逻辑分离，build() 管 UI，handleLogin() 管行为。
• 错误提示即时：通过 prompt 进行反馈，可以统一处理错误交互。

当然可以。我们来详细拆解文章中的两个关键示例代码模块：

TDD 测试用例示例（以登录验证为例）

什么是测试驱动开发？

TDD（Test Driven Development）强调先写测试再写实现。虽然前期投入略多，但长期来看能大大减少 Bug，因为每次改动都有用例做“安全网”。

鸿蒙中的实践方式

虽然目前鸿蒙官方对单元测试支持还不算成熟，但我们可以用类似 JUnit/TestNG 风格的工具 + 模块化拆分，逐步构建测试能力。

示例：对登录逻辑进行单元测试

function validateLogin(username: string, password: string): boolean {
  return !!username && !!password;
}

// 假设我们用 jest 进行测试
test('空用户名应返回 false', () => {
  expect(validateLogin('', '123456')).toBe(false);
});

test('空密码应返回 false', () => {
  expect(validateLogin('admin', '')).toBe(false);
});

test('正确用户名密码应返回 true', () => {
  expect(validateLogin('admin', '123456')).toBe(true);
});

模块讲解：

模块	功能	说明
validateLogin()	登录验证函数	判断用户名与密码是否为空
test()	单元测试函数	描述每个场景的预期行为
expect().toBe()	断言语句	验证实际结果是否等于预期值

实际开发应用点：

• 抽离逻辑：将业务逻辑（验证）独立为函数，便于测试和复用。
• 覆盖关键路径：包括正常登录、用户名为空、密码为空三个核心用例。
• 可持续演进：后续只要登录逻辑变化（如加入邮箱验证），更新测试即可验证是否破坏原逻辑。

延伸建议

如果你用 DevEco Studio 进行 ArkTS 开发，虽然目前还没有像 Jest 这样的单元测试插件，但你可以通过以下方式测试逻辑代码：

• 将验证函数放入独立模块（如 LoginUtils.ets）
• 使用 Node.js + ts-jest 在本地编写测试脚本
• 后续结合 UI 测试框架（如 HarmonyOS 模拟器场景测试）

为什么必须做 Code Review？

一个人容易疏忽，三人审核互相拦 Bug。尤其是鸿蒙这种组件层层嵌套的架构，一不小心状态同步就出错，提前有人看一眼，是最便宜的 QA。

实践建议

• 用 DevEco Studio 的 Git 进行代码 Review 前检查

• 每次提交前都用 “MR 模板”标明改动点、影响模块

• 用统一规范的 Commit Message（如 feat: 添加登录功能）

QA环节

问：鸿蒙 UI 的状态管理容易乱，有啥建议？

答：使用 @State、@Prop 的状态流转，不要在组件 build 内部直接 set 数据，逻辑写在方法中。

问：鸿蒙怎么做自动化测试？

答：ArkTS 生态还在发展，可以先用业务逻辑抽离 + Node.js 做逻辑测试，或使用 DevEco Studio 的模拟器场景。

总结

代码质量不是靠上线后测试，而是靠开发中设计。通过写规范、先写测试、互相审核，我们能在鸿蒙这样的新平台上写出可维护、低 Bug 的系统。

未来展望

随着 HarmonyOS 在车载、智能家居、工业设备等场景的推进，复杂状态协同将成为常态。这也倒逼我们在开发阶段“码字更小心、规范更严格”。建议团队未来从 DevOps 一体化入手，逐步建立全链路的质量保障体系。