PHP 怎么复盘

本文目录导读：

1. 场景一：对“代码质量”进行复盘（Code Review / 重构）
2. 场景二：对“线上故障（Bug/事故）”进行复盘
3. 场景三：对“业务逻辑”进行复盘
4. 场景四：对“项目迭代 (Sprint)”进行复盘
5. 高效复盘的工具与操作（实操指南）
6. 复盘最重要的三个底层原则

在 PHP 开发中进行“复盘”（Retrospective），通常是指对一段代码、一个项目、一次故障或一个开发周期进行回顾和总结，提炼出可以优化的地方,避免重复犯错。

根据你具体想复盘的对象，方法会有所不同，以下是 PHP 开发中最常见的四种复盘场景及具体操作指南：

---

对“代码质量”进行复盘（Code Review / 重构）

这是日常开发中最频繁的复盘，目的是让代码更健壮、更易维护。

复盘 Checklist（清单）：

1. 检查语法与基础规范：
   • 是否使用了 PHP-CS-Fixer 或 PHP_CodeSniffer 来统一代码风格（PSR-12）？
   • 是否有未使用的变量、死代码或冗余的注释？
2. 安全性盲区（重中之重）：
   • SQL 注入：是否直接拼接了 SQL？$_GET/$_POST 是否通过 PDO 预处理参数绑定？
   • XSS 攻击：输出到 HTML 的数据是否使用了 htmlspecialchars() 转义？
   • CSRF 防护：表单提交是否有 Token 验证？
   • 文件上传：是否验证了 MIME 类型？文件是否存放于 Web 根目录之外？
3. 性能隐患：
   • 是否在循环中执行了 SQL 查询（N+1 问题）？是否使用了懒加载或预加载（with()）？
   • 是否有不必要的 session_start() 或耗时的第三方 API 调用？
4. 可读性与设计模式：
   • 函数是否超过 50 行？是否过于复杂（圈复杂度）？
   • 是否存在违背 SOLID 原则的“上帝类”或“长函数”？
   • 是否使用了魔术方法（__set/__get）导致隐性问题？

复盘方法：使用静态分析工具（如 PHPStan 或 Psalm）进行扫描，对实操作“一票否决”,其余按优先级修复。

---

对“线上故障（Bug/事故）”进行复盘

这是运维和生产环境中最重要的复盘,目标是找出根因。

复盘五步法（5 Whys 分析法）：

1. 当时发生了什么？（时间线还原,精确到分钟）
2. 为什么没有提前被发现？（测试用例缺失？还是监控告警阈值设置不合理？）
3. 根因是什么？（是逻辑错误、环境差异，还是第三方服务抖动？）
4. 影响范围多大？（影响了多少用户？数据是否丢失？）
5. 如何防范再次发生？（自动化测试、新增日志监控、代码评审关卡）。

重点建议：如果在生产环境出现致命错误，复盘时不要急于写补丁，先花时间查看 error_log 和堆栈追踪,确保完全理解原因后再动代码。

---

对“业务逻辑”进行复盘

这是产品层面,主要看接口返回是否符合预期。

复盘要点：

• 状态码与异常：接口是否只返回了 200？是否按规范返回了 2xx/4xx/5xx？错误信息是否过于暴露（泄露了服务器细节）？
• 事务一致性：涉及多表更新时，是否使用了 DB::beginTransaction()？更新失败时能否完整回滚？
• 并发场景：在高并发下（如秒杀），是否存在超卖问题？是否使用了 Redis 锁或乐观锁？

---

对“项目迭代 (Sprint)”进行复盘

这是敏捷开发中的 Rerto 会议,偏向团队协作和流程。

复盘三连问：

1. 做得好的：哪些技术栈（如 Laravel 的队列）极大地提升了效率？
2. 可以改进的：预估工时是否严重不准？跨部门沟通是否有内耗？
3. 下个迭代的承诺：至少要完成一件具体的事来提升开发体验（如引入 ApiDoc 工具）。

---

高效复盘的工具与操作（实操指南）

如果要在本地进行代码复盘,建议按以下步骤执行：

第一步：利用 Git 进行历史回溯

# 查看最近提交的代码差异
git log --oneline -5
git show <commit_id> --stat
# 查看某个函数文件的修改历史
git log -p app/Http/Controllers/UserController.php

第二步：安装静态分析工具（强制体检）

# 在项目根目录执行
vendor/bin/phpstan analyse src --level=6
vendor/bin/psalm --show-info=true

这些工具能帮你抓出 90% 的潜在逻辑错误和未定义变量。

第三步：使用 Profiling 工具分析性能 不要只靠感觉,用数据说话：

• Xdebug + QCacheGrind：生成调用图,看哪个函数的执行时间最长。
• Laravel Telescope（Laravel 项目）：查看每次请求的 N+1 问题和耗时。
• Tideways：分析 API 接口的响应时间瓶颈。

第四步：建立“问题日志”文件 建议在项目根目录创建 ARCHITECTURE.md 或 DECISIONS.md,记录下：

“2023年X月X日，因为未启用 opcache.preload 导致内存占用过高，解决方案：部署时需重启 PHP-FPM，后续建议：引入 Deployer 部署脚本。”

---

复盘最重要的三个底层原则

1. 不指责个人，只针对流程：复盘是“对事不对人”，寻找系统性的漏洞（如缺少测试）,而不是责怪开发者粗心。
2. 时间盒管理：复盘决议最好设置在 1-2 小时内完成，重点在于得出可执行的 TODO 列表,而不是无休止的讨论。
3. 追踪结案：如果复盘只产出“下周一整改”，那就是白复盘，必须将其拆解为 Jira Task 并分配给负责人。

你现在具体想复盘哪个方面？ 是想查一个难缠的 Bug，还是想优化一段老代码的性能？如果你描述一下具体场景,我可以给出更细化的指令。