邹方成
1ab39d2f5a
Some checks failed
Build docker and publish / linux (1.24.5) (push) Failing after 25s
feat(admin): 新增工会管理功能 feat(activity): 添加活动管理相关服务 feat(user): 实现用户道具卡和积分管理 feat(guild): 新增工会成员管理功能 fix: 修复数据库连接配置 fix: 修正jwtoken导入路径 fix: 解决端口冲突问题 style: 统一代码格式和注释风格 style: 更新项目常量命名 docs: 添加项目框架和开发规范文档 docs: 更新接口文档注释 chore: 移除无用代码和文件 chore: 更新Makefile和配置文件 chore: 清理日志文件 test: 添加道具卡测试脚本
41 lines
1.9 KiB
Markdown
41 lines
1.9 KiB
Markdown
# ALIGNMENT: 开发规范
|
||
|
||
## 1. 原始需求
|
||
|
||
根据用户指令，需要完成以下任务：
|
||
1. **学习现有代码**：参考 `/internal/api/admin` 目录下的代码实现。
|
||
2. **制定开发规范**：总结并编写一份项目开发规范文档。
|
||
3. **核心要求**：
|
||
* 新代码必须导入对应的包。
|
||
* 遵循项目已有的代码风格和结构。
|
||
* 所有的注释都必须是中文。
|
||
|
||
## 2. 边界确认
|
||
|
||
* **输入**：
|
||
* 项目源码，特别是 `/internal/api/admin` 目录。
|
||
* 用户的口头指令和规范要求。
|
||
* **输出**：
|
||
* 一份名为 `docs/开发规范.md` 的 Markdown 文档。
|
||
* 文档内容需清晰、准确，能作为后续开发的指导。
|
||
* **范围**：
|
||
* 本次任务的核心是**学习和文档化**，不涉及新的功能开发或代码修改。
|
||
* 规范内容应主要涵盖 API 层（Handler）的编写风格，包括但不限于：
|
||
* 目录结构和文件命名。
|
||
* 请求/响应数据结构（DTO）定义。
|
||
* Swagger 注解的使用。
|
||
* `core.HandlerFunc` 的实现模式。
|
||
* 参数绑定和校验。
|
||
* 错误处理机制。
|
||
* 日志记录。
|
||
|
||
## 3. 需求理解
|
||
|
||
用户希望通过分析现有成熟的代码（`/internal/api/admin`），提炼出一套适用于本项目所有模块开发的统一规范。这套规范旨在解决之前开发过程中遇到的问题（如包导入不全、特殊字符使用不当），并确保未来代码的一致性、可读性和可维护性。
|
||
|
||
这本质上是一个**逆向工程和标准化**的过程：从已有实现中总结出最佳实践，并将其固化为团队必须遵守的规则。
|
||
|
||
## 4. 疑问澄清
|
||
|
||
目前没有需要立即澄清的疑问。我将首先分析代码，然后根据分析结果来组织规范文档的结构和内容。如果在此过程中发现任何歧义或需要决策的地方，我会再提出。
|