110 lines
4.6 KiB
Markdown
110 lines
4.6 KiB
Markdown
---
|
||
tags: []
|
||
aliases:
|
||
- 渐进式开发最佳实践
|
||
date created: 星期一, 十二月 8日 2025, 12:04:31 凌晨
|
||
date modified: 星期一, 十二月 8日 2025, 12:05:12 凌晨
|
||
---
|
||
|
||
# 渐进式开发最佳实践
|
||
|
||
## 1. 必须在写代码前锁定的“硬约束” (The Non-Negotiables)
|
||
|
||
即使是后规划细节，但这 **4 样东西** 是一旦开工就很难改的，必须在骨架阶段定死：
|
||
|
||
1. **目录结构 (Directory Layout):** `cmd`, `internal`, `pkg` 怎么分。这决定了你能不能顺畅地加代码。
|
||
|
||
- _现状:_ 我们已经定好了 (Modular Clean Architecture)。
|
||
|
||
2. **核心技术栈与基础设施:** 选 Gin 还是 Echo，用 GORM 还是 SQLX，依赖注入用 Wire 还是手写。
|
||
|
||
- _现状:_ 我们已经定好了 (Gin+GORM+Wire+Viper)。
|
||
|
||
3. **统一的交互规范:** API 怎么返回错误？数据库怎么管理变更？日志打在哪里？
|
||
|
||
- _现状:_ 我们已经定好了 (JSON Envelope, Golang-Migrate, Zap)。
|
||
|
||
4. **核心领域模型 (Core Schema):** 最关键的表（User, Role）。
|
||
|
||
- _原因:_ 它们是系统的地基，地基不稳，后面写 Service 逻辑会反复推倒重来。
|
||
|
||
---
|
||
|
||
## 2. 可以（且应该）推迟设计的“软逻辑” (The Deferrables)
|
||
|
||
这些内容不要现在想，想了也是白想，等写到那个函数时再具体的“具体问题具体分析”：
|
||
|
||
1. **复杂的业务算法:** 比如“文章的热度排名算法”、“复杂的权限递归校验逻辑”。
|
||
|
||
- _策略:_ 先写个 `return true` 或简单的逻辑占位，跑通流程再说。
|
||
|
||
2. **极致的性能优化:** 比如“这里要不要加 Redis 缓存？”、“这里 SQL 要不要分表？”。
|
||
|
||
- _策略:_ 先跑通功能 (Make it work)，再优化性能 (Make it fast)。
|
||
|
||
3. **非核心字段的定义:** 比如文章表里要不要加 `seo_keywords`，用户表要不要加 `wechat_id`。
|
||
|
||
- _策略:_ 用到了再加 migration，不要为了“未来可能用到”而过度设计。
|
||
|
||
4. **具体的 API 参数细节:** 比如“更新文章是传 ID 还是传 UUID”。
|
||
|
||
- _策略:_ 写 Handler 的时候，顺手定义 DTO 就行。
|
||
|
||
---
|
||
|
||
## 3. 个人开发者的“曳光弹”开发流 (The Tracer Bullet Workflow)
|
||
|
||
不要试图“横向”开发（先把所有 50 张表设计完，再把所有 API 定义完）。
|
||
|
||
要进行 “纵向”切片开发（Vertical Slice）。
|
||
|
||
**推荐的实操步骤：**
|
||
|
||
### 第一阶段：搭建“行走的骨架” (Day 1 - 也就是你现在该做的)
|
||
|
||
**目标：** 一个能跑起来、能连数据库、有日志、有 Swagger 文档，但没有任何业务功能的空壳。
|
||
|
||
1. **初始化项目:** 建立文件夹，`go mod init`。
|
||
2. **配置基础设施:** 放入 `Makefile`, `docker-compose.yml`, `config.yaml`。
|
||
3. **连通性测试:** 写一个简单的 `GET /ping` 接口，确保能读到配置，能连上 DB，能打出日志。
|
||
4. **依赖注入跑通:** 确保 `wire` 能自动生成代码并启动 Server。
|
||
5. **结果:** 你拥有了一个**“生产级”的 Hello World**。
|
||
|
||
### 第二阶段：第一个“核心切片” (Day 2-3)
|
||
|
||
**目标:** 打通 User 模块的完整闭环。
|
||
|
||
1. **DB:** 设计 `users` 表，执行 Migrate。
|
||
2. **Entity:** 生成 User Struct。
|
||
3. **Repo:** 写 `CreateUser` 和 `FindUser` 的 CRUD。
|
||
4. **Service:** 写 `Register` 逻辑（这里涉及到密码加密，此时再去查 Argon2 怎么用）。
|
||
5. **API:** 定义 `RegisterReq` DTO，写 Handler。
|
||
6. **测试:** 用 Postman/Swagger 调通注册接口。
|
||
|
||
### 第三阶段：具体问题具体分析 (Day 4+)
|
||
|
||
**目标:** 遇到什么写什么。
|
||
|
||
- _场景:_ 比如你做到了“文章发布”，突然发现需要“敏感词过滤”。
|
||
- _动作:_ 停下来，在 `pkg/util` 里设计一个敏感词过滤函数（或者找个库），然后在 Service 层调用它。
|
||
- _这就是你说的:_ “进行到具体的业务逻辑的时候进行设计”。
|
||
|
||
---
|
||
|
||
## 4. 总结给你的建议
|
||
|
||
你现在的焦虑在于试图**预见未来**。
|
||
|
||
**作为个人开发者，你的代码就是你的设计文档。**
|
||
|
||
**你的下一步行动：**
|
||
|
||
1. **停止**思考复杂的业务场景。
|
||
2. **立即**按照我们之前确定的目录结构，新建文件夹。
|
||
3. **立即**把 `docker-compose` 跑起来，把 `main.go` 跑起来。
|
||
4. **立即**实现“用户注册”这一个功能。
|
||
|
||
只要“骨架”（架构分层、依赖注入、数据库管理方式）是对的，后面你往里面填什么肉（业务逻辑），怎么填，都不会把楼盖歪。
|
||
|
||
**准备好开始初始化项目文件夹了吗？**
|