主线只讲三件事：① 需求的生命周期（谁在什么环节做什么）② 技术方案怎么写 ③ Git 怎么协作。 很多新手只盯着"写代码"这一个环节，结果在团队里处处碰壁。看完这篇，你会明白：写代码只是整条链路里的一环，把前后环节做好，代码反而是最轻松的部分。
一、需求的生命周期（全景图）
一个需求从"想法"到"上线"，要走完下面这条流水线。每个环节都有主负责角色和配合角色：
黄色 = 大家一起开会的环节；蓝色 = 设计；绿色 = 开发自己干的活。 注意第 ⑨ 步有一条回头箭头：测出 Bug 要打回开发重改，这是最常见的循环。
二、每个环节谁负责、产出什么
把上面这张图拆开看，重点关注**「输入 → 谁负责 → 产出物」**：
| 环节 | 主负责 | 配合 | 产出物（交付件） |
|---|---|---|---|
| ① 需求提出 | 业务/客户 | 产品 | 原始诉求、问题描述 |
| ② 需求分析 | 产品经理 | — | 需求文档（PRD）+ 原型图 |
| ③ 需求评审 | 产品（主持） | 开发、测试、UI | 确认后的需求、待办问题清单 |
| ④ 技术方案设计 | 开发 | 架构师 | 技术方案文档 |
| ⑤ 技术评审 | 开发 | 架构师、相关开发 | 评审通过的方案、风险点 |
| ⑥ 编码实现 | 开发 | — | 代码 + 单元测试 |
| ⑦ 自测 | 开发 | — | 自测通过的功能 |
| ⑧ 提测 | 开发 → 测试 | — | 可测试的环境 + 提测说明 |
| ⑨ 测试 | 测试 | 开发（修 Bug） | 测试报告、Bug 列表 |
| ⑩ 验收 | 产品/业务 | — | 验收结论 |
| ⑪ 上线部署 | 开发/运维 | — | 线上可用的功能 |
| ⑫ 线上维护 | 开发 | 运维 | 问题响应、修复 |
作为开发，你深度参与的是 ③④⑤⑥⑦⑧⑨⑪⑫——几乎全程。 真正"埋头写代码"的只有 ⑥ 这一步。
开发最该上心的两个"会"
- 需求评审（③）：需求有不合理的地方，当场就要开口。别等上线后用户骂"不好用"，你却只留一句"产品让这么做的"。评审时心里要同步想：表怎么设计、要哪些接口、要不要缓存、整体流程怎么走。
- 技术评审（⑤）：把你的技术方案讲给团队听，提前暴露风险，避免开发到一半推倒重来。
三、技术方案怎么写（开发的核心交付件）
"打败你的往往不是复杂的设计，而是——面对空白文档不知道怎么开始。" 解决办法：用固定模板。思路更清晰，风格也统一。
3.1 技术方案模板
| 模块 | 写什么 | 新手提醒 |
|---|---|---|
| 背景 | 这个需求要解决什么问题 | 一两句话即可 |
| 目标 | 做完达到什么效果 | 可衡量 |
| 整体设计 | 画图：业务流程、数据流转、系统间调用 | 篇幅重点 |
| 详细设计 | 核心功能的处理逻辑、表结构、技术选型、调用时机 | 篇幅重点 |
| 接口设计 | 只列接口名，复杂的特别说明，详细的丢 Swagger | 开发前先定接口！ |
| 问题/优化 | 已知风险、暂时没做、未来可优化 | 体现你的思考深度 |
3.2 用"从整体到局部"的顺序设计
3.3 一图胜千言：常用的三种图
技术方案里不用画全所有类型的图，新手掌握这三种就能覆盖大多数需求：
| 图 | 用来表达 | 什么时候画 |
|---|---|---|
| 流程图 | 业务/逻辑的走向、分支判断 | 几乎每个需求都画 |
| 时序图 | 多个角色/系统按时间先后怎么交互调用 | 涉及多方调用时 |
| 模型图（ER/类图） | 数据结构、表与表的关系 | 涉及数据库设计时 |
画图基本规范：判断用菱形◇、流程用方框▭。别钻牛角尖抠冷门规范——只要团队都能看懂，就是好图。
示例：一个"下单"流程的时序图长这样
把这种图放进技术方案，比一大段干巴巴的文字清楚得多——评审时大家一眼就懂。
四、Git 协作：团队怎么不互相踩脚
写代码不是一个人的事。多人协作的核心规矩，就在 Git 分支模型 上。
4.1 分支模型
我们的分支分两类：代码分支（写代码、合并用）和发布分支（一推上去就触发 CI/CD 自动部署）。
| 分支 | 类型 | 作用 |
|---|---|---|
release | 代码·主干 | 稳定主干，对外生产代码以它为准；新需求都从这里切分支 |
feat/名字缩写_xxx | 代码·个人 | 你自己开发一个需求，从 release 切出 |
test | 代码·集成 | 测试集成分支，多个 feat 合到这里一起测 |
test-deploy | 发布 | 推送即触发 CI/CD，自动部署到「测试环境」 |
release-deploy | 发布 | 推送即触发 CI/CD，自动部署到「生产环境」 |
黄金法则：
- 新需求一律从
release切feat/xxx分支，不要直接在release上写代码。test-deploy/release-deploy是"开关"不是"工作区"——你不在上面写代码，只是把验证好的代码推上去，剩下的部署 CI/CD 全自动帮你做。- 测试通过后，
feat合回release，再由release触发生产发布。💡 线上紧急 Bug 也一样：从
release切个feat/hotfix_xxx，修完走同样的流程发布。
4.2 一个需求的 Git 实操流程
关键认知：你手动做的只到"合并、推送"为止，"部署"这一步是推送到发布分支后由 CI/CD 自动完成的——这也是为什么发布分支不能乱推。
4.3 提交（commit）的基本规范
提交信息别再写 update、修改、111 了。用「类型 + 说明」：
| 类型 | 含义 | 示例 |
|---|---|---|
feat | 新功能 | feat: 新增订单超时自动取消 |
fix | 修 Bug | fix: 修复库存超卖问题 |
refactor | 重构 | refactor: 抽取订单校验逻辑 |
docs | 文档 | docs: 补充接口说明 |
style | 格式 | style: 统一缩进 |
好处：翻历史一眼看懂每次改了什么，回滚、定位问题都快。
4.4 Code Review 看什么
合并前同事帮你审一遍代码，主要看：
- 逻辑对不对、有没有明显 Bug；
- 有没有循环里查库、没命中索引、该加缓存没加这类性能坑；
- 命名、风格是否符合团队规范（推荐遵循阿里巴巴开发规范 + 编辑器插件）；
- 是否和技术方案一致。
五、串起来：完整工作流一张图
六、给新手的 5 条心法
- 写代码只是一环：需求评审、技术方案、自测、上线维护，开发全程都要参与。
- 方案先行：技术方案写扎实了，编码就是享受；方案有问题，代码必然返工。
- 多花时间在设计上：一图胜千言，前期想清楚，Bug 率断崖式下降。
- Git 守规矩：新需求从
release切feat分支干活，不乱推发布分支，commit 写清楚，Review 走起来。 - 有责任心：需求不合理就开口，提测前先自测，上线后出问题马上响应。