6.5 完成复盘：经验总结与后续行动
让经验可迁移，让改进可持续
复盘不是自我批评，而是客观分析
6.4 完成简历和作品集后，项目成果已经可以展示和复用。但如果不对项目过程进行反思，经验就只能停留在这一次。复盘的目标是客观分析项目中的经验和教训，让经验可迁移，让改进可持续。
本节将帮助你完成项目复盘，识别做得好、做得不好、学到什么、下次怎样改进，形成能力差距分析和后续行动计划。
本节学习目标
完成项目复盘报告，包含做得好、做得不好、学到什么、下次改进四个维度；完成能力差距分析表，明确当前能力、目标能力、差距和弥补方案；制定后续行动计划（3—6 个月），包括毕业设计、竞赛、求职等方向。
返回上一节：整理简历
返回第六篇导读
🎯 本节完成后，你要交付
| 成果 |
要求 |
| 项目复盘报告 |
2—4 页，包含做得好、做得不好、学到什么、下次改进 |
| 能力差距分析表 |
明确当前能力、目标能力、差距和弥补方案 |
| 后续行动计划 |
3—6 个月，包括毕业设计、竞赛、求职等方向 |
| 给未来团队的建议 |
如适用，包含协作、流程、技术方面的建议 |
复盘必须基于真实经历
不要虚构经验、夸大成长或抄袭他人复盘。复盘的价值在于真实反思，虚构内容无法指导后续行动。
一、复盘的四个问题
复盘围绕四个核心问题展开，每个问题都要有具体例子和分析。
1. 做得好：识别超出预期的做法，形成可复制经验
目的：识别项目中超出预期的做法，形成可复制经验，在下一个项目中继续使用。
分析框架：
| 维度 |
问题 |
示例 |
| 流程 |
哪些流程安排得好？ |
提前冻结需求基线，避免了后期大范围返工 |
| 技术 |
哪些技术决策好？ |
选择 Docker Compose 部署，降低部署门槛 |
| 协作 |
哪些协作方式好？ |
每日站会 + 任务看板，进度可视化 |
| 质量 |
哪些质量保障好？ |
提前编写测试计划，核心功能覆盖完整 |
| 沟通 |
哪些沟通方式好？ |
通过文档共享设计决策，减少口头误解 |
写法要求：
- 具体：用具体例子代替空泛描述；
- 可复制：说明为什么好，怎样在下一个项目中复制；
- 量化：用数字说明效果（如减少返工次数、提高测试覆盖率）。
示例：
| ## 做得好
### 1. 提前冻结需求基线
- 做法：在需求分析阶段，通过教师评审确认需求基线，后续变更通过变更评审流程控制；
- 效果：避免了后期大范围返工，需求变更次数从 8 次减少到 3 次；
- 可复制：下一个项目中，继续采用需求基线冻结和变更评审机制。
### 2. 测试驱动开发
- 做法：在核心功能开发前，先编写测试用例，再实现功能；
- 效果：发现 3 个 P0 缺陷，全部在开发阶段修复，避免了部署后才发现；
- 可复制：下一个项目中，继续采用测试驱动开发，扩大测试覆盖范围。
### 3. Docker 容器化部署
- 做法：使用 Docker Compose 编排 MySQL、后端、前端、Nginx，实现一键部署；
- 效果：部署时间从 30 分钟减少到 5 分钟，部署环境可复现；
- 可复制：下一个项目中，继续使用 Docker，增加 CI/CD 自动化部署。
|
2. 做得不好：识别低于预期的地方，明确改进方向
目的：识别项目中低于预期的地方，明确改进方向，避免在下一个项目中重复犯错。
分析框架：
| 维度 |
问题 |
示例 |
| 流程 |
哪些流程安排不好？ |
测试计划制定太晚，部分功能测试不充分 |
| 技术 |
哪些技术决策不好？ |
未使用 CI/CD，部署依赖人工操作 |
| 协作 |
哪些协作方式不好？ |
分工不明确，部分模块重复开发 |
| 质量 |
哪些质量保障不好？ |
性能测试未覆盖高并发场景 |
| 沟通 |
哪些沟通方式不好？ |
设计决策通过口头沟通，无文档记录 |
写法要求：
- 诚实：承认不足，不要回避或掩饰；
- 分析：说明原因，不要只列问题不分析；
- 改进：提出具体改进方向，不要只批评不建设。
示例：
| ## 做得不好
### 1. 测试计划制定太晚
- 问题：测试计划在核心功能开发完成后才制定，部分功能测试不充分；
- 原因：对测试的重要性认识不足，认为开发完成后再测试即可；
- 影响：部分边界场景未覆盖，部署后才发现权限绕过问题；
- 改进：下一个项目中，测试计划与需求分析同步进行，核心功能开发前先写测试用例。
### 2. 未使用 CI/CD
- 问题：部署依赖人工操作，容易出错且不可复现；
- 原因：对 CI/CD 工具不熟悉，认为 Docker Compose 已足够；
- 影响：每次部署需要手动执行 5—6 个命令，耗时且易错；
- 改进：下一个项目中，学习 GitHub Actions 或 GitLab CI，实现自动化部署。
### 3. 性能测试未覆盖
- 问题：未进行高并发和压力测试，系统性能未知；
- 原因：时间有限，优先保证功能正确性；
- 影响：无法评估系统在高并发场景下的表现；
- 改进：下一个项目中，使用 JMeter 进行压力测试，评估系统性能。
|
3. 学到什么：沉淀新技能、新方法、新认知
目的：沉淀项目中获得的新技能、新方法和新认知，作为能力成长的记录。
分析框架：
| 维度 |
问题 |
示例 |
| 技术能力 |
学到了哪些新技术？ |
掌握了 Spring Boot、Vue 3、Docker |
| 工程能力 |
学到了哪些工程方法？ |
理解了测试驱动开发、缺陷管理 |
| 协作能力 |
学到了哪些协作方法？ |
学会了 Git 分支管理、代码审查 |
| 反思能力 |
学到了哪些新认知？ |
理解了需求变更控制的必要性 |
写法要求：
- 具体：用具体技术或方法代替空泛描述；
- 可验证：说明学会的证据（如完成模块、通过测试）；
- 可迁移：说明如何在下一个项目中应用。
示例：
| ## 学到什么
### 1. 技术能力
- Spring Boot 3：掌握了依赖注入、AOP、自动配置、异常处理；
- Vue 3：掌握了组合式 API、Pinia 状态管理、Vue Router；
- Docker：掌握了 Dockerfile 编写、Docker Compose 编排、Nginx 反向代理；
- MySQL 8：掌握了表设计、外键约束、索引优化。
### 2. 工程能力
- 测试驱动开发：理解了先写测试再实现的重要性；
- 缺陷管理：学会了缺陷记录、优先级排序、回归测试；
- 部署验证：理解了从干净环境验证部署的必要性。
### 3. 协作能力
- Git 分支管理：学会了 feature 分支、PR 评审、冲突解决；
- 文档协作：学会了通过文档共享设计决策，减少口头误解；
- 任务分解：学会了将大任务分解为小任务，通过看板跟踪进度。
### 4. 反思能力
- 需求变更控制：理解了需求基线冻结和变更评审的必要性；
- 技术选型：理解了对比分析的重要性，不盲目跟风；
- 风险管理：理解了提前识别风险和制定预案的必要性。
|
4. 下次怎样做得更好：制定具体行动计划
目的：基于复盘结果，制定具体行动计划，确保持续改进。
写法要求：
- 具体：用具体行动代替空泛目标；
- 可衡量：用数字或里程碑说明进度；
- 可实现：确保行动在现有条件下可实现；
- 有时间：明确行动的时间范围。
示例：
| ## 下次怎样做得更好
### 1. 流程改进
- 行动 1：测试计划与需求分析同步进行，核心功能开发前先写测试用例；
- 行动 2：引入 CI/CD，使用 GitHub Actions 实现自动化部署；
- 行动 3：每日站会 + 任务看板，进度可视化。
### 2. 技术改进
- 行动 1：学习 JMeter，进行压力测试，评估系统性能；
- 行动 2：学习响应式设计，优化移动端适配；
- 行动 3：学习 Spring Security，增强安全防护。
### 3. 协作改进
- 行动 1：明确分工，每个模块有唯一负责人；
- 行动 2：设计决策通过文档记录，减少口头沟通；
- 行动 3：定期代码审查，提高代码质量。
|
二、能力差距分析
1. 能力差距分析表
| 能力维度 |
当前能力 |
目标能力 |
差距 |
弥补方案 |
时间范围 |
| 后端开发 |
能独立完成 Spring Boot 项目 |
能设计高并发架构 |
缺乏高并发经验 |
学习 JMeter、阅读《高并发系统设计》 |
3 个月 |
| 前端开发 |
能协助前端开发 |
能独立完成前端项目 |
缺乏响应式设计经验 |
学习 Vue 组件库、实践响应式设计 |
3 个月 |
| 数据库设计 |
能设计核心表结构 |
能优化查询性能 |
缺乏索引优化经验 |
学习 MySQL 索引原理、实践查询优化 |
2 个月 |
| 测试验证 |
能编写功能测试用例 |
能进行自动化测试和性能测试 |
缺乏自动化测试经验 |
学习 JUnit 5 高级用法、实践 JMeter |
3 个月 |
| 部署运维 |
能使用 Docker 部署 |
能使用 CI/CD 自动化部署 |
缺乏 CI/CD 经验 |
学习 GitHub Actions、实践自动化部署 |
2 个月 |
| 文档编写 |
能编写 README 和设计文档 |
能编写技术博客和用户手册 |
缺乏技术写作经验 |
学习技术写作规范、实践技术博客 |
持续 |
| 团队协作 |
能在 3 人团队中协作 |
能在大型团队中协作 |
缺乏大型团队经验 |
参与开源项目、学习敏捷开发 |
持续 |
| 问题解决 |
能解决常见技术问题 |
能解决复杂架构问题 |
缺乏复杂问题经验 |
阅读源码、参与技术社区 |
持续 |
2. 能力差距分析示例
| # 能力差距分析
## 当前能力
- 后端开发：能独立完成 Spring Boot + MyBatis-Plus 项目，具备基础测试和部署能力；
- 前端开发：能协助前端开发，解决跨域和接口对接问题；
- 数据库设计：能设计核心表结构，通过外键关联确保数据一致性；
- 测试验证：能编写功能测试用例，覆盖正常、异常和权限场景；
- 部署运维：能使用 Docker Compose 实现一键部署。
## 目标能力
- 后端开发：能设计高并发架构，具备性能优化和安全防护能力；
- 前端开发：能独立完成前端项目，具备响应式设计和组件化开发能力；
- 数据库设计：能优化查询性能，具备索引优化和查询优化能力；
- 测试验证：能进行自动化测试和性能测试，具备 CI/CD 集成能力；
- 部署运维：能使用 CI/CD 自动化部署，具备监控和日志分析能力。
## 差距
- 缺乏高并发场景经验，对性能测试和安全测试不熟悉；
- 缺乏响应式设计经验，移动端适配不完善；
- 缺乏索引优化经验，查询性能优化不熟悉；
- 缺乏自动化测试经验，测试效率有待提高；
- 缺乏 CI/CD 经验，部署依赖人工操作。
## 弥补方案
- 学习 JMeter 性能测试，阅读《高并发系统设计》；
- 学习 Vue 组件库，实践响应式设计；
- 学习 MySQL 索引原理，实践查询优化；
- 学习 JUnit 5 高级用法，实践自动化测试；
- 学习 GitHub Actions，实践自动化部署。
|
三、后续行动计划（3—6 个月）
1. 行动计划表
| 时间 |
行动 |
目标 |
验证方式 |
| 1 个月 |
学习 JMeter 基础 |
能编写简单压力测试脚本 |
完成 1 次压力测试 |
| 2 个月 |
学习 MySQL 索引优化 |
能优化核心查询 |
查询性能提升 50% |
| 3 个月 |
学习 GitHub Actions |
能配置 CI/CD 流水线 |
实现自动部署 |
| 4 个月 |
参与开源项目 |
学习大型项目协作方式 |
提交 1 个 PR |
| 5 个月 |
完善简历和作品集 |
准备实习求职面试 |
完成 3 次模拟面试 |
| 6 个月 |
实习求职或毕业设计 |
应用本次项目经验 |
获得实习 offer 或完成毕设选题 |
2. 行动计划示例
| # 后续行动计划
## 1. 毕业设计（如适用）
- 选题：选择更复杂的业务场景，应用本次项目经验；
- 技术：在本次项目基础上，增加高并发和安全防护；
- 文档：完善需求分析、系统设计和测试报告；
- 答辩：准备答辩 PPT 和演示视频。
## 2. 竞赛（如适用）
- 类型：参加软件设计竞赛，锻炼快速原型和演示能力；
- 团队：与不同专业的同学协作，学习跨领域沟通；
- 成果：完成可演示的作品，积累项目经历。
## 3. 实习求职（如适用）
- 简历：完善简历项目描述，使用 STAR 法则；
- 作品集：整理 GitHub、演示视频、文档链接；
- 面试：准备 30 秒、2 分钟、5 分钟三个版本的面试表达；
- 目标：投递 10—20 家公司，获得 3—5 次实习面试机会。
## 4. 开源贡献（如适用）
- 项目：参与与本次项目相关的开源项目；
- 方式：提交 Issue、修复 Bug、完善文档；
- 目标：提交 1—2 个被合并的 PR。
## 5. 持续学习
- 技术：学习 JMeter、Spring Security、响应式设计；
- 方法：阅读《高并发系统设计》《重构》《清洁代码》；
- 实践：通过个人项目或开源贡献应用新技术。
|
四、给未来团队的建议
如果你在团队中工作，可以给未来团队留下建议，帮助他们避免同样的问题。
1. 建议清单
| 维度 |
建议 |
原因 |
| 流程 |
需求基线冻结后再开发 |
避免后期大范围返工 |
| 流程 |
测试计划与需求分析同步 |
避免测试不充分 |
| 技术 |
使用 Docker Compose 部署 |
降低部署门槛，确保可复现 |
| 技术 |
引入 CI/CD 自动化部署 |
减少人工操作，提高效率 |
| 协作 |
明确分工，每模块唯一负责人 |
避免重复开发 |
| 协作 |
设计决策通过文档记录 |
减少口头误解 |
| 质量 |
定期代码审查 |
提高代码质量 |
| 质量 |
进行性能测试 |
评估系统性能 |
2. 建议示例
| # 给未来团队的建议
## 流程
1. 需求基线冻结后再开发，避免后期大范围返工；
2. 测试计划与需求分析同步进行，避免测试不充分；
3. 每日站会 + 任务看板，进度可视化。
## 技术
1. 使用 Docker Compose 部署，降低部署门槛，确保可复现；
2. 引入 CI/CD 自动化部署，减少人工操作，提高效率；
3. 进行性能测试，评估系统在高并发场景下的表现。
## 协作
1. 明确分工，每个模块有唯一负责人，避免重复开发；
2. 设计决策通过文档记录，减少口头误解；
3. 定期代码审查，提高代码质量。
## 质量
1. 核心功能开发前先写测试用例，确保测试覆盖；
2. 进行性能测试和安全测试，评估系统质量；
3. 建立缺陷管理流程，确保问题可追踪。
|
🤖 让 AI 帮你整理复盘素材
复盘的素材分散在 Git 提交、周报、AI 协作记录、测试报告和答辩反馈中。可以让 AI 先整理素材，再由你完成反思：
| 请先阅读当前项目的真实材料：Git 提交记录、项目周报、AI 协作记录、测试报告、缺陷记录和答辩反馈记录。
我要写项目复盘报告。
请遵守：
1. 只使用材料中能够确认的事实，不虚构经验和教训；
2. 按"做得好、做得不好、学到什么、下次改进"四个维度整理素材，每条注明依据（提交编号、周报日期、缺陷编号）；
3. 从材料中识别反复出现的问题和超出预期的做法；
4. 缺失的内容写为"【待确认：具体问题】"；
5. 列出仍需我回忆、讨论和确认的内容。
先说明你读取到的依据和缺失项，再整理复盘素材。
|
AI 只能整理素材，反思必须由你完成
AI 可以从提交和记录中找出"发生了什么"，但"为什么发生""下次怎样改进"必须来自你的真实思考。直接提交 AI 生成的复盘，无法回答答辩中的追问，也无法指导后续行动。
五、复盘报告模板
将以下模板复制到项目的 docs/项目复盘报告.md 或课程要求的文档中。
| # 【项目名称】项目复盘报告
## 1. 基本信息
| 项目 | 内容 |
| :--- | :--- |
| 项目名称 | 【填写】 |
| 团队成员 | 【填写】 |
| 我的角色 | 【填写】 |
| 项目周期 | 【填写】 |
| 交付版本 | v1.0 |
| 复盘日期 | 【填写】 |
## 2. 做得好
### 【做得好的方面 1】
- 做法：【填写】
- 效果：【填写，包含量化数据】
- 可复制：【填写，如何在下一个项目中复制】
### 【做得好的方面 2】
- 做法：【填写】
- 效果：【填写】
- 可复制：【填写】
## 3. 做得不好
### 【做得不好的方面 1】
- 问题：【填写】
- 原因：【填写】
- 影响：【填写】
- 改进：【填写，具体改进方向】
### 【做得不好的方面 2】
- 问题：【填写】
- 原因：【填写】
- 影响：【填写】
- 改进：【填写】
## 4. 学到什么
### 技术能力
- 【填写】
### 工程能力
- 【填写】
### 协作能力
- 【填写】
### 反思能力
- 【填写】
## 5. 下次怎样做得更好
### 流程改进
- 【填写】
### 技术改进
- 【填写】
### 协作改进
- 【填写】
## 6. 能力差距分析
| 能力维度 | 当前能力 | 目标能力 | 差距 | 弥补方案 | 时间范围 |
| :--- | :--- | :--- | :--- | :--- | :--- |
| 【填写】 | 【填写】 | 【填写】 | 【填写】 | 【填写】 | 【填写】 |
## 7. 后续行动计划
| 时间 | 行动 | 目标 | 验证方式 |
| :--- | :--- | :--- | :--- |
| 【填写】 | 【填写】 | 【填写】 | 【填写】 |
## 8. 给未来团队的建议（如适用）
- 【填写】
|
六、提交前自查
本节小结
完成复盘的核心是客观分析项目中的经验和教训，让经验可迁移，让改进可持续：
做得好 → 做得不好 → 学到什么 → 下次改进，配合能力差距分析和后续行动计划，确保持续成长。
完成本节后，你将拥有一份完整的项目复盘报告，记录经验、差距和后续行动。这也标志着第六篇的完成：你已经把课程项目从代码转化为可展示、可解释、可复用、可迁移的完整资产。
返回第六篇导读
返回上一节：整理简历