函数要不要拆，先看它是不是同时在做几件事，而不是先看行数。一段两百行的纯映射逻辑，如果只有一个职责、命名准确、改动时不需要通读全文，硬拆成七八个只被调用一次的小方法，读的人反而要在文件里来回跳。反过来，一个六十行的方法里混着参数校验、业务计算、写库和发通知，还夹着注释分块，那它就是该拆的。拆的目标是可读、可测、可改，不是把行数压到某个数字以下。
判断是否值得拆，通常看四个信号：存在注释分隔的独立代码块、混用了不同抽象层级、改一处必须通读全方法、无法用一句准确的话命名这个方法。确认后，先用现有测试或补一层行为测试兜住，再按注释块和空行标出接缝，一次只抽一个“一件事”的方法，参数尽量走形参而不是靠成员变量传递。抽完用原有测试、调用点检查和代码评审验证行为未变；如果这段落在热路径、事务边界、反射或框架约定依赖的方法签名上，先不动或只做不改变语义的机械抽取。
先确认当前场景和目标
动手前需要确认三件事：这段代码有没有测试能覆盖、它被多少地方调用、它是否处在不能随意改签名的位置（比如被反射调用、被框架按注解扫描、是某个接口的实现）。没有测试覆盖就先补一层行为测试，或者退一步，这一轮只做不改逻辑的机械抽取，把语义改动留到下一次。
可以对照下面几条判断是否属于“该拆”的场景：
- 方法里有明显的分块注释，例如“校验参数”“计算金额”“写日志”，每块都能独立命名。
- 同一个方法里既在做业务规则判断，又在做字符串拼接、日期格式化、异常包装，抽象层级不一致。
- 改一个分支要先把整个方法读完，怕漏掉后面某处对同一变量的二次赋值。
- 方法名只能写成
handleOrderAndNotify这种带 And 的形式，说明它至少有两个职责。 - 想给其中一段写单元测试，只能把整个方法连同它的副作用一起跑。
不太适合硬拆的场景也要先认出来：纯数据映射的大 switch、配置表的展开逻辑、状态机的分支集合、代码生成产物、只跑一次的一次性脚本。这些代码长是正常的，拆开只会让对应关系变散。如果逻辑本身是状态流转或规则表，更合适的做法是改成表驱动，而不是切成十几个小方法。
按这个顺序处理
- 先固定行为。有测试就跑一遍记为基线；没有测试，就对几个典型输入手动记录输出、异常消息、日志顺序和写库结果，作为改造后的比对依据。
- 标出接缝。把注释块、空行、临时变量最后一次被使用的位置标出来，这些就是天然的切分点。切分点通常出现在“一段计算结束、结果赋给一个变量”的地方。
- 从最独立的一块开始抽。顺序上建议先抽不依赖方法内部中间状态、输入输出清晰的块，例如参数校验、格式化、单条规则判断。抽的时候不要顺手改逻辑，不要把循环改成 stream，不要调整计算顺序，这一轮只搬家。
- 按意图命名，不按实现命名。用
validate、calculateTotal、shouldNotify这类动词加业务词，避免doPart2、handleInner。 - 处理参数。只在两个分支里用到的布尔参数，通常拆成两个方法；参数超过四五个时考虑引入参数对象；抽出来的方法如果只读一个成员变量，要判断这个状态是否真的该留在类上。
- 清理残留。抽完检查是否留下未使用的临时变量、只被调用一次的私有方法、重复的判空。小步提交，每一步都能编译通过、测试通过。
下面是一个通用骨架示例，语言无关，重点是拆分粒度和顺序，不要一次抽太细：
// 改造前：一个方法里做了四件事
public void handle(Order order) {
// 1. 校验
if (order == null || order.getItems().isEmpty())
throw new IllegalArgumentException("empty order");
// 2. 计算
BigDecimal total = BigDecimal.ZERO;
for (Item item : order.getItems()) {
total = total.add(item.getPrice().multiply(BigDecimal.valueOf(item.getQty())));
}
if (order.isVip()) total = total.multiply(VIP_RATE);
// 3. 落库
repo.save(order, total);
// 4. 通知
if (total.compareTo(NOTIFY_THRESHOLD) > 0) notifier.send(order);
}
// 改造后：主流程只保留步骤，细节下沉
public void handle(Order order) {
validate(order);
BigDecimal total = calculateTotal(order);
repo.save(order, total);
notifyIfNeeded(order, total);
}
private void validate(Order order) {
if (order == null || order.getItems().isEmpty())
throw new IllegalArgumentException("empty order");
}
private BigDecimal calculateTotal(Order order) {
BigDecimal total = BigDecimal.ZERO;
for (Item item : order.getItems()) {
total = total.add(item.getPrice().multiply(BigDecimal.valueOf(item.getQty())));
}
return order.isVip() ? total.multiply(VIP_RATE) : total;
}
private void notifyIfNeeded(Order order, BigDecimal total) {
if (total.compareTo(NOTIFY_THRESHOLD) > 0) notifier.send(order);
}注意示例里的计算循环保持原样，只把阈值和费率提成常量，这样行为差异最小。抽取顺序上是先抽校验，再抽计算，最后抽通知，每一步都能单独提交和回退。
改完后怎么验证
验证的核心是“行为没变”和“确实更好读”，这两件事要分开确认。
- 跑测试对比。原有测试全部通过；如果没有测试，用改前记录的几组输入重跑，对比返回值、异常类型和异常消息是否一致。
- 确认副作用顺序。日志打印顺序、写库和发消息的先后关系、事务提交时机，改前改后应当一致。这一步在拆分含副作用的方法时最容易出问题。
- 检查调用点。搜索被抽取方法的原调用位置，确认没有遗漏更新；确认没有留下未被调用的私有方法或未使用的参数。
- 做一次“去注释阅读”。把新方法里的注释遮住，只看方法名和主流程，能不能说清这段代码在做什么。如果还要靠注释解释，名字或粒度大概率还需要调整。
- 检查抽象层级。主流程方法里不应再出现字符串截取、日志格式化这类细节；被抽出的方法里也不应再跨多层调用业务规则。
- 借助工具辅助。用 IDE 的抽取方法、查找未使用声明、参数数量提示等静态检查作为补充，但不要以工具告警数量作为是否重构完成的判断标准。
预期信号是：主流程方法能一眼读出步骤顺序，单个方法可以脱离整体被单独测试，修改某条规则时只需打开一个方法。如果拆完发现方法数量翻了几倍、阅读时要在文件里上下跳十几次，说明粒度切得太碎，应该合并回去一部分。
容易忽略的边界
- 共享可变状态。原方法里多个代码块读写同一个局部变量时，直接抽成方法会变成参数传递或成员变量，后者会引入并发和生命周期问题。优先用返回值串起来，不要把中间状态提到字段上。
- 事务、锁和注解位置。被抽出的方法如果涉及事务注解、加锁、重试、切面增强，要先确认注解应该留在调用方还是新方法上。机械地把带注解的代码块搬走，容易让事务范围变大或失效。
- 性能敏感路径。方法抽取本身通常不改变复杂度，但如果拆出了对大对象的复制、额外的集合遍历，或让原本一次遍历变成多次遍历，就需要在压测环境确认。没有把握之前，热路径上的长方法可以先只做命名和注释清理。
- 框架与反射依赖。被序列化、被反射按方法名调用、作为接口实现或重写父类方法的函数，签名和可见性不能随手改。
- 没有测试覆盖。这种情况下建议只做不改逻辑的机械抽取，不做条件合并、循环改写这类语义调整；一旦发现问题，按提交粒度回退到上一个可运行版本。
- 本质是表或状态机。如果拆分后出现大量只做一次判断的小方法，说明这段代码更适合改成规则表或状态转换表，继续切方法收益不大。