企业官网建设流程全解析

上周帮一个团队做代码评审，产品提的需求看着特别小：把订单导出的优惠券字段从单个改成列表。本来评估是半天的活，结果那位同学翻了 11 个文件，改了 6 个类，还顺手改坏了两处历史逻辑，测试环境冒出一个跟需求毫无关系的报错。改完之后大家坐在会议室里沉默了一会儿，没人说得清这段代码到底哪一部分该谁负责。这种局面在重构圈子里有两个非常精准的名字：弹式修改（Shotgun Surgery）和它的镜像面发散式变化（Divergent Change）。它们看起来是两个毛病，根子上其实是同一个问题——单一职责没有落地。这两个词出自 Martin Fowler 的《重构》，书里把它们归在"代码坏味道"章节，我做过几年业务系统维护和架构治理，可以说这两种味道是最常见、破坏力最大、也最容易被团队忽视的一类。这篇内容我会把这两种味道的现场特征、判断标准、跟单一职责的真实关系、以及我实际用过的重构手法和踩过的坑，完整地摊开讲一遍。无论你是刚接手一个祖传项目的开发，还是正在设计新模块的负责人，都能从里面拿到能直接抄作业的判断依据和操作步骤。

1. 先把这两种坏味道的现场还原清楚

概念听多了容易飘，我习惯先把它们翻译成代码现场长什么样。很多人第一次听到"发散式变化"和"弹式修改"会觉得这俩说的是同一件事，都是"改一处动多处"，其实方向正好相反。一个说的是"一个模块被太多原因推动着改"，另一个说的是"一个原因散落在太多模块里"。把方向搞清楚，后面的处理手法才不会用错。

1.1 发散式变化：一个类被好几拨人轮流改

发散式变化的典型现场，是一个类同时承载了好几个业务维度的变化。比如一个 400 行的OrderService，里面塞了价格计算、优惠券匹配、发票抬头渲染、库存预占、风控审核判断。表面上它是一个"订单服务"，很合理。但你去翻提交记录就会发现：促销规则调整改它，财务要求发票格式变更改它，仓储侧的库存策略调整还改它，风控加一条规则又改它。四条完全不同的变化轴，全部压在一个文件上。

我在一个电商项目里见过更极端的：一个UserManager类同时管登录鉴权、会员等级、积分发放、消息推送开关。这个类最后 1200 多行，任何两个小组同时排期，git 合并必冲突，而且冲突还往往不在同一个方法里，解决起来特别费劲。更麻烦的是回归测试范围——改积分逻辑理论上只影响积分，但因为它们在同一个类里共享私有字段和辅助方法，谁也不敢保证不影响登录。于是每次改动都要跑全量回归，发布节奏被拖得很死。

识别发散式变化有一个很土但特别准的办法：打开这个文件的 git 历史，看提交信息的主题词分布。如果提交主题能明显归成三到四类完全不相干的关键词，而且每隔一段时间就交替出现，那基本可以判定它承担了多条变化轴。这个办法不需要任何工具，git log --oneline就够了，我经常在评审前先跑一遍。

注意：发散式变化的核心不是"代码行数多"，而是"变化原因多"。一个 800 行的纯算法类如果只有一个变化原因，它不算发散式变化，硬拆反而有害。

1.2 霰弹式修改：一个小需求散落到十几个文件

霰弹式修改是反过来的方向。你只做了一个概念上的变更，比如"新增一个销售渠道"，结果代码里到处都要动。枚举要加一项，校验器要加一个分支，费率计算要加一个if，报表映射要加一条，数据库字典表要插一行，前端配置文件里还有一份渠道列表，甚至消息模板里也硬编码了渠道名称。

这种散落最直接的后果就是漏改。我记得有个项目新增支付方式，主流程测通了，上线后发现对账报表把新渠道的数据全部归到了"其他"，因为报表那边是另一个小组维护的，需求评审时根本没人想到要通知他们。这类问题的排查成本极高——现象是数据不对，但出错的地方离你改动的代码隔着五六个模块，靠猜是猜不出来的。

还有一个隐性的成本：需求评估会越来越不准。因为没人能说清"改这个功能到底要动几处"，估时只能凭经验拍，拍出来的工时经常差三倍。我见过团队干脆放弃评估，所有需求统一按最坏情况排期，结果整体交付效率被这个不确定性吃掉了很大一块。

霰弹式修改的识别特征也很明显：一个原本很小的语义变更，提交里涉及的文件数超过 5 个，而且这些文件分属不同目录、不同层级。如果同一个变更散落在三个以上的switch或if-else链里，那基本就是标准案例。

1.3 两种味道的对照关系与判断矩阵

为了不让大家混，我把两者的关键差异整理成一张表。这张表我在团队内部讲过好几次，比纯文字描述好记很多。

这张表里最能说明问题的是"常见根因"那一行。发散式是该分的没分，霰弹式是该聚的没聚。所以很多时候你会看到两种味道在同一个系统里同时出现：一个巨大的上帝类负责编排，周围散着一堆各自维护半个规则的辅助类。这种组合结构是最难改的，因为动任何一边都会牵动另一边。

还有一个容易被忽略的点：这两种味道跟代码量没有必然关系。我见过一个只有 60 行的工具类，同时承担了日期格式化、字符串截断和金额精度处理三件事，照样是发散式变化。反过来，一个两千行的纯解析器如果只有一个变化原因，也不该被硬拆。判断依据始终是变化原因的数量，不是行数。

2. 单一职责到底该怎么理解才不跑偏

聊到这里绕不开单一职责原则（SRP）。但这个词被误用得实在太厉害，我见过太多团队把它执行成"一个类只允许有一个 public 方法"，最后拆出几百个碎类，跳转成本高到没人愿意读。所以这一章我想把 SRP 重新讲一遍，重点讲清楚它的判断依据到底是什么，以及拆分到什么程度算合适。

2.1 职责不等于"做一件事"

最常见的误解是把"职责"理解成"功能"。一个类负责计算价格，那它就只做一件事，符合 SRP——这个理解是错的。因为"计算价格"这件事本身可能同时被促销团队、财务团队、渠道运营团队三拨人推动着变。促销要加满减，财务要改税的计算口径，渠道要加平台补贴。它们都作用在"价格计算"这一个功能上，但它们是三条完全不同的变化轴。

Robert Martin 给 SRP 的原始定义是"一个模块应该有且只有一个被修改的原因"，注意是reason to change，不是thing to do。Fowler 在《重构》里说得更直接：判断一个类有没有多个职责，方法是问"它会被哪些不同类型的需求推动着修改"。所以职责的单位是变化原因，不是功能点。

我自己的判断句式是这样的：如果这个类的修改需求来自两个不同的部门、不同的角色、或者在不同时间点以完全独立的节奏提出，那它就是多个职责。用这个句式去扫，准确率比"看起来像不像一件事"高很多。比如"价格计算"和"发票渲染"，前者被定价团队驱动，后者被财务合规驱动，虽然都在订单上下文里，但它们是两个职责。

2.2 用变化轴做一次体检

光讲道理不够，我给一个可以照着做的体检流程。第一步，把这个模块近半年的提交记录拉出来，按提交主题归类。第二步，为每一类归纳出一个"驱动角色"或者"驱动来源"，比如定价策略、合规要求、渠道对接、性能优化。第三步，数一数有几类。超过两类，并且它们的变化节奏互不相关，就值得考虑拆分。

这里有个细节：同一类变化原因的多次修改不算多个职责。比如定价团队三个月里改了五次促销规则，这仍然只是一个变化轴。有些人看到提交多就以为职责多，然后拆完发现拆出来的两个类还是被同一拨人改，白拆。

我在实际项目里还会用一个更快的近似判断：观察修改这个模块时的知识需求。如果改 A 部分要求你懂税率和发票规范，改 B 部分要求你懂库存的预占和释放规则，那这两部分的知识领域完全不同，大概率是两个职责。知识领域不重叠这个信号非常好用，因为它直接对应到"换个人来改行不行"这个现实问题。

2.3 拆分粒度：拆太细同样是一场灾难

这一节是我最想强调的。这些年我见过太多"为了 SRP 而 SRP"的改造，把原本还能读的代码拆成了一堆三行小类。结果是：读一个业务流程要在十几个文件之间跳来跳去，IDE 的调用链视图都画不下；新人接手一周还在找入口；为了传一个参数，中间要加两层 DTO 转换。

我的经验判断标准是三条。第一，拆出来的两个部分能不能交给两个人并行开发而互不干扰？如果拆完之后两边还是要频繁同步改同一个接口，说明切分位置选错了。第二，拆完之后主流程的可读性有没有变好？如果一个业务流程原来在一个方法里 30 行能读完，拆完变成需要跳 8 个文件才能看懂，那这个拆分是负收益。第三，一起变化的代码是不是还在 一起？把经常同时改的两段逻辑拆到两个模块里，等于人为制造霰弹式修改，这是最常见的反向操作。

提示：当你拿不准该不该拆的时候，先别拆，加一个注释把不同职责的边界标出来。等它真正开始在不同节奏上变化时再动手，这时候你手上会有更明确的变化轴证据。

还有一个避免过度拆分的手法：优先用模块内的私有方法分组，而不是直接提取成独立类。先用方法名把职责边界划清楚，观察两个季度。如果这两组方法始终各改各的，再提类也不迟。这个方法帮我避免了好几次冲动拆分。

3. 从坏味道到重构：完整实操流程

讲完判断，进入动手环节。我按两种味道分开讲手法，然后给一段完整的改造实录，最后说安全网怎么搭。这一段建议对照代码看，光看描述容易觉得"道理我懂"，但真正动手时顺序错了会带来很大风险。

3.1 发散式变化的处理手法与操作顺序

处理发散式变化的主线思路是提取类 + 委托，必要时引入策略模式把条件分支消掉。顺序很关键，我一般按这五步走：

1. 补上覆盖当前行为的测试。哪怕只是几个粗粒度的集成测试，也必须有，否则后面每一步都是在赌。
2. 标记变化轴。在代码里用注释把属于同一条变化轴的字段和方法圈出来，先不搬。
3. 提取第一个类。选那条最独立、依赖最少的变化轴先动，用 IDE 的 Extract Class 或者手写，把相关字段和方法搬过去。
4. 在原类里保留委托入口。这一步是为了让外部调用方不受影响，避免一次改动波及所有调用点。
5. 观察一个迭代周期，再决定要不要继续拆第二条变化轴，以及委托入口是否可以逐步删除。

第 4 步是很多人会跳过的，但这步能救你。保留委托意味着你可以分多次提交，每次提交都很小，出问题也容易定位。我见过有人一次把上帝类拆成七个类，提交里 80 个文件，review 根本没法做。

下面是一段真实的改造前后对照。改造前是一个典型的多职责订单服务：

public class OrderService { public BigDecimal calculatePrice(Order order) { BigDecimal total = order.getItems().stream() .map(i -> i.getPrice().multiply(BigDecimal.valueOf(i.getQty()))) .reduce(BigDecimal.ZERO, BigDecimal::add); if (order.getUser().isVip()) { total = total.multiply(new BigDecimal("0.95")); } if (order.getCoupon() != null) { total = total.subtract(order.getCoupon().getAmount()); } return total; } public String renderInvoice(Order order) { StringBuilder sb = new StringBuilder(); sb.append("抬头：").append(order.getCompanyName()).append("\n"); sb.append("税号：").append(order.getTaxNo()).append("\n"); sb.append("金额：").append(calculatePrice(order)).append("\n"); return sb.toString(); } public void deductStock(Order order) { for (OrderItem item : order.getItems()) { stockClient.lock(item.getSkuId(), item.getQty()); } } public boolean needManualReview(Order order) { return calculatePrice(order).compareTo(new BigDecimal("50000")) > 0 || order.getUser().isFirstOrder() && order.getItems().size() > 20; } }

这段代码里至少压了四条变化轴：定价、发票渲染、库存、风控。改造后拆成四个协作对象，原来的类退化成编排者：

public class OrderService { private final PricingCalculator pricing; private final InvoiceRenderer invoiceRenderer; private final StockDeductor stockDeductor; private final ReviewPolicy reviewPolicy; public OrderService(PricingCalculator pricing, InvoiceRenderer invoiceRenderer, StockDeductor stockDeductor, ReviewPolicy reviewPolicy) { this.pricing = pricing; this.invoiceRenderer = invoiceRenderer; this.stockDeductor = stockDeductor; this.reviewPolicy = reviewPolicy; } public BigDecimal calculatePrice(Order order) { return pricing.calculate(order); } public String renderInvoice(Order order) { return invoiceRenderer.render(order, pricing.calculate(order)); } public void deductStock(Order order) { stockDeductor.deduct(order); } public boolean needManualReview(Order order) { return reviewPolicy.needReview(order, pricing.calculate(order)); } }

拆完之后的变化特征是：促销规则调整只碰PricingCalculator，发票格式调整只碰InvoiceRenderer，两个小组可以并行开工，回归测试范围也各自收敛了。

3.2 霰弹式修改的收敛手法

处理霰弹式修改，核心是找到"散落的元数据"，把它收拢到唯一一处。三条常用路径：

• 提炼配置或注册表。把散落在各处的枚举、映射、硬编码字符串收进一个集中定义的数据结构。适用于"新增一种类型要改六处"的情况。
• 多态替代条件分支。适用于同一个switch在多处重复出现的情况，把每个分支的行为封装成一个实现类，用接口统一调用。
• 搬移方法与内联类。如果职责被切得太碎，把本该在一起的东西重新合并回同一个模块，这是收敛方向的操作，和发散式的处理手法正好相反。

举个例子：新增一种渠道要在四个地方加if：

public BigDecimal calcFee(String channel, BigDecimal amount) { if ("A".equals(channel)) return amount.multiply(new BigDecimal("0.006")); if ("B".equals(channel)) return amount.multiply(new BigDecimal("0.008")); if ("C".equals(channel)) return amount.multiply(new BigDecimal("0.010")); return BigDecimal.ZERO; }

同一套分支在validateChannel、mapToReportType、buildMessage里各出现一次。收敛的做法是定义一个接口，把每个渠道的全部差异装进同一个实现类：

public interface ChannelHandler { String code(); BigDecimal fee(BigDecimal amount); void validate(Order order); String reportType(); String messageTemplate(); } public class ChannelRegistry { private final Map<String, ChannelHandler> handlers = new HashMap<>(); public ChannelRegistry(List<ChannelHandler> handlerList) { for (ChannelHandler h : handlerList) { handlers.put(h.code(), h); } } public ChannelHandler get(String code) { ChannelHandler h = handlers.get(code); if (h == null) { throw new IllegalArgumentException("unknown channel: " + code); } return h; } }

改完之后，新增渠道只需要写一个新的实现类并注册进容器，其他代码一行不改。我把这种改造称为"从一个点炸开"变成"往一个点收敛"。

注意：收敛过程中最容易出问题的是默认分支。原来的switch里可能有default兜底逻辑，改造时如果漏掉，异常场景的行为会变。我在迁移时会专门为 default 场景补一个测试用例。

3.3 一段完整改造实录：300 行服务类的拆分过程

这里我详细讲一次实际操作，包含中间状态和参数选择。

项目背景是一个财务对账服务，单个类 312 行，负责拉取账单、解析、比对、生成差异报告、推送通知。变化来源有四个：上游账单格式、比对规则、报告模板、通知渠道。半年内被四个不同的人改过。

第一步我做的事情不是动代码，而是量了一下改动分布。用git log --pretty=format:"%s" -- src/ReconcileService.java | sort | uniq -c | sort -rn看提交主题的重复情况，结果"账单格式"出现 11 次，"比对规则"出现 8 次，"报告模板"出现 6 次，"通知渠道"出现 4 次。四条轴清晰分开，证据够了。

第二步搭测试。这类批处理服务的测试不好写，我的做法是抓三份真实账单样本（含正常、缺字段、金额不一致三种情况），写成参数化测试，断言最终的差异报告内容。这里我刻意没有去测内部方法，只测输入到输出的整体行为，为的是让后续重构有自由度。

第三步按轴抽取，顺序是从依赖最少的那条轴开始。通知渠道最独立，先抽成NotifySender，原类里保留一个委托方法。提交一次，跑测试，通过。再抽报告模板成ReportRenderer，同样保留委托。这里有个参数选择：我把ReportRenderer的入参从原来的ReconcileResult大对象改成了一个更小的DiffSummary，为的是切断它和比对逻辑的隐式耦合。这一步做了差不多两个小时，因为要改十几处调用点。

第四步是比对规则的抽取，也是最难的一步。原来比对逻辑散在三个方法里，还共享了几个私有字段。我的做法是先把共享字段打包成一个内部状态类MatchContext，再把三个方法连同状态类一起搬到RuleEngine里，最后在原类中改成委托。整个过程分五次提交，每次提交后跑一次全量测试。

改造后的数字：ReconcileService从 312 行降到 78 行，四个协作类加起来 340 行。总行数略增，但四个小组从此可以并行修改，合并冲突从每周两三次降到几乎为零。回归测试范围也从全量压缩到各自模块，发布周期从两周缩短到一周。

3.4 安全网：测试、提交粒度和工具顺序

重构能做的前提是有安全网。我这边有三条硬规矩，分享出来可以直接用。

第一条，没有测试覆盖的代码不重构，先补测试。如果实在没法补（比如依赖外部系统太重），退一步用"录制回放"的办法：把真实输入和输出录下来，作为对比基线，重构后跑一遍看结果差异。

第二条，一次提交只做一种动作。重构和功能修改绝对不放在同一个提交里。我见过太多次"顺手改了个 bug 顺便重构"，结果出问题时根本分不清是重构引入的还是新逻辑的问题。这条规矩看起来啰嗦，实际救命的次数不少。

第三条，优先用 IDE 的自动化重构。IntelliJ 的 Extract Class、Move Method、Inline、Change Signature 这些操作用了十几年，靠谱程度远高于手写。但要注意顺序：先做 Change Signature 调整接口，再做 Move，最后做 Extract，反之容易产生大量临时编译错误。

提示：重构前先在一个干净的分支上打一个 tag。万一改到一半发现方向错了，回退成本几乎为零。

4. 常见问题与踩坑实录

这一章是我这些年攒下来的实战教训。有些坑我自己踩过，有些是看别人踩的。我把它们整理成速查表加具体案例的形式，方便对照排查。

4.1 问题速查表

4.2 三条我踩过的坑

第一个坑：按技术分层拆，而不是按变化轴拆。早年我把一个服务类拆成了XxxValidator、XxxCalculator、XxxConverter，看起来很有条理，符合分层美学。结果发现每次业务规则变化，这三个类都要一起改，硬生生造出了霰弹式修改。后来我才明白，分层是逻辑视角，变化轴是演化视角，重构要按后者来。现在我做拆分时会先问一句：这次拆开的两部分，将来会不会经常一起改？会的话就不拆。

第二个坑：在没有测试的地方凭感觉重构。有一次我改一个老的对账模块，觉得逻辑很简单，跳过补测试直接动手。改完上线，某个边界场景（金额刚好等于阈值）的判断从>=变成了>，一个月后才被发现，代价是人工核对了几千条记录。从那以后我的规矩就是硬性的：先测后改，没有例外。

第三个坑：把重构和性能优化混在一起。有一次我拆完类之后顺手把两层循环改成了一次遍历，结果重构提交和优化提交混在一个 commit 里，后来发现结果有细微差异，回滚的时候只能整个回滚，前面两天的重构工作白做。现在我一定是先完成纯重构并提交，等测试全绿，再单独做优化。

4.3 什么时候该忍一忍

不是所有坏味道都要立刻处理。我的取舍标准是这样的：如果一个模块虽然承担了多条变化轴，但每条轴一年才动一次，那拆分的收益很低，我会选择加注释标注边界，等它真正开始频繁变化时再动。反过来，如果某个模块最近三个月被改了十次以上，而且分属不同人的不同需求，那就算它只有 200 行也要拆。

还有一种情况要忍：临近发布窗口。重构的收益是长期可维护性，而发布窗口前任何改动都是风险。我一般会把识别出的坏味道记录进技术债清单，等下一个迭代排进去，而不是见缝插针地改。

判断"是不是该动"我有个简单的问题：这次改动如果只改一半，会不会让代码变差？如果会，说明这次拆分不完整，宁可不做。完整的重构比半个重构安全得多。

5. 从源头防止这两种味道复发

治已病的成本永远高于防未病。两种味道的产生往往不是个人技术问题，而是团队在接口设计、模块边界和评审习惯上留下的口子。这一章讲几个我实际推行过的预防措施。

5.1 边界划分与依赖方向

发散式变化的预防核心在模块边界。在设计阶段就要把变化轴显式地列出来，作为模块划分依据。我的做法是在设计文档里加一个小节，叫"变化来源清单"，把每个模块预期会被哪些外部需求推动着变化写清楚。如果同一个模块下出现了两个以上来源，评审时就要提出质疑。这个小节写起来不到十分钟，但能拦住很多后期的拆分成本。

霰弹式修改的预防核心在依赖方向。一条规则如果在多个地方被复制，说明它没有被正确地放在唯一的宿主模块里。我推行的原则是：任何一条业务规则只能有一个定义点，其他地方只能通过接口访问，不允许重新实现。落到代码上就是不允许在业务代码里出现硬编码的业务枚举字符串，所有类型判断都必须走注册表或者接口。

还有一个具体做法：把"新增一种类型"作为一个明确的验收场景写进设计检查清单。设计评审时问一句"如果现在要新增一个渠道，需要改哪些文件"，如果答案是超过三个，就说明边界没切好。这个问题比任何理论讲解都管用。

5.2 代码评审的识别清单

评审是最经济的拦截点。我整理过一份五条的快速清单，评审时按顺序扫一遍，一分钟能判断出大概：

1. 这次改动涉及的文件数有没有超过 5 个？超了的话，改动内容是不是同一个业务概念？
2. 这个文件最近的提交主题是否分散在不同业务领域？
3. 有没有在同一提交里既改了业务逻辑又做了结构调整？
4. 新增的类型判断是不是写在了多个地方？
5. 修改的类名和它实际承担的变化原因还匹配吗？

第 5 条看起来虚，但其实很有效。当一个类叫OrderService却开始承担发票和库存的修改时，命名和职责就脱节了。这种脱节往往比具体代码更容易被发现。

5.3 用 git 历史做一次坏味道体检

最后分享一个我经常用的小技巧，不需要任何静态分析工具，纯 git 命令就能跑出一份坏味道候选清单。

# 找出最近三个月改动最频繁的文件 git log --since="3 months ago" --name-only --pretty=format: \ | grep -v '^$' | sort | uniq -c | sort -rn | head -20 # 查看某个文件的提交主题分布 git log --pretty=format:"%s" -- path/to/File.java \ | sort | uniq -c | sort -rn

第一条命令给出高频改动文件，这些是发散式变化的高危候选。第二条命令看提交主题的分散程度，如果主题词归不出清晰的一两类，那基本可以确认存在多职责。

我一般每个季度跑一次，把结果贴到技术债清单里，按改动频次排序处理。高频率且多主题的文件优先拆，低频的就先挂着。这个做法比凭印象判断靠谱得多，而且能拿出数据说服产品经理排期。

注意：这个统计方法对刚合并进来的大模块会失真，因为迁移本身会产生大量提交。跑之前先把大规模迁移的提交过滤掉。

我个人在实际操作中的体会是，重构这件事最大的难点从来不是手法，而是判断。Extract Class 和 Move Method 这些操作，会写代码的人两小时就能学会，真正拉开差距的是"该不该拆、拆到哪、什么时候拆"。我见过太多团队把 SRP 当成教条，拆出一堆比原来更难维护的碎类；也见过一些团队对着一千行的上帝类视而不见，因为"它一直在跑没出过事"。这两种做法都走偏了。比较务实的路径是：用 git 历史去量变化轴，用变化轴去判断职责，用可读性和并行开发能力去检验拆分结果，最后用小步提交和测试兜住风险。这套流程没有任何玄学成分，也不需要引入复杂工具，任何一个有半年开发经验的人都能照着做。真要给一句总结性的话，我会说：盯着变化看，而不是盯着代码看——代码长什么样只是结果，变化从哪来才是原因。