Quartz 4

coding-standards

5 min read

研发流程与编码规范

🎯 核心目标: 提升代码质量，减少重复劳动，保障系统稳定性。

🛠️ 关于开发流程

一个高效、靠谱的开发流程应严格遵守以下准则：

✅ 开发前/中

  • 必须写单元测试: 核心逻辑必须有 UT 覆盖，确保改动不破坏原有逻辑。
  • 代码自查: 不断地、重复地看自己的代码，在 Commmit 前自我 Code Review。
  • 明确改动范围: 开发人员需列出改动了哪些已有接口，评估影响面。
  • 开发联调: 必须主动推进前后端及上下游的开发联调。
  • 按时提测: 尽最大努力保证开发提测不 Delay，有风险提前暴露。

🔍 测试阶段

  • 关注日志: 测试人员在测试阶段应辅助查看后端日志，便于快速定位问题。

💻 编码规范 (Coding Standards)

💾 数据库与性能 (Database & Performance)

  1. 拒绝重复查询

    • ❌ 禁止在整个调用链路中重复查询相同的 DB 数据。
    • ✅ 建议获取过的对象在上下文传递，或使用内存缓存。

  2. 按需查询

    • ❌ 禁止无脑全量查询字段 (SELECT *)。
    • ✅ 建议根据业务需求只查询必要字段 (尤其是有大字段时)。

  3. 循环操作

    • ❌ 禁止在循环 (foreach/for) 中操作 Redis 或 DB。
    • ✅ 建议使用批量方法 (BatchGet, BulkInsert)。

  4. 索引命中

    • ⚠️ 注意查询索引命中问题，避免全表扫描。
    • ⚠️ 注意 LIST 转 Dic 时 Key 重复导致的异常。

  5. 事务控制

    • ✅ 建议事务范围越小越好。
    • ✅ 建议将纯查询类的操作移出 Using Transaction / Lock 之外，尽早释放数据库资源。

  6. 发号器优化

    • ✅ 建议发号器放到 Using 外部使用，减少数据库事件占用时间。

🚀 缓存策略 (Caching)

  1. 配置缓存

    • ✅ 建议品牌配置类型的数据必须缓存 (不易变)。
    • ✅ 建议不要缓存多余字段，节省 Redis 内存。

  2. 分页缓存

    • ✅ 建议按筛选条件与分页进行缓存。
    • ❌ 不推荐一次性取出所有数据（除非数据量极小且常访）。

  3. Key 命名

    • ✅ 规范 Key 要简洁明了，不要太长。
    • ✅ 建议统一分层项目管理 Key 前缀。

  4. 穿透防护

    • ⚠️ 注意缓存穿透风险。
    • ✅ 建议查询不到数据时，设置空值缓存 (Null Object Pattern)。

🏗️ 代码质量与架构

  1. 服务化调用

    • ✅ 建议调用封装好的服务化方法，而非直接写 SQL 或散落的逻辑。

  2. 异常处理

    • ❌ 禁止 Catch 掉异常后不做任何日志输出 (吃掉异常)。
    • ✅ 建议异常必须记录日志（包含堆栈信息）。

  3. 日志规范

    • ❌ 禁止过多写入调试日志 (Debug Log)。
    • ✅ 建议生产环境只打印关键路径和错误日志。

  4. 异步编程

    • ⚠️ 注意多线程 Task、async/await 的死锁与上下文丢失问题。
    • ❌ 禁止业务代码中使用 where(true) 导致死循环风险。

  5. 数据类型

    • ✅ 建议固定值转为枚举类型 (Enum)，通过枚举维护更容易。
    • ⚠️ 注意 LINQ 函数使用问题 (如 First 若无数据会报错，建议 FirstOrDefault)。

📌 典型坏味道 (Bad Smell)

🚫 Case 1: 重复查库 有主键 ID 的情况下，不要先根据 BrandId 查列表再取第一条，直接 Find(Id)。

🚫 Case 2: 循环查库

foreach(var item in list) {
    var user = _repo.GetUser(item.UserId); // ❌ 禁止
}
// ✅ 应该先 GetUsers(ids) 批量查出放入 Dictionary

Graph View