本文适合：刚入行不知道拿到需求后该怎么一步步做的开发新人、想规范团队开发流程的技术负责人、对每日构建和持续集成感兴趣但没落地过的工程师。
你将收获：分析与设计方法四类工具、从Spec到实现的标准开发流程、开发阶段日常管理（每日构建/小强地狱/构建大师）、AI结对编程对开发流程的重塑。
写在前面
第十章解决了"为谁设计"和"怎么把需求说清楚"（典型用户+Spec），第十一章终于进入开发者最熟悉的领域：拿到Spec之后，怎么一步步把代码写出来并交付。
邹欣老师在微软的实战经验告诉我：优秀的开发不是"拿到需求就写代码"，而是有一套标准化的工作流程。 跳过任何一步，后面都会加倍还债。
第四版在这一章融入了AI结对编程对开发流程的影响，这是与前三版最大的差异。
章际衔接：从"为谁设计"到"怎么实现"
|
维度 |
第十章（典型用户和场景） |
第十一章（软件设计与实现） |
|
核心问题 |
为谁设计、怎么把需求说清楚 |
拿到Spec后怎么一步步把代码写出来 |
|
视角 |
用户与场景 |
开发与工程 |
|
关键产出 |
典型用户画像、用例、Spec |
可交付的代码、构建产物 |
|
比喻 |
"用户画像" |
"施工图纸到交付" |
一句话衔接： 第十章产出了"施工图纸"（Spec），第十一章讲"怎么按图纸施工"。
01 | 分析与设计方法：四种描述工具
1.1 四类工具速查
拿到需求后，第一步不是写代码，而是分析和设计。书中介绍了四类描述工具：
|
类型 |
代表方法 |
特点 |
适用场景 |
|
文字为主 |
需求文档、设计文档 |
易读、易改 |
小型项目、简单功能 |
|
图形为主 |
思维导图、ERD、DFD、UML |
直观、结构化 |
中大型项目、复杂关系 |
|
数学语言 |
形式化方法（Z语言、VDM） |
精确无歧义 |
安全关键系统 |
|
类语言+代码 |
伪代码、接口定义、原型代码 |
可执行、可验证 |
技术细节验证 |
1.2 图形建模方法
书中重点介绍了几种图形工具的适用场景：
|
图形工具 |
表达什么 |
我的理解 |
|
思维导图 |
实体间的层级关系 |
适合头脑风暴、功能分解 |
|
ERD（实体关系图） |
数据实体及其关系 |
适合数据库设计 |
|
DFD（数据流图） |
数据在系统中的流动 |
适合理解业务流程 |
|
UML用例图 |
角色与功能的映射 |
适合需求阶段 |
|
UML类图 |
类的结构与关系 |
适合详细设计 |
|
FSM（有限状态机） |
状态转换与控制流 |
适合复杂状态逻辑 |
1.3 不要为画图而画图
书中提醒：图形工具是手段不是目的。 很多团队"为了文档而画UML"，画完就没人看了。正确的做法是：哪个工具能帮你把问题想清楚，就用哪个。 想不清楚的时候画图，想清楚了就不用画了。
我的实战感悟
我们团队早期每个功能都要求画完整UML——类图、时序图、活动图。结果开发花在画图上的时间比写代码还多，图还没人维护。后来改成"关键功能画图、简单功能直接写"——只有涉及多模块交互或复杂状态的功能才要求画UML，简单CRUD直接写代码。
工具是帮你思考的拐杖，不是给别人看的展板。
一句话提炼
四类描述工具各有侧重：文字读得懂、图形看得清、数学写得准、代码跑得通。选对工具比用全工具更重要。
02 | 从Spec到实现：开发者的标准工作流
2.1 标准开发流程
书中给出了一个开发人员拿到Spec后的标准工作流程：
|
步骤 |
名称 |
做什么 |
产出 |
|
1 |
需求分析 |
理解Spec，确认需求边界和验收标准 |
需求理解确认 |
|
2 |
复审设计文档 |
检查技术可行性，发现设计缺陷 |
设计问题清单 |
|
3 |
估计 |
估算任务所需时间 |
工时估算 |
|
4 |
原型 |
写快速原型代码验证效果 |
原型Demo |
|
5 |
详细设计 |
写设计文档，明确实现方案 |
设计文档 |
|
6 |
编程 |
按设计文档写代码 |
源代码 |
|
7 |
自我复审 |
自己检查代码规范和逻辑 |
修改记录 |
|
8 |
同伴复审 |
请同事审查代码 |
复审意见 |
|
9 |
单元测试 |
写测试并确保通过 |
测试用例 |
|
10 |
集成签入 |
合并代码到主干，运行构建 |
签入记录 |
2.2 每一步都不能跳
书中强调：这个流程看起来"繁琐"，但每跳过一步，后面都会加倍还债。
|
跳过的步骤 |
短期看 |
长期后果 |
|
跳过原型 |
省了半天 |
设计方案不可行，返工一周 |
|
跳过详细设计 |
省了一天 |
编码时频繁改方向，浪费三天 |
|
跳过自我复审 |
省了一小时 |
同伴复审发现低级错误，丢人 |
|
跳过同伴复审 |
省了半天 |
上线后发现Bug，修一个改坏三个 |
|
跳过单元测试 |
省了一天 |
集成时全崩，排查两天 |
2.3 "闭门造车"的故事
书中讲了一个"闭门造车"的教训：一个开发人员拿到任务后不跟任何人沟通，自己闷头干了两周，结果做出来的东西跟PM期望的完全不一样——需求理解偏了、接口对不上、风格不统一。
开发不是个人创作，是团队协作。 每一步的产出（原型、设计文档、代码）都是与团队"对齐"的机会。
我的实战感悟
我带团队最头疼的就是"闷头型开发"——分配任务后一声不吭，问进度永远说"快了"，交付一看全偏。后来强制要求两个"汇报点"：第1天出原型Demo（对齐方向），第3天出设计文档（对齐方案）。不行就打回重来。
宁可提前对齐返工一天，不要交付后发现偏了两周。
一句话提炼
标准开发流程十步：需求→复审→估计→原型→设计→编码→自审→同伴审→单测→集成。跳过任何一步，后面加倍还债。
03 | 代码复审：不是找茬，是互助
3.1 三种复审方式
|
方式 |
谁来审 |
效果 |
成本 |
|
自我复审 |
自己 |
发现明显问题，但盲区看不到 |
低 |
|
同伴复审 |
同级别同事 |
发现逻辑错误和风格问题 |
中 |
|
团队复审 |
全组一起 |
发现架构级问题，促进知识共享 |
高 |
3.2 复审查什么
书中明确了代码复审的四层检查：
|
检查层 |
查什么 |
举例 |
|
规范层 |
是否符合编码规范 |
命名规范、注释格式 |
|
逻辑层 |
逻辑是否正确 |
边界条件、空值处理 |
|
设计层 |
是否符合架构设计 |
分层是否正确、接口是否合理 |
|
安全层 |
是否有安全风险 |
SQL注入、XSS、权限绕过 |
3.3 复审的纪律
书中强调了几条复审纪律：
|
纪律 |
说明 |
|
对事不对人 |
审代码不是审人，不评价能力 |
|
记录问题 |
复审意见必须记录，不能口头说完就忘 |
|
限时修改 |
复审发现的问题必须在约定时间内修复 |
|
交叉复审 |
避免总是同一个人审同一个人的代码 |
我的实战感悟
我们团队推行代码复审时遇到的最大阻力是"面子问题"——开发觉得被审代码就是"被质疑能力"。后来我改了说法，叫"同伴互审"，并且要求每个人既审别人也被别人审。慢慢地团队发现复审能学到别人的写法，抵触就小了。
代码复审不是"审你"，是"帮我们俩"。
一句话提炼
代码复审四层：规范、逻辑、设计、安全。核心原则是对事不对人——审的是代码，不是人。
04 | 开发阶段的日常管理
4.1 每日构建
书中重点介绍了"每日构建"（Daily Build）的概念：
|
维度 |
说明 |
|
是什么 |
每天自动、完整地构建整个代码树 |
|
为什么 |
尽早发现集成问题，避免"攒到最后崩" |
|
怎么做 |
定时触发自动化构建脚本，编译+测试+打包 |
|
谁负责 |
全员负责——任何人的代码导致构建失败，必须立即修复 |
4.2 小强地狱
书中提到了一个生动的概念——"小强地狱"（Bug Hell）：
如果某人的代码导致每日构建失败，他就被分配去修所有"小强"（Bug），直到全部清理干净才能继续开发新功能。这是一种"惩罚机制"，逼着每个人在签入前充分测试。
4.3 构建大师
另一个概念——"构建大师"（Build Master）：
团队中指定一个人负责维护构建系统，监控构建状态，在构建失败时协调修复。构建大师不一定是技术最强的人，但必须是最有责任心的人。
4.4 从每日构建到持续集成
|
阶段 |
频率 |
代表工具 |
核心理念 |
|
每日构建 |
每天1次 |
脚本+计划任务 |
一天一集成 |
|
持续集成 |
每次签入 |
Jenkins、GitLab CI |
签入即集成 |
|
持续交付 |
每次通过测试 |
ArgoCD、Spinnaker |
随时可部署 |
|
持续部署 |
每次通过自动部署 |
K8s+GitOps |
签入即上线 |
书中讲的"每日构建"是持续集成的雏形。在第四版时代，大部分团队已经从"每日构建"进化到了"持续集成"甚至"持续部署"，但核心理念不变：尽早集成、尽早暴露问题。
我的实战感悟
我们团队早期没有每日构建，代码攒了两周才集成一次——每次集成就是一场"灾难"，合并冲突、接口不兼容、测试全崩。后来上了GitLab CI，每次签入自动触发构建和测试，构建失败立即修复。集成时间从"两天"降到了"十分钟"。
集成越频繁，每次集成的痛苦越小。
一句话提炼
每日构建是持续集成的雏形——核心不是"每天"，而是"尽早集成、尽早暴露问题"。
05 | AI结对编程：开发流程的重塑（第四版新增）
5.1 AI如何改变开发流程
第四版重点融入了AI结对编程对传统开发流程的影响：
|
开发步骤 |
传统方式 |
AI辅助方式 |
|
需求理解 |
人工读Spec |
AI辅助解读Spec、自动提取关键约束 |
|
原型 |
手写原型代码 |
AI根据Spec生成原型初稿 |
|
详细设计 |
手写设计文档 |
AI根据需求生成设计方案草案 |
|
编程 |
手写全部代码 |
AI生成代码片段，人工审查修改 |
|
代码复审 |
同伴人工审 |
AI自动审查规范和逻辑，人工审设计 |
|
单元测试 |
手写测试用例 |
AI自动生成测试用例初稿 |
|
集成 |
手动触发 |
AI辅助分析集成风险 |
5.2 AI结对编程 vs 人类结对编程
|
维度 |
人类结对 |
AI结对 |
|
知识广度 |
限于个人经验 |
覆盖广泛技术栈 |
|
响应速度 |
需要沟通时间 |
即时响应 |
|
耐心 |
审多了会烦 |
永不疲倦 |
|
创新性 |
能提出意想不到的思路 |
基于已有模式推荐 |
|
上下文理解 |
深入理解业务背景 |
可能缺乏业务上下文 |
|
责任承担 |
人对代码负责 |
AI不对结果负责 |
5.3 人的角色变了
AI结对编程后，开发人员的角色从"写代码的人"变成了"审代码的人"：
|
维度 |
传统开发 |
AI辅助开发 |
|
核心动作 |
写代码 |
审代码、改代码 |
|
时间分配 |
70%写+30%审 |
30%写+70%审 |
|
关键能力 |
编码能力 |
判断能力、审查能力 |
|
质量风险 |
人写人审，盲区重叠 |
AI写的代码人必须审，否则隐患更大 |
5.4 AI不能替代的环节
书中提醒：AI能加速编码，但有三件事替代不了：
1. 需求理解——AI能读Spec，但"用户真正想要什么"需要人与PM、用户沟通确认
2. 架构决策——AI能给出方案，但"选哪个方案"需要结合业务约束、团队能力、长期演进做判断
3. 质量责任——AI写的代码出了Bug，责任还在人身上。AI不背锅
我的思考
我们团队从去年开始用AI编程助手，最直观的变化是——代码产出速度提升了，但代码审查的压力更大了。 以前一个人一天写200行，现在AI帮他生成500行，他要审500行。审查能力成了新的瓶颈。
AI让"写代码"变便宜了，但让"审代码"变更重要了。
一句话提炼
AI结对编程让开发从"写代码的人"进化为"审代码的人"——核心能力从编码速度转向判断力和审查力。
干货复盘
|
本章核心概念 |
一句话理解 |
常见误区 |
|
四类设计工具 |
文字读得懂、图形看得清、数学写得准、代码跑得通 |
"什么都要画UML" |
|
标准开发流程 |
十步流程，跳过一步后面加倍还债 |
"拿到需求直接写代码" |
|
代码复审 |
对事不对人，审代码不是审人 |
"复审就是找茬" |
|
每日构建 |
尽早集成、尽早暴露问题 |
"等做完了再集成" |
|
小强地狱 |
构建失败者去修Bug |
"构建失败无所谓" |
|
持续集成进化 |
每日构建→持续集成→持续交付→持续部署 |
"这些都是一回事" |
|
AI结对编程 |
从"写代码"到"审代码"，核心是判断力 |
"AI写的代码不用审" |
本章最大收获： 这一章的核心是"标准化"——开发不是个人创作，而是一套有纪律的工程流程。十步标准流程、代码复审四层检查、每日构建、AI结对编程，所有方法指向同一个目标：把"个人水平"变成"团队水平"，让质量不依赖某个人的状态。 在AI时代，开发的核心能力正在从"编码速度"转向"审查判断力"——AI帮你写，但你必须看得懂、判得准、负得起责。
下篇分享第十二章：用户体验。如果这篇笔记对你有帮助，欢迎转发给也在学软件工程的朋友。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/weixin_40967106/article/details/165627339
