三轮自动代码评审，质量持续收敛

文章主旨： 通过一个实际项目的迭代修复过程，论证了代码评审（尤其是多轮结构化评审）是质量收敛的有效方法，强调“评审—修复—再评审”闭环的价值，以及后置四区评审方法论在发现深层和次生问题方面的优势。

关键要点：

• 多轮评审（三轮）能逐步收敛严重问题（3→1→0），建议问题（3→2→0），信息项（2→3→1）。
• 第一轮评审发现架构级问题（公共模块缺失、CDN降级、重复文件读取）；第二轮发现修复引入的细节问题（null处理、副作用位置、残留代码）；第三轮收敛到零。
• 后置四区评审框架（区内逻辑、输出侧影响、输入侧依赖、共享状态）比传统diff审查更能捕捉变更的涟漪效应。
• “修复即引入”是常态，需要将评审作为迭代闭环来应对。

内容结构：

1. 背景：Bug修复与架构决策失误
   • 原始问题：Word预览失败、Excel加载失败、行距过大、含大量表格的Word崩溃。
   • 根因：后端用python-docx解析文档并传递纯文本到前端，丢失样式并容易崩溃。
   • 修复方案：将文档渲染移到浏览器端（mammoth.js / marked.js），后端仅负责文件存储和API。
   • 涉及4个文件：两个前端页面、一个后端接口、一个新公共模块。
2. 第一轮评审：架构层面的深层问题
   • 发现3个严重问题：公共模块缺失（escapeHtml和renderFileContent在两个页面中重复定义）、CDN无降级、重复文件读取。
   • 评审结论：不通过，需修复严重问题。
3. 第一轮修复
   • 抽取公共模块 file-preview-renderer.js。
   • CDN降级机制：catch中实现双层fallback。
   • 修复重复读取：支持preloadedText参数。
   • 标记废弃API。
4. 第二轮评审：修复后的新问题
   • 发现1个严重（escapeHtml(null)渲染为"null"）和2个建议（marked.setOptions重复调用、markdown-renderer.js仍有重复escapeHtml）。
   • 评审结论：有条件通过（需修严重）。
   • 观察：修复本身会引入次生问题，但评审能像剥洋葱一样层层深入。
5. 第二轮修复
   • escapeHtml添加null防护。
   • marked.setOptions移到模块顶层并加守卫。
   • 删除markdown-renderer.js中的重复escapeHtml。
   • 补充learn.html对该模块的引用（连锁反应）。
6. 第三轮评审：收敛到零
   • 严重、建议均为0，信息项1个（其他页面遗留的inline escapeHtml，属于既有技术债务）。
   • 结论：通过。
7. 核心洞察
   • 一次评审不够，两次才收敛 —— 注意力先大后小。
   • "修复即引入"是常态，闭环应对。
   • 后置四区评审追问输出侧、共享状态等，能发现diff看不到的问题。
   • 方法论比工具更重要，结构化checklist能触发深度思考。
8. 结语
   • 代码评审应迭代收敛，三轮从3个严重到零缺陷。
   • 建议：修完一轮后别急着合并，再评一轮。

文章总结： 本文通过一个真实项目的实践案例，展示了多轮结构化代码评审（后置四区评审）如何系统性地发现并修复问题，最终实现质量收敛，强调了迭代评审和追问涟漪效应的有效性。

2000字吃透IPD产品研发！各阶段怎么落？看了就懂

了解更多

麦哲思科技任甲林

查看原文：三轮自动代码评审，质量持续收敛

文章来源：

麦哲思科技任甲林

扫码关注公众号