移动开发代码规范：让团队协作更高效

在开发一个电商类 App 时，小李负责商品详情页，小王负责购物车模块。两人用的都是 React Native，但打开代码一看，风格完全不同：小李的变量名全是英文缩写，比如 prodInfo、skuList，而小王偏爱中文拼音，写着 shangPinId、gouWuChe。等要联调接口时，光是理解对方的代码就花了大半天。

命名规范不是小事

变量、函数、类的命名直接影响代码可读性。统一使用驼峰命名法，比如 getUserInfo，避免下划线或拼音混用。组件命名采用帕斯卡命名法，如 ProductCard，这样在 JSX 中一眼就能识别是自定义组件。

文件结构要有套路

一个典型的移动端项目可以按功能划分目录：

src/
  ├── components/
  │   ├── Header
  │   │   ├── index.tsx
  │   │   ├── styles.ts
  │   │   └── types.ts
  ├── screens/
  │   ├── ProductDetail/
  │   ├── ShoppingCart/
  ├── utils/
  └── constants/

每个页面或组件独立成文件夹，包含自己的逻辑、样式和类型定义，别人接手时能快速定位。

别让注释变成负担

不是每行代码都要写注释。重点是解释“为什么”，而不是“做什么”。比如网络请求失败后重试三次，可以在代码旁加一句：

// 超时或弱网环境下易失败，重试机制提升成功率
await retry(fetchOrderData, 3);

这种说明比写“调用重试函数”有用得多。

ESLint + Prettier 是标配

手动检查格式太累人。在项目中集成 ESLint 统一代码检测规则，Prettier 自动格式化。提交代码前自动跑一遍 lint，能避免很多低级错误。配置文件放在仓库根目录，新成员 clone 下来也能保持一致风格。

异步处理要克制

移动端常涉及网络请求、本地存储操作。不要到处写 async/await，封装成工具函数更省心。例如：

const api = {
  get: async (url) => {
    const res = await fetch(url);
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return res.json();
  }
};

后续调用时只需 api.get('/products')，不用重复处理异常和解析流程。

状态管理别滥用

有些开发者一上来就引入 Redux 或 MobX，结果小项目变得臃肿。优先用组件自带的状态（useState）或上下文（Context），真正跨层级、多模块共享的数据再考虑全局状态管理。不然调试起来就像在迷宫里找路。

提交信息也要讲规矩

Git 提交记录是项目的历史书。用清晰的动词开头，比如 fix: 修复登录页键盘遮挡输入框、feat: 添加商品收藏功能。时间久了回头看，哪次改了什么一目了然。

团队里推行代码规范，一开始可能觉得麻烦，但只要坚持两周，就会发现代码审查变快了，新人上手也轻松。好的规范不是束缚，而是让每个人都能专注解决问题本身。