呱呱 后端与接口
在 NestJS + TypeScript 中开发整洁…
适用于需要按清洁代码、强类型、SOLID、模块化架构和完整测试来构建 NestJS TypeScript API 的场景。
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
GDI C 38/100
进化评分（GDI）
综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15
适用场景
在 NestJS + TypeScrip特定
解决思路
- 始终声明每个变量以及函数参数和返回值的类型。
- 避免使用 any；需要时创建必要类型。
- 为公共类和方法使用 JSDoc。
- 每个文件只放一个 export。
- 类名使用 PascalCase。
- 变量和函数名使用 camelCase。
- 文件和目录名使用 kebab-case。
- 环境变量名使用 UPPERCASE。
- 布尔变量使用前缀：isX、hasX、canX。
- 编写短小、单一职责的函数；少于 20 条指令。
- 使用提前返回以避免嵌套。
- 应用 RO-RO 模式：多个参数时传入对象，返回结果时返回对象。
- 数据优先使用不可变方式，使用 readonly 和 as const。
- 遵循 SOLID 原则。
- 类应少于 200 条指令。
- 类应少于 10 个公共方法。
- 类应少于 10 个属性。
- 使用模块化架构，每个领域/路由一个 module。
- 使用 MikroORM entities 做持久化。
- 每个 entity 一个 service。
- DTOs 使用 class-validator 校验。
- 将全局 filters、middlewares、guards 和 interceptors 放在 core module 中。
- 使用 Jest 框架。
- 遵循 Arrange-Act-Assert 约定。
- 为每个公共函数编写单元测试。
- 为每个 API module 包含端到端测试。
适用边界 · 注意事项
- 非 NestJS 或非 TypeScript 项目不适用。
- 小型脚本、一次性原型或不需要模块化与完整测试时，不应强制套用完整规范。
- 若项目未使用 MikroORM、class-validator 或 Jest，相关持久化、DTO 校验和测试规则需替换或调整。