任务工作流

一种结构化的开发工作流，通过计划、测试驱动开发（TDD）和代码审查来保障交付质量。

工作流概览

明确需求 → 制定计划 → 获得批准 → 实现（TDD） → 提交 PR → 审查 → 合并 → 下一任务

阶段 1：需求澄清

在任何实现开始前，需提出问题以明确以下内容：

• 业务需求与目标
• UI/UX 流程预期
• 架构决策
• 技术约束条件
• 存在歧义的需求

需求未明确前，不得进入下一阶段。

阶段 2：计划与审批

1. 提交详细计划，包含任务拆解
2. 保持任务粒度小且聚焦
3. 必须获得明确审批后方可启动开发
4. 未经审批，禁止开展任何实现工作

阶段 3：任务跟踪设置

搭建 Trello 看板（或同类工具），配置以下列：

• 📝 Backlog
• 📋 To Do
• 🔨 In Progress
• 🔍 Review
• ✅ Done

所有任务必须在看板中进行跟踪。

阶段 4：任务级实现

针对每个任务：

1. 将卡片移至 “In Progress” 列
2. 先编写测试（TDD）：
   • 在测试中定义预期行为
   • 运行测试（应失败）
   • 实现功能逻辑
   • 再次运行测试（应通过）
3. 任务完成后执行 Commit
4. 仅在获得 明确审批 的前提下，方可跳过测试

阶段 5：分支与 PR 规范

规则如下：

• 禁止直接向 main 分支推送代码
• 禁止更改默认分支 —— main 必须始终为默认分支
• 每个任务均需创建独立的 feature 分支

任务完成后：

1. 从任务分支发起 PR 至 main
2. PR 描述中需包含对应 Trello 任务链接
3. 将卡片移至 “Review” 列
4. 同时向 Reviewer 发送通知，并附上 Trello 链接与 PR 链接

阶段 6：PR 反馈循环

当收到 CR（Code Review）评论时：

1. 将任务卡片移回 “In Progress” 列
2. 逐一响应并修复所有评审意见
3. 推送修复后的代码
4. 通知 Reviewer 进行复审（需同时提供 Trello 链接与 PR 链接）

重复该流程直至 PR 获得批准。

阶段 7：合并守门机制

• 当前 PR 合并完成前，不得领取新任务
• 将已合并任务的卡片移至 “Done” 列
• 随后从 “To Do” 列中选取下一任务继续执行

流程图

Backlog → To Do → In Progress → Review → Done
                      ↑            │
                      └─── CR ─────┘

新项目初始化

对于新项目：

1. 创建仓库，并提交初始 README
2. 推送到远程仓库
3. 随后开始执行各项实现任务

核心原则

• 质量优先于速度 —— TDD 可在早期捕获缺陷
• 任务粒度小 —— 更易于审查与合并
• 沟通清晰透明 —— 始终主动同步 Reviewer
• 杜绝捷径 —— 每次均须严格遵循本流程