48 lines
1.5 KiB
Markdown
48 lines
1.5 KiB
Markdown
# 开发守则
|
||
|
||
**一、编码规范**
|
||
|
||
1. 命名规则
|
||
|
||
• 类名使用大驼峰（如 `UserService`），方法/变量用小驼峰（如 `getUserName`）
|
||
|
||
- 常量全大写加下划线（如 `MAX_COUNT`），禁止缩写（用 `number` 而非 `num`）
|
||
- 包名采用反向域名全小写（如 `com.example.project`）
|
||
2. 代码格式
|
||
|
||
使用阿里巴巴Java编码规范进行要求，可在Idea中安装**Alibaba Java Coding Guidelines**可实时检测代码规范问题，并提供快速修复建议
|
||
|
||
3. 注释要求
|
||
|
||
• 类注释需说明功能、作者、创建时间
|
||
|
||
- 方法注释描述参数、返回值及核心逻辑（使用Javadoc或Swagger格式）
|
||
- 关键代码块添加单行注释，避免冗余（如算法实现步骤）
|
||
- 修改时要在代码中添加注释，某年某月某日某人因何修改该处代码
|
||
|
||
**二、开发流程管理**
|
||
|
||
1. 开发前的设计阶段
|
||
- 技术方案需至少包含数据库设计文档，经评审后实施
|
||
2. 编码阶段
|
||
|
||
• 遵循“单一职责原则”，模块化拆分功能，禁止500行以上的单体类
|
||
|
||
- 每日提交代码至版本控制系统，提交信息格式为 `[类型]: 描述`（如 `[修复]: 登录验证逻辑漏洞`）
|
||
3. 测试要求
|
||
|
||
• 单元测试覆盖率需≥80%，关键路径需100%覆盖
|
||
|
||
|
||
**三、工具与协作规范**
|
||
|
||
1. 版本控制
|
||
|
||
• 分支策略：`feature/xxx`（功能分支）
|
||
|
||
|
||
**四、团队习惯培养**
|
||
|
||
1. 日常纪律
|
||
|
||
• 每日主动同步进度，每周五提交本周工作周报 |