增加修改和删除功能
This commit is contained in:
@@ -78,153 +78,3 @@ alwaysApply: true
|
||||
42. 关键业务操作必须记录操作日志
|
||||
43. 异常信息要包含足够的上下文信息
|
||||
44. 生产环境禁止输出debug级别日志
|
||||
|
||||
---
|
||||
|
||||
## Java Spring Boot 项目开发与代码质量保障规范（扩展）
|
||||
|
||||
适用范围：本规范适用于 logistics-finance 项目所有后端模块（common、gateway、auth、user、order、waybill、vehicle、finance、report、ai、file）。若与本文件前文条款或现有项目规范冲突，以更严格者为准。
|
||||
|
||||
### 一、代码规范完善
|
||||
|
||||
- 编码标准
|
||||
- 严格开启编译参数校验与空指针警告，禁止忽略 IDE/编译器提示。
|
||||
- 代码提交前必须通过本地编译、单元测试、静态扫描（如存在）。
|
||||
- 严禁出现魔法值：使用常量或配置项；跨模块常量放在 common 模块统一管理。
|
||||
- 日志分级：业务关键信息用 info，调试用 debug（生产禁用），异常用 error，禁止打印敏感信息（密码、密钥、Token、手机号等）。
|
||||
|
||||
- 命名规范
|
||||
- 类：PascalCase；方法/变量：camelCase；常量：UPPER_SNAKE_CASE；包名全小写。
|
||||
- 接口路径参照现有规则（禁止 /api 前缀、禁止 PathVariable、Mapping value 必须显式且驼峰命名）。
|
||||
|
||||
- 注释规范
|
||||
- 类注释需包含：职责/用途、作者、创建时间、版本；方法注释需包含：用途、参数、返回、可能抛出的异常。
|
||||
- 复杂算法/易错逻辑必须添加行内注释；废弃方法使用 @Deprecated 并标注替代方案与移除计划。
|
||||
|
||||
- 代码结构规范（建议包结构）
|
||||
- controller、service、service.impl、repository（mapper/dao）、domain/entity、converter、config、client（feign）、event、facade、task、util、constant。
|
||||
- DTO/Request/Response 与 Entity 分离；Controller 不做对象互转，统一在 Service/Converter 层完成。
|
||||
|
||||
### 二、分层架构规范
|
||||
|
||||
- Controller 层职责
|
||||
- 接收请求、参数校验（Jakarta Validation）、鉴权校验（由网关/拦截器）、调用 Service，统一使用 `Result<T>` 返回。
|
||||
- 禁止：业务逻辑、事务控制、数据访问、实体与请求/响应的相互转换。
|
||||
|
||||
- Service 层职责
|
||||
- 聚合业务逻辑、领域编排、事务边界控制（@Transactional，读写分离时仅在写方法上标注），幂等与重试策略在此实现。
|
||||
- 方法命名与 Controller 对应，入参使用 Request 对象，出参使用 Response 对象。
|
||||
|
||||
- Repository 层职责
|
||||
- 仅做数据访问，统一使用 MyBatis-Plus（优先 LambdaQueryWrapper，避免硬编码字段）。
|
||||
|
||||
- Entity 规范
|
||||
- 统一继承 BaseEntity，字段包含：created_by、create_time、updated_by、update_time、logical_delete、remark（与项目约定一致）。
|
||||
- 禁止使用枚举作为实体/DTO 字段类型；以 String/Integer 存储并在注释中补充取值说明。
|
||||
|
||||
### 三、统一异常与返回结果
|
||||
|
||||
- 全局异常处理
|
||||
- 继续使用 common-web 的 GlobalExceptionHandler；禁止在业务代码中大面积 try-catch，异常由全局处理。
|
||||
- 业务异常一律抛出 BusinessException；校验异常统一转为 400 语义返回。
|
||||
|
||||
- 统一返回结构
|
||||
- 统一使用 common-core 的 Result<T> 与 ResultCode；保证 traceId、timestamp 一致性。
|
||||
- Controller 层仅返回 Result，不直接返回实体或集合。
|
||||
|
||||
- 参数校验
|
||||
- 使用 jakarta.validation 注解（@NotNull、@Size 等），在 Request 对象上标注；Controller 使用 @Validated。
|
||||
|
||||
### 四、数据库操作规范
|
||||
|
||||
- 设计规范
|
||||
- 数据表必须包含 create_time、update_time；删除优先逻辑删除 logical_delete；字段命名下划线风格。
|
||||
- 建议仅创建必要索引；避免外键约束（由应用层保证一致性）。
|
||||
|
||||
- 查询构建
|
||||
- 优先使用 LambdaQueryWrapper 和链式调用；分页查询必须使用分页插件；大数据量必须分页。
|
||||
- 避免 N+1 查询；需要时使用批量查询或联表映射。
|
||||
|
||||
- 事务管理
|
||||
- 仅在 Service 层声明事务；方法内仅包含数据库操作或与数据库一致性相关的远程调用；跨服务一致性使用可靠消息/补偿方案。
|
||||
|
||||
---
|
||||
|
||||
## 二、代码质量保障机制
|
||||
|
||||
- 代码审查流程（Code Review）
|
||||
- 所有变更必须走 PR；至少 1 名同组开发+1 名模块 Owner 审核通过方可合并。
|
||||
- 审查清单：命名/注释/分层边界/异常处理/日志/性能/安全/接口兼容性/测试覆盖率/静态扫描告警。
|
||||
- PR 模板需包含：改动描述、影响面、回归范围、测试说明、回滚方案。
|
||||
|
||||
- 静态代码分析与格式
|
||||
- 集成 Checkstyle（代码风格）、SpotBugs/PMD（潜在缺陷）、SonarQube（质量门禁），EditorConfig/格式化工具保持一致风格。
|
||||
- 质量门禁建议：
|
||||
- 新增代码覆盖率 >= 80%，全局覆盖率 >= 70%；
|
||||
- Blocker/Critical 问题为 0；
|
||||
- 重复代码率 < 3%；
|
||||
- 圈复杂度阈值：方法 < 10，类 < 80。
|
||||
|
||||
- 测试规范
|
||||
- 单元测试：命名 {ClassName}Test，方法名 should_xxx_when_xxx；使用 Mockito/AssertJ；隔离外部依赖。
|
||||
- 集成测试：使用 @SpringBootTest，测试容器或嵌入式组件替代真实依赖；构造典型场景与边界场景。
|
||||
- 覆盖率准则：核心业务与关键分支必须覆盖（正常/异常/边界/空数据）。
|
||||
- 用例分层：Service 层单测覆盖业务规则；Controller 层使用 MockMvc；Repository 层覆盖复杂 SQL 与多条件查询。
|
||||
|
||||
- 重构指导原则
|
||||
- 小步快跑、单一职责、先加测试再重构；保持对外行为一致（新增特性使用特性开关/版本控制）。
|
||||
- 严禁大规模跨模块重构合并在单次 PR；拆分为多个可审查的独立提交。
|
||||
|
||||
---
|
||||
|
||||
## 三、变更管理流程
|
||||
|
||||
- 变更前影响分析
|
||||
- 维度：接口兼容性（路径/入参/语义）、数据库（表/字段/索引/数据迁移）、配置（Nacos/环境变量）、依赖版本、性能、容量与并发、安全与合规、可回滚性。
|
||||
- 产出：影响分析文档与回滚方案（包含回滚脚本/开关）。
|
||||
|
||||
- 回归测试策略
|
||||
- 冒烟覆盖主干流程；模块级回归覆盖变更影响域；跨服务联调验证接口契约（通过网关）。
|
||||
- 回归范围基于依赖关系与影响分析确定；优先自动化回归，必要时补充手工用例。
|
||||
|
||||
- 版本管理与发布
|
||||
- 分支策略建议：
|
||||
- 主分支：master；
|
||||
- 功能分支：feature/{module}-{short-desc}；
|
||||
- 预发布：release/x.y.z；
|
||||
- 紧急修复：hotfix/x.y.z；
|
||||
- 版本号：语义化版本 SemVer（MAJOR.MINOR.PATCH），发布时打 Tag；所有服务端口遵循 280xx 约定（配置文件统一）。
|
||||
|
||||
- 紧急修复与常规开发
|
||||
- 紧急修复：创建 hotfix → 修复 → 快速测试 → 合并 master 与 release → 立即发布 → 追补测试与文档。
|
||||
- 常规开发：feature → PR 审核 → 合并 → 集成测试 → 发布。
|
||||
|
||||
---
|
||||
|
||||
## 四、持续改进机制
|
||||
|
||||
- 规范评审与更新
|
||||
- 每月一次质量例会，评审新增问题与改进项；规范变更需在本文件留痕（版本/日期/变更点）。
|
||||
|
||||
- 质量指标监控（建议在 Sonar/日志/监控平台看板化）
|
||||
- 构建成功率、静态问题趋势、单元测试覆盖率、平均修复时长、缺陷密度、接口成功率、P95/P99 响应时间、数据库慢查询比例。
|
||||
|
||||
- 团队培训计划
|
||||
- 新人入项必读规范与代码演练；关键模块轮训；每季度至少一次专题分享（性能调优/安全加固/重构实践）。
|
||||
|
||||
- 反馈闭环
|
||||
- 通过代码评审、事后复盘（Postmortem）、问题工单收敛到规范条款；指定责任人与截止时间；下次评审验证落地结果。
|
||||
|
||||
---
|
||||
|
||||
## 附：标准检查清单（节选）
|
||||
|
||||
- PR 自检
|
||||
- 命名/注释达标；无魔法值；日志分级正确且无敏感信息；空指针风险已处理；删除代码/文件已获批准。
|
||||
- Controller 不含业务逻辑；路由命名与网关规范一致；统一 Result 返回；参数校验齐全；不使用 PathVariable。
|
||||
- Service 事务边界清晰；仅更新非空字段；分页/批量/幂等校验到位。
|
||||
- Repository 使用 LambdaQueryWrapper；避免硬编码字段；SQL 有必要索引；避免 N+1。
|
||||
- 测试覆盖关键路径与边界；新增功能附带测试；CI 静态扫描无阻断级问题。
|
||||
|
||||
- 回滚准备
|
||||
- 是否具备配置开关/灰度发布策略；是否提供回滚脚本；数据库迁移是否可逆（或给出补偿方案）。
|
||||
|
||||
Reference in New Issue
Block a user