TDD优先的软件开发工作流，通过需求澄清、规划审批、任务追踪、测试驱动开发和PR代码审查确保代码质量
说明：
## 核心用法
本技能定义了一套结构化的软件开发工作流，适用于需要高质量交付的团队协作项目。工作流程分为七个阶段：
1. **需求澄清阶段**：在编码前必须充分理解业务需求、UI/UX流程、架构决策和技术约束，明确模糊点后才能继续
2. **规划审批阶段**：将任务拆分为小而专注的子任务，提交详细计划并等待明确批准，未经批准不得开始实现
3. **任务追踪设置**：使用Trello看板管理任务状态（Backlog → To Do → In Progress → Review → Done）
4. **TDD实现阶段**：严格执行测试驱动开发——先写测试（应失败）、再实现功能、再验证测试通过；每个任务完成后提交代码
5. **分支与PR策略**：禁止直接推送main分支，必须为每个任务创建特性分支，PR描述中需包含Trello任务链接
6. **PR反馈循环**：收到代码审查意见后，将任务移回In Progress，修复问题后通知审查者重新审查，循环直至批准
7. **合并门禁**：当前PR合并后才能选取下一个任务
### 显著优点
– **质量保障**：TDD在开发早期捕获缺陷，减少后期返工成本
– **流程透明**：看板可视化任务流转，状态清晰可追溯
– **风险控制**：规划审批和合并门禁防止方向性错误和代码污染
– **协作规范**：强制通知审查者、关联Trello与PR，减少沟通摩擦
– **小步快跑**：任务粒度小，代码审查负担轻，合并冲突少
### 潜在缺点与局限性
– **启动成本**：前期需求澄清和规划审批可能延缓项目启动，不适合探索性原型开发
– **流程刚性**：测试跳过需显式批准，紧急修复场景可能受限
– **工具依赖**：深度绑定Trello，使用其他项目管理工具时需要适配
– **审查瓶颈**：PR反馈循环可能成为阻塞点，审查者响应不及时时影响吞吐
– **单线程限制**：必须等PR合并才能开始下一任务，无法并行处理多个任务
### 适合人群
– 追求代码质量的中小型开发团队
– 需要严格质量门禁的协作项目（如开源贡献、外包交付）
– 采用TDD实践的敏捷团队
– 远程协作团队，需要异步透明的工作流
### 常规风险
– **流程形式化**：团队可能机械执行流程而忽视实际价值，沦为”为了流程而流程”
– **审查疲劳**：频繁的PR往返可能导致审查者倦怠，降低审查质量
– **上下文切换**：任务在In Progress和Review间反复移动，开发者需频繁切换注意力
– **工具同步失效**：Trello状态与Git状态可能不一致，需额外维护成本
会员专属
