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: 添加道具卡测试脚本
1.9 KiB
1.9 KiB
ALIGNMENT: 开发规范
1. 原始需求
根据用户指令,需要完成以下任务:
- 学习现有代码:参考
/internal/api/admin目录下的代码实现。 - 制定开发规范:总结并编写一份项目开发规范文档。
- 核心要求:
- 新代码必须导入对应的包。
- 遵循项目已有的代码风格和结构。
- 所有的注释都必须是中文。
2. 边界确认
- 输入:
- 项目源码,特别是
/internal/api/admin目录。 - 用户的口头指令和规范要求。
- 项目源码,特别是
- 输出:
- 一份名为
docs/开发规范.md的 Markdown 文档。 - 文档内容需清晰、准确,能作为后续开发的指导。
- 一份名为
- 范围:
- 本次任务的核心是学习和文档化,不涉及新的功能开发或代码修改。
- 规范内容应主要涵盖 API 层(Handler)的编写风格,包括但不限于:
- 目录结构和文件命名。
- 请求/响应数据结构(DTO)定义。
- Swagger 注解的使用。
core.HandlerFunc的实现模式。- 参数绑定和校验。
- 错误处理机制。
- 日志记录。
3. 需求理解
用户希望通过分析现有成熟的代码(/internal/api/admin),提炼出一套适用于本项目所有模块开发的统一规范。这套规范旨在解决之前开发过程中遇到的问题(如包导入不全、特殊字符使用不当),并确保未来代码的一致性、可读性和可维护性。
这本质上是一个逆向工程和标准化的过程:从已有实现中总结出最佳实践,并将其固化为团队必须遵守的规则。
4. 疑问澄清
目前没有需要立即澄清的疑问。我将首先分析代码,然后根据分析结果来组织规范文档的结构和内容。如果在此过程中发现任何歧义或需要决策的地方,我会再提出。