瀑布开发代码评审，放在哪一阶段

一、先说结论：代码评审不是“放不放”的问题，而是“怎么放”才能不拖垮项目

上周，一家做车载电子的客户找到我，他们技术副总裁说了这么一句话：“我们严格按照瀑布模型走，需求完了做设计，设计完了写代码，代码完了交给测试。现在上面要求加上代码评审，结果项目连续三个版本延期。是不是瀑布模型根本不适合搞代码评审？”

这个问题我至少被问过上百次。每次我都反问一句：“你们把代码评审放在编码完成之后、集成测试之前，所有人集中评审至少三天，是不是这么干的？”答案无一例外都是“对，你怎么知道？”

因为这就是绝大多数瀑布团队犯的第一个致命错误。他们把代码评审当成一个独立阶段的关卡，而不是嵌入编码阶段的质量活动。结果就是，编码名义上结束了，实则一堆缺陷被压到评审环节集中爆发，测试团队干等，项目延期，领导拍桌子骂人，团队开始抵制评审。

所以这篇文章要回答的核心问题不是“代码评审要不要做”，而是：在严格的瀑布流程里，代码评审应该嵌入到哪个阶段、以什么形式、在什么时机、对什么内容进行，才能既守住质量，又不拖垮进度？

下面我会基于我过去十二年服务过的企业在瀑布流程中落地代码评审的实际经验，拆解三种放置方案、四种错误做法、一个决策模型，以及一套可以直接套用到你团队里的实操指南。

二、先搞清楚场景：瀑布模型里，“编码阶段”到底在干什么

1. 教科书上的瀑布 vs 实际项目中的瀑布

教科书告诉你：需求确定后，进入设计；设计冻结后，进入编码；编码完成，交付测试。一个阶段结束后，下一个阶段才开始。看上去很美。

但在实际项目里，编码阶段从来都不是“写代码”一个动作。一个合格的编码阶段，内部至少包含以下几个子步骤：

• 详细设计消化（理解类图、顺序图、接口定义）
• 模块级编码实现（写代码本身）
• 单元测试（自测，确保自己写的函数能跑通）
• 代码自检（对照规范，快速过一遍自己的提交）

问题就出在最后一步。绝大多数团队把“代码自检”等同于“代码评审”。但自检是开发者自己的事，评审是至少第二个人参与的质量活动。两者截然不同，却经常被混为一谈。

2. 三种真实场景下的代码评审困境

过去几年，我接触过三类典型的瀑布团队，每一类对“代码评审放哪”的困惑都不同：

场景一：传统政务软件团队（40-60人规模的乙方公司）

项目周期6-8个月，需求确认后基本不做变更。他们的困境是：项目经理要求在提测前完成评审，但提测节点一拖再拖，因为评审过程发现的上一层级设计缺陷需要返工，而设计团队早已抽调到下一个项目里去了。

场景二：汽车电子嵌入式开发团队（甲方研发中心，200人以上）

功能安全要求极高，任何代码变更都需要追溯。他们的困境是：每次评审都像开听证会，一份800行的C代码片段评审耗时3小时，开发人员怨声载道。评审的记录厚得像病历本，但真正发现的有效缺陷并不多。

场景三：银行核心系统团队（混合型组织，百人以上）

采用“大瀑布套小迭代”的变体模式。他们的困境是：两个开发小组对“评审时机”的理解完全不同，A组在编码中期就邀请评审，B组坚持编码全结束后再评审。结果同一个项目的不同模块，评审节奏混乱，版本管理失控。

这三类场景的共同症结都是一样的：没有人从流程设计上明确回答“代码评审属于瀑布哪一阶段”，于是每个团队各凭直觉执行，结果就是混乱。

三、拆解四种常见的错误放置方式

在给出正确方案之前，我必须先把最常见的错误讲清楚。这些错误我在至少三十个团队里反复看到过。

1. 错误一：放在“编码结束后、集成测试前”，作为独立关卡

这是最普遍、也是最致命的一种做法。流程看起来是这样的：

1. 需求阶段 → 产出需求规格说明书
2. 设计阶段 → 产出概要设计、详细设计文档
3. 编码阶段 → 开发人员完成全部代码编写
4. 代码评审阶段（新增）→ 组织评审会议，集中审查代码
5. 测试阶段 → 评审通过后转交测试

为什么这种做法在瀑布模型里几乎注定失败？

第一，时间挤压效应。瀑布模型的阶段时间通常是固定的（比如编码阶段2个月，第58天必须交付），你在编码阶段末尾强行插入评审，实际上压缩的是编码时间本身。开发人员为了抢占时间，会把评审视为“不得不走的过场”。

第二，缺陷雪崩效应。当整个系统所有模块的代码都集中在3-5天内评审，评审者面对的是一个月甚至更长时间积累的代码量，大脑认知负载过高，越过阈值后，评审质量断崖式下降。

第三，测试空转效应。测试团队在评审期间处于等待状态，干耗工时。一旦评审发现的问题需要大规模返工，整个测试计划全盘打乱。

我见过最极端的案例：一家政务系统公司，对某个30万行代码的项目进行集中评审。评审持续了7个工作日，发现严重缺陷412个。返工又花了12天。测试推迟整整三周启动。最终项目延期两个月交付，客户罚款超过合同额的15%。

2. 错误二：把代码评审等同于设计评审的一部分

有些团队（尤其在汽车电子和军工领域）会把代码评审放在“详细设计评审”阶段，认为代码只是设计的延伸，一并审了更高效。

流程逻辑是：详细设计评审会上，设计文档和代码片段一起过。

这种做法的问题是混淆了审查目标。设计评审关注的是“做对的事”，接口定义是否合理？模块间耦合度是否达标？时序是否闭环？而代码评审关注的是“把事做对”，边界条件是否处理？空指针是否判断？循环终止条件是否正确？

把两件事放到同一个会议里，结果往往是：讨论设计问题花费大部分时间，代码细节一带而过。最后设计评审的质量没提升，代码评审也没真正执行。

我在给一家车载ECU供应商做咨询时，翻看他们的评审记录，发现超过80%的评审意见都是设计层面的（接口定义、状态机设计等），代码实现层面的缺陷几乎没有被记录。但后期测试阶段发现的崩溃类bug，追溯回去几乎全和代码实现有关。

3. 错误三：把评审前置到“每个开发人员提交后立即进行”

这听起来像是在模仿敏捷的CI流程，但在瀑布模型里直接套用，问题很多：

• 需求冻结后，编码顺序不是随机的。被依赖的底层模块先开发，上层应用后开发。你评审一个数据库DAO层代码时，根本无法评估它是否能满足上层业务逻辑的需求，因为没有上下文。
• 评审标准难以统一。项目初期评审宽松，后期严格，或者反过来，导致不同模块的代码质量方差极大。
• 评审者的时间被碎片化。高级工程师或架构师可能需要每天参加2-3次短评审，打断自己的开发节奏，得不偿失。

4. 错误四：不提评审，只靠测试倒逼质量

很多团队的做法更直接：不设专门的代码评审环节，让测试充当代码质量的唯一守门员。测试阶段暴露的所有bug，开发人员直接修。

这种做法的隐性成本是多少？

我统计过某个政府项目的数据，该项目不设代码评审，所有缺陷等待测试阶段发现。结果：

• 测试阶段平均每个缺陷修复耗时：4.7小时（含重现、定位、修复、回归）
• 同等难度缺陷在编码同期被评审发现并修复耗时：1.2小时/个
• 测试阶段发现的结构性问题（需要改动多个模块），平均修复耗时：21小时/个
• 编码同期评审发现的同类结构性问题，修复耗时：5.5小时/个

差异来自：测试人员需要额外的工作去重现和描述bug，开发人员需要切换上下文去修复“两个月前写的代码”，回归测试成本也需要叠加。

四、我的专业判断：三种有效放置方案及其原理

否决了错误做法后，下面是我基于实战反复验证过的三种有效方案。注意，这三种方案不是“三选一”的单选题，而是根据项目特征可以组合使用的工具箱。

1. 方案A：编码阶段内部的“模块完成走查”（适用于70%的瀑布型项目）

这是我推荐最多的方案，也是成功率最高的方案。

核心逻辑：不改变瀑布的宏观阶段划分，但在编码阶段的内部，引入“子阶段切分+子阶段走查”机制。具体做法是：

• 将编码阶段按模块粒度，切分为3-5个子阶段（每子阶段通常1-2周）
• 每个子阶段结束时，对该子阶段完成的模块进行一次“代码走查”（Walkthrough），时长控制在45-90分钟
• 走查参与者：模块开发人、另一位同组工程师（伙伴制）、以及必要时介入的架构师
• 走查聚焦于：接口实现正确性、关键算法逻辑、异常处理完整性、代码与详细设计的一致性
• 走查结果记录在项目管理系统（如PingCode）的对应任务下，不单独形成长篇评审报告

为什么这个方案在瀑布环境有效？

第一，不打破阶段边界。走查仍然在编码阶段内部完成，不新增独立阶段。项目经理的甘特图不需要大改，只需在编码阶段的任务分解结构（WBS）中加一项子任务。

第二，缺陷发现呈分散态而非集中爆发。把评审从“一锤子买卖”变成了“分批进行”。每一批次的评审量可控（通常在500-1500行代码），评审者认知负载合理，缺陷发现率高。

第三，开发者反馈及时。一个模块走查结束，开发的记忆还是热的，返工成本极低。不用像两个月后翻回来看自己写的代码那样痛苦。

第四，对测试团队友好。测试团队可以在第一个子阶段走查通过后就开始介入做测试用例设计，不需要等待全部编码完成。

以PingCode为例，我们服务过的客户中，采用这种方案的典型配置是：

• 在PingCode Project中，将编码阶段拆分为多个“子迭代”（Sub-sprint），每个子迭代对应一个模块开发周期
• 需求下挂载的任务分为“开发任务”和“走查任务”两类
• 走查任务有明确的完成标准（如检查清单上的12项全部确认），完成后才能流转到下一个子阶段
• 走查意见直接作为任务评论记录，与代码关联，形成追溯链

2. 方案B：设计阶段末尾的“关键接口预评审”（适用于高风险项目）

这个方案适用于对功能安全有严格要求的项目，比如汽车电子ISO 26262、航空DO-178C、医疗器械IEC 62304等标准下的开发。

核心逻辑：在设计阶段即将结束、编码阶段即将开始时，对关键模块的接口设计及对应的伪代码/核心算法片段进行一次“预评审”。这时候代码还没大规模写，但核心逻辑的框架已经可以在详细设计文档中体现。

具体操作方式：

1. 在详细设计评审阶段末尾，增加一项“关键接口预评审”议程
2. 评审对象：关键算法伪代码、复杂状态机定义、数据流处理逻辑、涉及安全的控制逻辑
3. 评审参与人：设计师、未来负责该模块的开发人员、安全工程师（如适用）、架构师
4. 评审产出：对伪代码的逻辑验证意见，以及对后续编码阶段补充性评审的触发条件

这不算“把代码评审和设计评审混淆”吗？

不算。区别在于评审的产出物性质。设计评审评审的是“设计文档及附图”，关键字是“设计”。这里的预评审，评审的是“伪代码及算法骨架”，关键字是“实现逻辑”。前者回答“该做什么”，后者回答“该怎么做”。在功能安全标准里，这是明确要求的两个不同步骤。

我服务过的一家汽车Tier 1供应商采用这种方式后，核心算法模块的后期缺陷密度下降了约40%。原因是很多逻辑层面的问题在设计到编码的交接阶段就暴出来了，而不是等到代码写完才惊觉“原来这么设计实现起来有大坑”。

3. 方案C：提测前的“自动化过滤 + 人工抽查”（适用于工期紧张或低风险项目）

理想状况下我推荐方案A。但现实中确实存在这样的场景：

• 项目排期极度紧张，连额外的走查时间都很难抠出来
• 功能风险较低（如内部管理系统的非核心模块）
• 团队缺乏成熟的评审经验，强行推完整走查可能导致抗拒和形式化

这时候可以采用方案C，作为一个“退而求其次但好过完全没有”的选择。

核心逻辑：在提测前设置一个轻量级质量关卡。但这个关卡不是靠人力密集型评审，而是靠两件事：

1. 自动化静态检查全覆盖：通过静态代码分析工具（如SonarQube、PCLint、Checkstyle等）自动扫一遍所有提测代码，把圈复杂度过高、潜在空指针、资源未释放、编码规范违规等机械性问题拦截下来。
2. 人工抽查聚焦高风险模块：从系统中挑选出高风险的3-5个模块（判断标准：核心业务逻辑、频繁变动的模块、新加入团队成员的代码），对这些模块进行人工走查，其余模块只做自动化检查。

这个方案的注意事项：

• 必须坚持“自动化检查不通过，不允许人工评审介入”，否则人工总会偷懒忽略自动化结果
• 高风险模块的人工抽查必须有时间控制，建议每个模块不超过60分钟
• 对于低风险模块，应建立“自动化检查通过即视为评审通过”的明确标准，不可临时变卦要求追加深层评审

五、实战案例：一个200人团队如何从“评审灾难”走到“评审常态化”

这里我讲一个具体的案例，来自我曾深度参与的一个项目。这是一个金融科技公司的核心系统重构项目，团队规模约200人，分布在三地。采用标准的瀑布流程：需求3个月，设计2个月，编码5个月，测试3个月，累计周期13个月。

1. 项目初期的“评审灾难”

项目启动后的首次尝试：按照上级要求，编码阶段结束后安排为期5天的集中代码评审。评审范围覆盖核心交易模块、风控模块、清算模块，待审代码量约18万行。

问题清单：

• 5天内，30名高级工程师被抽调参与评审，原计划的项目技术支持工作全面暂停
• 累计发现缺陷1436个，其中严重缺陷281个，需要返工的模块有12个
• 编码阶段名义上第5个月底结束，实际上第6个月中旬还在修评审发现的问题，整整延迟17天
• 测试团队原计划第6个月第一天接手，结果闲置等待2周以上
• 部分开发人员反馈：“评审太晚了，有些逻辑我写完都快忘了，现看懂再评审，效率极低”

这是典型的“错误一”症状。团队已经踩到了最大的坑里。

2. 调整方案：转向“模块完成走查”模式

我给这个团队的建议很明确：立刻切换到方案A，在接下来的版本中实施“编码阶段内部子阶段走查”。具体执行步骤：

（1）拆分编码阶段：将5个月的编码阶段拆分为6个子阶段，每个子阶段约3-4周，对应2-3个关联模块的开发和走查。

（2）确定走查标准：制定一份12项的走查检查清单，涵盖接口实现、异常处理、边界条件、日志记录、安全校验五个维度，走查者按清单逐项确认。

（3）分配走查角色：每个模块指定一名“走查伙伴”（同组另一位开发），加上模块开发人和一名技术负责人，每次走查不超过3人。

（4）时间控制：每次走查不超过90分钟，每个模块单次走查不超过1500行代码，超额部分拆分期次。

（5）工具支持：全部走查任务在PingCode上创建、跟踪、关联到对应需求。走查意见以评论形式记录到具体任务中，可以追溯到代码commit。

3. 实施效果

第二个版本（12万行新增代码）采用新方案后的对比数据：

最重要的变化不是数字，而是评审从项目的瓶颈变成了项目的加速器。因为子阶段的走查让需求理解偏差在编码早期就被纠正，避免了整个模块写完才发现方向搞错的悲剧。测试团队的压力也大幅减轻，因为他们接手的代码基本盘已经经过了多轮轻量验证。

六、不同场景下的行动建议与取舍

1. 如果你的项目符合以下特征，优先选择方案A（模块完成走查）

• 项目周期3个月以上，编码阶段至少6周
• 团队成员在5人以上，模块之间有一定耦合但可拆解
• 管理层对“评审”持开放态度但不接受增加独立阶段
• 测试团队处于等待状态的时间较长

行动清单：

1. 在项目计划的编码阶段WBS中，明确增加“子阶段X走查”任务项
2. 制定15项以内的走查检查清单，初期可由架构师拟定，迭代2-3次后固化
3. 使用PingCode或其他项目管理工具创建“走查任务”类型，关联到需求条目
4. 明确走查完成标准：检查清单全部确认通过 + 发现的问题已修复或记录为技术债务
5. 前三次走查建议邀请有经验的引导者（可以是外部顾问或技术负责人）主持，培养团队惯例

2. 如果你的项目有严格的功能安全合规要求，方案B（关键接口预评审）不能省略

这条建议不需要太多讨论，因为功能安全标准（如ISO 26262功能安全等级ASIL C/D）对代码评审有明确的形式化要求。你需要做的不是讨论“要不要”，而是确保预评审的深度和记录形式满足认证审核的要求。

特别注意：

• 预评审的记录必须可追溯，包括参与者、评审日期、评审项、发现的问题、问题关闭状态
• 对于ASIL D级别的模块，预评审后的编码走查也不可豁免，两者是叠加关系而非替代关系

3. 如果你不得不接受极紧的工期，方案C（自动化过滤 + 人工抽查）是最后的防线

这时候需要做一个清醒的取舍：你接受的是质量风险的上限提升。

必须做到的三件事：

1. 自动化检查的质量门禁必须硬性执行：静态分析工具设置阻断级规则，不通过则不允许进入人工评审环节
2. 高风险模块的选择不能由开发人员自己说了算，应由技术负责人根据模块的变更频次、影响范围、业务重要性来指定
3. 项目复盘时必须对比该版本的测试阶段缺陷泄露率，如果显著高于历史基线，下个版本必须调整策略，加大人工走查覆盖

七、落地过程中的四个关键权衡

1. 评审深度与评审速度的平衡

很多团队在这个问题上走向极端。要么评审过浅，沦为“代码有没有注释”的风格检查；要么评审过深，每行代码逐字逐句朗读分析，一个模块评审四个小时。

我的经验判断标准是：一次有效的走查，应该覆盖大约800-1500行代码，耗时45-90分钟，平均每行代码的评审投入在3-5秒。太快的往往是漏网之鱼，太慢的通常说明评审者掉进了细节漩涡或者模块设计本身有重大问题。

实操建议：给走查设定时间盒（Timebox），例如：本次走查90分钟，前半段聚焦接口和算法（全局视角），中间段抽查异常处理（风险视角），后半段确认检查清单（合规视角）。到点即停止，未覆盖的模块留到下次走查。这个硬性约束会倒逼评审者抓大放小。

2. 评审覆盖率的选择：100% vs 关键模块

方案A和方案B都涉及一个核心选择：是所有模块都评审，还是只评审高风险模块？

我的建议是：

• 首个版本或首次引入评审流程：尽量做到100%覆盖，目的是建立评审文化和团队参考基线
• 第二个版本起：可以根据模块的风险等级分类处理。高风险模块（核心交易、安全认证、数据加密、新架构的首次应用）保持每次走查；中风险模块（常规业务逻辑）每2-3个子阶段走查一次；低风险模块（CRUD页面、配置脚本、工具类代码）仅做自动化检查，只有自动化告警时才触发人工复查
• 任何时候，对于团队中新成员的代码，前三个月必须100%走查（这既是质量保障，也是能力传递的有效手段）

3. 谁来做评审者：伙伴制 vs 专家制

一种做法是同组成员互相评审（伙伴制），另一种是让架构师或技术负责人评审所有人的代码（专家制）。

伙伴制的优势：评审者了解模块的业务上下文，评审效率高；评审者和被评审者地位对等，心理负担小，意见交流更充分。

伙伴制的劣势：两个人可能有同样的认知盲区，发现不了根本性的设计偏差。

专家制的优势：架构师能从全局视角发现局部设计偏差，避免模块内部的“局部最优”导致系统级的“全局次优”。

专家制的劣势：架构师是瓶颈，一个项目的几十个模块全靠一个人审，效率极低且不可持续。

我的混合建议：常规走查采用伙伴制，每3-4次走查穿插一次专家参与。专家参与时重点审视跨模块接口、架构合规性、技术债务积累趋势，不介入具体函数级的逻辑细节。

4. 评审记录的形式化程度

这是另一个容易走极端的点。一边是想起来就口头说两句、没有任何记录；另一边是要求填写五页A4纸的评审报告，格式比内容还重要。

我的经验标准：记录量和项目风险等级成正比，和团队对评审流程的熟悉度成反比。

初期（导入评审的前2-3次）：记录可以详细些，包括检查清单逐项确认、发现问题的描述、修复方案记录。目的是建立团队对评审流程的共识。

中期（流程稳定后）：记录精简为三类：检查清单确认项 + 已修复问题简述 + 标记为技术债务的问题编号。每条记录不超过3行。

高合规要求项目：按认证标准的最低记录要求执行，不额外增加。能放在PingCode任务评论里的就不单独写成文档。

八、关于工具和流程的一些实操观察

我从2018年开始使用PingCode辅助团队管理Scrum和瀑布混合型项目，发现一个很有意思的现象：很多团队评审失败不是评审能力的问题，是流程可视性不足的问题。

具体来说：

• 评审任务的创建没有纳入项目WBS，导致项目经理排期时不分配时间，评审员靠“自觉”挤时间
• 评审意见散落在邮件、企业微信、口头对话中，没有和代码版本、需求条目关联，事后无法追溯
• 评审的状态流转不透明，不知道哪些模块审了、审到什么程度、有没有遗留问题没处理

在PingCode的落地实践中，我们通常这样配置来解决上述问题：

1. 工作项类型自定义：在项目中新增“代码走查”工作项类型，与“需求”“任务”“缺陷”并列。走查工作项绑定到对应的用户故事或需求条目下。
2. 状态流转：走查工作项的状态流设置为“待走查 → 走查中 → 走查通过/有遗留 → 遗留已解决 → 已关闭”。每一个状态变化都触发通知到相关人。
3. 与代码关联：走查工作项的描述中关联到代码仓库的Pull Request或Commit ID，评审意见直接作为工作项评论，支持@提及相关人员。
4. 度量面板：通过项目报表查看走查覆盖率和缺陷发现趋势。例如：本周走查覆盖了哪些模块、发现了哪些类型的问题、问题关闭率等。

值得注意的是，工具只是放大器。一个本身流程混乱的评审方案，用了再好的工具也不会变好，只会让混乱更效率化地扩散。所以回到本文的核心：先把评审放在瀑布模型的正确位置，再考虑用什么工具来执行这个位置上的操作。

九、总结：记住三个核心判断

写到这里，我想要你记住的不是哪套具体的流程步骤，而是三个可以用来做判断的原则。

1. “评审本质是编码活动，不是测试活动”

代码评审的产出是“更高质量的代码进入下一阶段”，而不是“验证代码是否符合需求”。所以它天然应该和编码阶段捆绑，而不是和测试阶段捆绑。把评审放到编码阶段内部，是回归它的本质属性。放到编码和测试之间作为独立关卡，是人为制造流程断层。

2. “分散评审战胜集中评审”

集中评审在瀑布模型里的失败率极高，根本原因不是人不够好，而是人脑的认知负载有限。一次评审超过1500行代码或超过90分钟，有效缺陷发现率会急剧下降。分散评审不仅是进度友好型的做法，也是认知科学告诉我们的正确做法。

3. “没有一种方案适用于所有项目”

方案A适用于大多数项目，方案B是高合规行业的必选，方案C是底线防守。你需要根据项目的合规要求、工期压力、团队成熟度来做判断，而不是照搬某种“最佳实践”。

最后说一句我经常对客户讲的话：代码评审不是给你的项目增加负担，而是把已经存在的、只不过延迟到测试阶段才爆发的负担，提前分摊到可控的节点上去。如果从这个视角看，评审就不再是“多出来的工作”，而是“早晚要做、早点做更划算的工作”。

下一步你可以做的：

1. 回顾你当前项目的瀑布阶段划分，找到编码阶段在WBS中的位置
2. 对比本文的三种方案，判断你的项目最接近哪一类特征
3. 选择一个方案在下一个版本试点，哪怕只是把集中评审拆成两次子阶段走查
4. 三个版本后，用测试阶段缺陷泄露率作为核心指标，评估是否需要继续调整策略