用户编码规范 ​

基础交互规则 ​

  1. 请始终使用中文进行沟通。
  2. 如果回答的是代码，请给每个关键节点，比较难懂的代码增加中文注释
  3. 当生成的代码行数超过 20 行时，请考虑聚合代码以及考虑其颗粒度是否适合
  4. 任何时候不要直接修改代码，而是先给出解决方案，当接收到 “请帮我修改” 指令时，再根据解决方案进行修改

git 提交规则 ​

当任务完成时，始终输出一份 git 提交记录，记录任务实现的功能：

  1. 提交记录遵循如下提交规范

    Git message 格式规范

    type(scope) : subject

    ( 1 ) type（必须） : commit 的类别，只允许使用下面几个标识：

    • feat : 新功能
    • fix : 修复bug
    • docs : 文档改变
    • style : 代码格式改变
    • refactor : 某个已有功能重构
    • perf : 性能优化
    • test : 增加测试
    • build : 改变了build工具 如 grunt换成了 npm
    • revert : 撤销上一次的 commit
    • chore : 构建过程或辅助工具的变动

    ( 2 ) scope（可选） : 用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

    ( 3 ) subject（必须） : commit 的简短描述，不超过50个字符。

  2. 提交记录中包含任务描述和实现的功能

  3. git commit message 始终使用英文书写，保持简洁

TypeScript 编码规范 ​

  1. 所有 TypeScript 代码必须符合 TypeScript 编码规范
  2. 所有 TypeScript 代码必须包含类型注释，包括函数参数、返回值、类字段等
  3. 所有 TypeScript 代码必须使用 const 或 let 声明变量，避免使用 var
  4. 所有 TypeScript 代码必须使用 interface 或 type 定义类型，避免使用 any
  5. 善于利用工具
    • 始终使用 lodash-es 来处理数组、对象等数据结构
    • 始终使用 dayjs 来处理日期时间
  6. 所有定时器必须在组件卸载时清除，避免内存泄漏

css 编码规范 ​

  1. 所有 css 代码必须符合 css 编码规范
  2. 所有 css 代码必须使用类选择器，避免使用 id 选择器
  3. 所有 css 代码必须使用 flex 布局，避免使用 float 布局
  4. 所有 css 代码必须使用 rem 单位，避免使用 px 单位
  5. 类名必须遵守 bem 命名规范，例如：.block__element--modifier
  6. 优先使用 css 变量来定义颜色、字体大小等全局样式
  7. 禁止使用行内样式

vue3 编码规范 ​

  1. 所有 vue3 代码必须符合 vue3 编码规范
  2. 所有 vue3 代码必须使用组合式 api，避免使用选项式 api
  3. 所有 vue3 代码必须使用单文件组件，避免使用 jsx 或 tsx
  4. 所有 vue3 代码必须使用类型注释，包括组件选项、组件 props、组件事件等
  5. 所有 vue3 代码必须使用 const 或 let 声明变量，避免使用 var
  6. 所有 模板的 refs 引用必须在组件卸载时清除，避免内存泄漏

代码质量与重构规范 ​

通用编码规范 ​

  1. 避免不必要的对象复制或克隆
  2. 避免多层嵌套，提前返回
  3. 使用适当的并发控制机制

代码坏味道识别与处理 ​

基于 Martin Fowler《重构》一书的核心观点，以下是应当注意的代码坏味道及其处理方法：

1. 神秘命名 ​

  • 问题：变量、函数、类或模块的名称不能清晰表达其用途和含义
  • 处理：重命名为具有描述性的名称，使代码自解释
  • 示例：将p = () => {}改为const calculatePrice = () => {}

2. 重复代码 ​

  • 问题：相同或相似的代码出现在多个地方
  • 处理：提取为函数、类或模块；应用模板方法模式
  • 示例：将重复的验证逻辑提取为共享函数

3. 过长函数 ​

  • 问题：函数过长，难以理解和维护
  • 处理：提取函数，将大函数分解为多个小函数
  • 示例：将 200 行的处理函数分解为多个职责单一的小函数

4. 过大的类/结构体 ​

  • 问题：类或结构体承担了过多责任，字段和方法过多
  • 处理：提取类，将相关字段和方法组合成新的类
  • 示例：将 User 类中的地址相关字段提取为 Address 类

5. 过长参数列表 ​

  • 问题：函数参数过多，难以理解和使用
  • 处理：引入参数对象，将相关参数组合成对象
  • 示例：将fn create_user(name, email, phone, address, city, country)改为fn create_user(user_info: UserInfo)

6. 发散式变化 ​

  • 问题：一个类因为多种原因而被修改
  • 处理：按照变化原因拆分类
  • 示例：将既处理数据库又处理业务逻辑的类拆分为两个类

7. 霰弹式修改 ​

  • 问题：一次修改需要改动多个类
  • 处理：将相关功能移到同一个类中
  • 示例：将分散在多个类中的订单处理逻辑合并到一个 OrderProcessor 类

8. 依恋情结 ​

  • 问题：一个函数对其他类的兴趣超过自己所在的类
  • 处理：移动函数或提取函数
  • 示例：将过度使用另一个类数据的方法移动到那个类中

9. 数据泥团 ​

  • 问题：相同的数据项总是一起出现
  • 处理：提取为对象
  • 示例：将经常一起出现的起始日期和结束日期提取为 DateRange 类

10. 基本类型偏执 ​

  • 问题：使用基本类型表示有特定含义的数据
  • 处理：使用小对象替代基本类型
  • 示例：用 PhoneNumber 类替代表示电话的字符串

重构过程原则 ​

1. 小步重构 ​

  • 每次只做一个小改动，然后测试
  • 频繁提交，保持代码随时可工作

2. 测试保障 ​

  • 重构前确保有足够的测试覆盖
  • 每次修改后运行测试确保行为不变

3. 代码审查 ​

  • 重构后进行代码审查，确保质量
  • 分享重构经验，提高团队能力

代码可读性优化 ​

1. 命名约定 ​

  • 使用有意义的、描述性的名称
  • 遵循项目或语言的命名规范
  • 避免缩写和单字母变量（除非是约定俗成的，如循环中的 i）

2. 代码组织 ​

  • 相关代码应该放在一起
  • 函数应该只做一件事
  • 保持适当的抽象层次

3. 注释与文档 ​

  • 注释应该解释为什么，而不是做什么
  • 为公共 API 提供清晰的文档
  • 更新注释以反映代码变化

性能相关重构 ​

1. 内存优化 ​

  • 避免不必要的对象创建
  • 及时释放不再需要的资源
  • 注意内存泄漏问题

2. 计算优化 ​

  • 避免重复计算
  • 使用适当的数据结构和算法
  • 延迟计算直到必要时

3. 并行优化 ​

  • 识别可并行化的任务
  • 避免不必要的同步
  • 注意线程安全问题
> cd ..

CC BY-NC-SA 4.0 乙巳 © 闻 · 斋