开发模式

更新: 2026/4/24 字数: 0 字 时长: 0 分钟

/development/type 用于说明团队在不同项目阶段应该采用什么样的交付方式，以及每种方式下的最低质量要求。

什么时候用哪种模式

团队通常采用两种工作方式：

模式	适用场景	目标	典型节奏
标准开发流程	需求明确、影响范围大、需要稳定交付的项目	降低风险，保证质量与可追踪性	以里程碑或版本为单位
快速迭代模式	需求还在探索、需要快速验证价值的项目	尽快拿到反馈，缩短试错周期	以天或周为单位

选择模式时不要只看“快不快”，而要综合判断以下三个维度：

• 需求稳定性：需求是否已经明确，是否存在频繁变动的可能。
• 业务风险：功能是否涉及支付、权限、数据安全、核心链路。
• 协作复杂度：是否需要多角色协同，例如产品、设计、前后端、测试、运维同时参与。

通用原则

无论采用哪种开发模式，都应满足以下共识：

• 先对齐目标，再开始编码：每个迭代都要明确目标、范围、验收标准。
• 小步交付，持续验证：尽量将工作拆小，避免“大功能一次性上线”。
• 文档与代码同步更新：需求变更、接口变更、部署说明要及时沉淀。
• 问题尽早暴露：风险、阻塞、依赖、资源不足应尽早同步，不要等到延期时才反馈。
• 质量底线不可省略：无论多赶，都不能跳过基本测试、代码审查和上线验证。

基于 Docker 的开发方式

对于现代团队协作，推荐采用 docker-first 的开发思路：尽可能把项目运行环境、依赖服务和联调链路都放进 Docker，但不必执着于把所有个人工作工具都容器化。

推荐态度

• 尽量 all in Docker，但不强求 docker-only：项目环境可以高度容器化，个人工作环境不必全部搬进去。
• 统一环境优先于个人习惯：相比“每个人本机都能跑但配置不一样”，更推荐团队共享同一套容器化环境。
• 让 Docker 服务于开发效率：容器化的目标是降低环境成本、减少联调问题、提升可复制性，而不是增加额外负担。

适合放进 Docker 的内容

• 前端、后端、BFF、网关等业务服务
• MySQL、PostgreSQL、Redis、MongoDB 等基础依赖
• 消息队列、对象存储、本地 mock 服务
• 测试环境依赖、联调依赖、CI 所需运行环境
• Node、Java、Python、Go 等语言运行时和构建环境

不必强行放进 Docker 的内容

• IDE 本体
• 浏览器
• 系统级代理、输入法、剪贴板工具
• 设计软件、桌面协作工具
• 强依赖图形界面或本机硬件的开发工具

为什么推荐 Docker-first

• 环境一致：减少“我电脑可以，你电脑不行”的问题。
• 新成员上手快：通过 docker compose up 即可拉起核心依赖。
• 联调更稳定：数据库、缓存、队列、网关版本更容易统一。
• 更接近生产环境：便于提前发现配置、网络、端口和依赖问题。
• 便于自动化：本地、测试、CI 可以尽量共用同一套启动思路。

可能的成本

• 文件挂载、热更新、容器网络在部分机器上可能影响体验。
• 调试链路可能比直接跑本机进程更复杂。
• 如果拆得过细，容器数量过多，日常维护成本会上升。

因此，更推荐的目标是：

• 宿主机保留 IDE + 浏览器 + Docker + Git
• 项目运行依赖尽量容器化
• 通过 docker compose 统一启动本地环境
• 通过脚本或 devcontainer 降低进入成本

适用场景

以下场景尤其适合采用 Docker 开发模式：

• 团队成员较多，环境经常不一致
• 项目依赖较多，本地安装复杂
• 涉及多服务联调，例如前端 + API + 数据库 + Redis + 消息队列
• 需要让开发、测试、CI 尽可能使用相似环境

一句话建议

如果团队问“能不能 all in Docker”，更合适的回答是：项目开发环境可以尽量 all in Docker，但团队工作方式应该坚持 docker-first，而不是 docker-only。

标准开发流程

标准开发流程适合正式项目、跨团队协作项目，以及对质量、合规、可维护性要求较高的功能。

1. 需求澄清

• 明确业务目标、使用场景、边界条件和优先级。
• 补齐 PRD、流程图、原型、验收标准等输入材料。
• 识别外部依赖：第三方服务、数据库变更、权限审批、上线窗口等。

阶段产出

• 需求文档或确认记录
• 验收标准
• 风险与依赖清单

2. 技术方案设计

• 确认技术栈、模块边界、数据结构、接口契约和异常处理方案。
• 评估性能、安全、可观测性和回滚策略。
• 对复杂功能进行任务拆分和工作量评估。

阶段产出

• 技术方案文档
• 接口定义
• 排期与负责人

3. 设计与开发准备

• UI/UX 出具设计稿，与产品、开发共同确认交互细节。
• 建立开发分支、联调环境、测试数据与配置项。
• 明确埋点、权限、监控、日志等非功能需求。

4. 编码实现

• 按模块拆分任务，避免多人同时改同一片核心逻辑。
• 优先完成数据结构、接口契约与核心链路，再补充边界功能。
• 关键逻辑必须补充单元测试或至少具备可复现的验证方式。

5. 联调与测试

• 前后端联调：接口字段、错误码、空态、权限校验全部核对。
• 测试覆盖：功能测试、回归测试、关键链路验证、必要的性能测试。
• 对高风险模块增加灰度或演练步骤。

6. 审查与上线

• 通过 Pull Request 进行代码审查，重点关注业务正确性、可维护性与风险点。
• 上线前完成变更说明、回滚方案和上线检查清单。
• 发布后观察日志、监控、告警与核心业务指标。

7. 复盘与沉淀

• 记录需求偏差、实现问题、测试遗漏、发布风险。
• 将可复用方案沉淀为规范、模板或脚手架。

快速迭代模式

快速迭代模式不是“省流程”，而是“缩短反馈回路”。它适合原型验证、MVP、内部工具、活动页或新方向探索。

推荐节奏

1. 聚焦目标：只定义本轮必须验证的 1 到 3 个核心问题。
2. 压缩范围：明确什么做、什么不做，优先交付最短路径。
3. 快速设计：用草图、简版流程图、接口约定替代厚文档。
4. 并行推进：前端、后端、设计同步推进，但接口和状态字段必须先对齐。
5. 每日同步：简短同步进度、风险、依赖和变更。
6. 即时验证：每天至少保证一次可运行、可演示或可测试的版本。
7. 尽早反馈：让业务方、测试方、真实用户尽快看到可用结果。
8. 按反馈继续迭代：保留有效方案，快速丢弃无效方向。

适用前提

• 业务允许试错，短期内更重视验证速度。
• 功能边界可控，不直接影响核心交易或核心资产安全。
• 团队可以保持高频沟通，且负责人能快速拍板。

常见风险

• 没有明确“本轮不做什么”，导致需求不断膨胀。
• 只顾速度，忽略接口约定，造成后续返工。
• 演示版本直接演变成线上版本，却没有补齐测试和治理。

两种模式如何切换

项目往往不是从头到尾只采用一种模式，常见切换方式如下：

• 探索期使用快速迭代：先验证需求是否成立、用户是否买单。
• 方案收敛后切回标准流程：补齐设计、测试、监控和发布治理。
• 局部采用不同节奏：例如核心链路按标准流程执行，外围页面按快速迭代推进。

当出现以下情况时，建议从快速迭代切回标准开发流程：

• 需求已经稳定，进入长期维护阶段。
• 开始涉及权限、支付、风控、日志审计等高风险能力。
• 参与角色增多，单靠口头同步已经无法保障一致性。

最低质量基线

无论是哪种模式，以下要求都不应省略：

• 提交前至少完成一次自测，确认主流程可走通。
• 代码变更要能被他人理解，命名、结构、注释保持一致性。
• 核心接口、关键页面、异常场景必须有验证记录。
• 通过 PR 合并代码，不直接向受保护分支推送。
• 上线前明确回滚方式、负责人和观察指标。

建议的交付物

为便于协作与追踪，建议至少保留下列材料：

• 需求说明或会议结论
• 技术方案或简版设计记录
• 任务拆分和负责人
• 测试记录或验收结果
• 上线说明、风险提示与回滚方案

一句话总结

标准开发流程解决的是“如何稳定交付”，快速迭代模式解决的是“如何更快获得反馈”。真正成熟的团队，不是只会一种模式，而是能根据业务阶段主动切换节奏。