代码审查时最该关注的不是语法，而是这五个“坏味道”
“这段代码能跑，但总觉得哪里不对劲。”如果你在审查代码时有过这种感觉，说明你已经嗅到了代码的坏味道。作为软件测试从业者，我们往往比开发人员更早感受到坏味道带来的痛苦——一个看似简单的变更导致回归测试大面积失败，一个边界值测试要绕过层层嵌套的条件才能命中，一段重复逻辑让测试用例本身也陷入复制粘贴的泥潭。语法错误编译器会告诉我们，但真正的质量隐患藏在那些不会报错、却让系统日渐臃肿的坏味道里。本文从测试视角出发，梳理代码审查中最该关注的五个坏味道，帮助你在评审中更早地发现风险，减少返工。
一、重复代码：测试用例膨胀的元凶
重复代码是最容易识别、却最容易被容忍的坏味道。同一个验证逻辑出现在三个接口里，同一段价格计算被复制到订单、退款、对账模块中，开发人员常常因为“时间紧”或“怕影响已有功能”而选择复制粘贴。但对测试人员来说，重复代码意味着三倍的风险：你需要为每一处重复编写相似的测试用例，而一旦业务规则变化，修改遗漏任何一处都会导致线上事故。
审查时，不要只看当前文件。当发现一段逻辑与另一处高度相似时，立刻追问：“这两处真的需要独立存在吗？”如果是同一个类内的重复，可以建议提取公共方法；如果是兄弟子类间的重复，应把公共逻辑上提到父类；如果是完全不相关的类出现重复，则需要提炼出独立的工具类或服务。从测试角度，你可以用一句话推动重构：“这段逻辑如果改了，你能保证所有复制的地方都同步修改吗？”这个问题往往能让开发人员意识到风险。
重构后的代码不仅减少了测试用例数量，更重要的是让业务规则有了唯一出口。当价格计算逻辑只存在于一个方法中时，你只需要围绕这个方法设计等价类和边界值，而不必担心某个角落还藏着另一套算法。
二、过长方法：理解成本与测试盲区
一个方法几百行，从参数校验、业务处理到日志打印全塞在一起，这是测试人员最头疼的审查对象。过长方法的问题不是“代码多”，而是“职责多”。当你试图为它设计测试用例时，会发现很难孤立地验证某一环节：想测异常处理，必须先构造正常流程的前置条件；想覆盖某个分支，要读懂前面八十行的上下文。
审查这类代码时，可以关注三个信号：方法名中出现了“And”或“Or”（如 validateAndProcess），说明它做了不止一件事；方法体内有明显的注释分段（如“//第一步：校验参数”），说明开发人员自己也在用注释划分职责；存在大量临时变量在不同阶段被反复赋值，说明这些阶段本可以独立成方法。
推动重构的策略是“提取方法”。建议开发人员按照“校验-处理-组装返回”的结构拆解，让每个小方法只做一件事。对测试人员来说，这带来了直接的好处：你可以为每个小方法单独设计单元测试，组合起来又能覆盖完整流程，测试金字塔的底层会更稳固。同时，当某个环节出现缺陷时，定位也更快——你不会在一个五百行的方法里逐行排查，而是直接锁定对应的小方法。
三、数据泥团：被忽视的边界风险
总是成对出现的参数，比如姓名和身份证号、经度和纬度、起始日期和结束日期，如果它们在多个方法签名中反复同时出现，就形成了数据泥团。这种坏味道在动态类型语言中尤其容易被忽视，因为开发人员习惯了传递多个独立参数，而不是封装成对象。
对测试人员而言，数据泥团隐藏着严重的边界风险。当起始日期和结束日期作为两个独立参数传递时，校验逻辑往往分散在各个方法中，有的方法校验了起始早于结束，有的忘了校验，有的甚至允许结束早于起始。你不得不在每个用到这对参数的接口里重复测试日期顺序的边界情况，而一旦某个接口漏测，数据混乱就会流入数据库。
审查时，如果发现一组数据在三个以上方法的参数列表中出现，就应该建议封装成值对象或数据类。例如将起始日期和结束日期封装为“DateRange”类，并把“起始不能晚于结束”的校验逻辑内聚在这个类中。这样一来，所有使用DateRange的方法都不再需要重复校验，你的测试也只需要围绕DateRange的构造器设计边界用例，而不必在每个业务接口中重复覆盖。
四、发散式变化与霰弹式修改：回归测试的噩梦
这两个坏味道是一体两面，都指向“修改成本高”的问题。发散式变化是指一个类因为不同原因被频繁修改，比如订单类今天因为支付规则改、明天因为物流规则改，说明这个类承担了太多职责。霰弹式修改则相反，一个业务规则的变更需要同时修改七八个类，比如增加一种优惠类型，要改动订单类、用户类、优惠券类、结算类等。
测试人员对这两种坏味道的感知最直接：发散式变化意味着每次修改都可能引入不相关的副作用，你的回归测试范围被迫扩大；霰弹式修改意味着开发人员很容易遗漏某个修改点，导致线上出现“改了但没完全改”的缺陷。
审查时，可以关注类的修改历史。如果一个类最近十次提交涉及了三个以上不同的业务模块，就是发散式变化的信号；如果一个需求改动涉及了五个以上的文件，就要警惕霰弹式修改。推动重构的方向是让类职责单一：把支付相关逻辑移入支付类，把物流相关逻辑移入物流类。对于霰弹式修改，则需要把散落各处的相同变化原因的逻辑集中到一个类中。重构后，你的回归测试策略会更清晰：修改支付逻辑时，只需重点回归支付模块，而不必把订单、物流全部跑一遍。
五、过度亲密与中间人：测试桩的复杂度陷阱
当两个类互相访问对方的私有成员，或者一个类的一半方法都在转发调用另一个类时，就出现了过度亲密和中间人坏味道。这种设计会让单元测试变得异常困难：你想测试A类，却发现必须实例化B类并设置一堆内部状态；你想Mock掉B，却发现A对B的调用深入到了私有细节，Mock无法覆盖。
审查时，如果看到一个类频繁使用另一个类的Getter来获取内部数据再做计算，这就是“依恋情结”的信号——这段计算逻辑更应该放在数据所属的类中。如果看到一个类的大部分方法只有一行代码，直接调用另一个类的同名方法，那这个类很可能只是无意义的中间人，可以移除。
推动重构的建议是“搬移方法”：把依赖其他类私有数据的方法搬移到那个类中，让数据和操作它的行为待在一起。对于中间人，可以直接让调用方绕过它访问真正的服务类。重构后，你的单元测试不再需要构造复杂的对象图，Mock策略也更简单直接，测试用例的可维护性会明显提升。
代码审查不是语法检查，而是设计质量的集体守护。作为测试人员，你的优势在于对变更风险和测试成本的敏感。当你从这五个坏味道的角度审视代码时，你提出的就不只是“这里有个Bug”，而是“这种写法会让后续测试越来越难维护”——这恰恰是开发人员最容易接受的重构理由。下一次代码评审会上，试着不再沉默，用坏味道的语言描述你看到的问题，你会发现团队的质量对话进入了更深的层次。