软件工程复杂性管理：从软件危机到订单状态机重构

软件工程导论类课程通常把“软件危机”放在第一章，原因是软件行业最原始的驱动力并不是更快的技术，而是对复杂度的控制。一个几百行的脚本可以靠人脑装下，一个几十万行的业务系统如果没有任何结构，负责维护的人会很快失去掌控。“软件工程的核心在于管理复杂性”这句话不是理论口号，而是行业多年踩坑后的总结。

在实际项目里，复杂性不会集中在某一天爆发。它会随着需求叠加、人员变动、框架升级慢慢积累，表现为“改一个状态判断要翻三种服务”“测试用例不敢动”“上线后只能用日志猜现场”。这些问题并不是某一个接口写得差，而是整个系统的结构和协作方式没有把复杂性管理住。

这篇文章围绕复杂性本身展开，分析它从哪里来、在代码里是什么样子、有哪些可落地的管理手段，再通过一个订单状态流转的重构案例演示如何把复杂分支变成清晰结构。最后会补充工程化落地的工具链、常见问题排查和可复用的复杂度自检清单。适合正在学习软件工程课程、准备软件工程毕业设计，或者正在维护中型业务项目的开发者阅读。

1. 软件靠什么对抗复杂性：先理解问题的本质

1.1 从“软件危机”到今天，复杂性为什么始终在

软件工程导论里有一个“软件危机”概念，描述的是 20 世纪 60 年代末大型软件开发频繁出现超期、超预算、质量失控的现象。当时很多失败项目并不是程序员能力差，而是问题规模已经超过了个人能够理解和掌控的边界。

单个人维护几千行代码时，可以通过记忆所有调用关系来保证正确性。当代码量到达十万、百万行，参与者变成几十人时，记忆失效，抽象不足的问题开始暴露：一个模块的细节被另一个模块直接依赖，一处数据修改导致二十个功能异常，没有人能说清楚完整影响范围。

软件危机的本质就是复杂性管理失败。后来出现的结构化编程、面向对象、设计模式、微服务、领域驱动设计，本质上都是为了让大规模代码仍然可以被少数人理解、修改和验证。技术名词在变，底层目标没有变：把复杂系统拆解成人脑能够处理的单元，并保持单元之间的依赖可控。

1.2 复杂性的三种来源：业务现实、技术选型、多人协作

很多开发者以为复杂度主要来自代码，实际上代码只是复杂性的最终投影。它通常有三个来源。

第一是业务现实。真实业务充满例外和规则，不同角色有不同权限，不同渠道有不同的退款策略，不同促销活动有不同的叠加规则。业务越接近现实，规则集合就越庞大。这种复杂性不能凭空消除，只能建模和管理。

第二是技术选型。分布式系统要处理网络超时、数据一致性、重试幂等；微服务要处理服务发现、配置中心、链路追踪；即使单体应用也会遇到并发、缓存失效和事务边界问题。技术方案本身会引入新的复杂度，收益是解决业务复杂度，但如果没有约束，技术复杂度会反过来压垮团队。

第三是多人协作。代码是多人共同修改的，每个人都有自己的理解方式、命名习惯和优先级。如果模块边界不清晰，两个开发者很容易在同一片区域里修改，造成隐性冲突。组织的沟通结构最终会反映在代码结构里，这也是康威定律的常见表现。

这三类复杂性来源完全消除掉是不现实的。工程的目标不是建立一个“零复杂”系统，而是建立一个“复杂度被有效分区”的系统，让任何一个局部都能被人独立理解。

1.3 复杂性失控的信号：构建、测试、修改、上线都变慢

复杂性失控通常有清晰信号，不需要等系统崩溃才意识到。下面这些现象如果出现三条以上，就需要开始治理。

这些信号本质上都是认知负荷过载。系统总复杂度超过团队能够维护的上限，日常开发就开始靠“小心谨慎”而不是“结构保证”来维持质量。

2. 复杂性的典型临床表现：一段代码如何从 20 行演变成 500 行

2.1 需求堆叠导致的分支地狱：一个订单状态判断的坏味道示例

订单状态处理是复杂度失控的高发区。业务开始时只有一个状态字段，随着支付、退款、发货、售后等需求加入，代码自然地长出层层 if-else。

下面是一段常见的“坏味道”代码，它同时处理了订单状态、用户角色和支付结果：

public String handleOrder(Order order, User user, Payment payment) { if (order.getStatus() == OrderStatus.PENDING_PAYMENT) { if (payment.isSuccess()) { if (user.isVip()) { order.setStatus(OrderStatus.PAID); sendVipNotify(order); return "paid_vip"; } else { order.setStatus(OrderStatus.PAID); sendNormalNotify(order); return "paid"; } } else { int retryCount = order.getRetryCount(); if (retryCount >= 3) { order.setStatus(OrderStatus.CLOSED); return "closed"; } order.setRetryCount(retryCount + 1); return "pending_retry"; } } else if (order.getStatus() == OrderStatus.PAID) { if (user.isAdmin()) { if (payment.isRefundable()) { order.setStatus(OrderStatus.REFUNDING); return "refunding"; } } order.setStatus(OrderStatus.SHIPPING); return "shipping"; } // 更多状态分支... return "unknown"; }

这段代码从功能上看可以运行，但它把状态流转、角色校验、支付结果、通知动作全部混在一个方法里。每接一个新需求，就需要往这个方法里再加一个 if 分支，方法体越来越长，直到没有人敢修改。

2.2 把业务规则和流程控制耦合在一起造成的连锁改动

上面这种代码最大的问题不是行数，而是规则散落。订单“从待支付到已支付”这个转移是否合法，没有在一个公共位置统一定义；不同角色支付成功的动作散落在不同 if 分支里；支付失败后的重试策略又被埋在状态判断内部。

结果是任何一处业务规则变更都会引发连锁修改。例如“所有用户支付成功都统一发送消息”，你需要同时改 VIP 分支和普通分支；例如“管理员不允许直接发货”，又需要新增一个嵌套判断。散落规则让变更范围不可预测，也让测试变得困难：为了覆盖一个分支，需要构造特定订单、特定用户、特定支付状态，测试用例数量成倍增加。

代码维护者需要同时理解三种概念的语义：状态枚举、业务规则、动作副作用。这三种概念叠加在一起，认知负荷自然上升。这不是某一个开发者的水平问题，而是结构没有给复杂性分区。

2.3 识别坏味道：圈复杂度、循环依赖、隐式依赖、共享可变状态

面对这种代码，不能用“看着乱”来评价，要有可量化的指标。

圈复杂度是最直接的指标。它统计一个方法里独立路径的数量。上面handleOrder方法的圈复杂度远高于 10，意味着测试和阅读都需要考虑大量分支组合。很多工程规范要求单个方法圈复杂度不超过 10，超过后必须拆分。

循环依赖是另一个典型坏味道。两个类互相引用时，单看任何一方都无法理解完整行为，必须同时打开两个文件来回跳转。模块之间一旦形成循环，重构就变成牵一发动全身。

隐式依赖比循环依赖更隐蔽。例如一个方法内部直接读取ThreadLocal，或者直接调用另一个模块的静态工具类获取配置，调用方看起来只有一个参数，实际上还依赖外部上下文。

共享可变状态也非常危险。多个线程同时修改同一个缓存或同一个全局对象时，正确性取决于执行时序，测试和排查都会变得困难。

这些问题都可以在代码评审和静态检查阶段被发现。关键不是追求代码“好看”，而是让任何一个局部模块都能独立阅读、测试和修改。

3. 管理复杂性的四件武器：分治、抽象、层次、契约

3.1 分治：把大问题拆成可独立验证的小问题

分治是软件工程最基础的方法。一个大型系统无法一次性整体验证，但可以拆成多个模块，每个模块先独立验证，再通过接口组合起来。

拆分维度可以按业务领域、技术层、功能流水线三种方式选择。按业务领域拆分时，订单、商品、用户、支付各自独立；按技术层拆分时，数据库访问、业务逻辑、接口展示分层；按功能流水线拆分时，库存扣减、订单生成、通知发送依次执行。

分治的代价是拆分后必然产生模块间通信。如果拆分过细，模块之间的关联成本会超过单模块简化带来的收益。合理拆分应该遵循“高内聚、低耦合”原则：模块内部的内容应该属于同一业务意图，模块之间只通过明确的接口交互。

3.2 抽象与信息隐藏：只暴露稳定的接口，隐藏易变的实现

抽象的目的是隐藏细节。调用方只需要知道“支付成功”和“退款发起”这两个动作，不需要知道底层连接了哪家支付渠道、如何处理验签和回调。

信息隐藏是抽象的重要实现手段。实现细节一旦暴露给调用方，调用方就会开始依赖它，导致改动细节时需要同步修改所有调用方。例如订单服务不应该把支付渠道字段直接暴露给上层，否则上层逻辑会针对微信支付、支付宝写不同分支，渠道更换时所有分支都要改。

好的抽象具有两个特点：接口稳定、语义清晰。稳定是指接口的方法签名不会随底层实现频繁变化；清晰是指调用方从方法名和参数就能理解行为，不需要阅读实现代码。如果调用一个方法还要去看实现才能知道副作用，抽象就是失败的。

3.3 层次与依赖方向：让依赖从底层指向高层，避免循环

分治解决了“拆成哪些模块”的问题，层次解决“模块之间能依赖谁”的问题。常见的三层结构是接口层、业务层、基础设施层，依赖方向从接口层指向业务层，业务层指向基础设施层。

依赖方向的作用是划定单向边界。业务层不应该知道当前是 Spring MVC 还是其他框架，基础设施层不应该反向依赖业务层的某个具体类。只要依赖方向是一致的，修改某一层内部实现时，其他层可以不受影响。

这里容易出现一个误区：把“分层”理解成“文件夹分层”。很多人建了 controller、service、dao 三个包，但 service 里直接写了 SQL，dao 里塞了业务逻辑，目录是分层的，依赖已经穿透。真正有效的是依赖检查，不是目录结构。

3.4 契约：用接口、类型和不变式约束模块边界

模块之间除了“能调用什么”，还要规定“调用的前提和结果是什么”。这些规定就是契约。

契约可以体现在类型上。例如订单状态不再用字符串表示，而是用枚举类型，编译器就能阻止无效状态赋值。契约也可以体现在方法签名上，例如传入null时抛出明确异常而不是返回空对象。契约还可以体现在业务不变式上，例如“已经完成订单不能再进入退款流程”。

一个实用做法是把业务规则集中到模型层。枚举状态机、金额的精确数值类型、订单号不可变等约束放在核心模型里，服务层只负责编排动作。这样规则不会散落到每个 service 方法中，即使更换框架也不会丢失业务约束。

4. 实战：用分层和状态机重构订单流程，把复杂分支精简成可维护结构

4.1 需求背景：订单状态流转到底复杂在哪里

订单系统最核心的问题是状态流转。订单会经历待支付、已支付、发货中、已完成、已关闭、退款中、已退款等状态，每个状态之间是否允许转移是由业务规则决定的。例如待支付订单可以关闭，但不能直接发货；已支付订单可以退款，但完成之后通常只能走售后流程。

如果把这些规则写在 service 方法里，每次新增状态都需要修改 service 判断逻辑。一个更稳的做法是把状态转移表从业务逻辑里抽出来，作为独立的领域规则。

下面用一个小案例展示这个思路。完整代码会省略基础设施细节，只保留核心逻辑，落地时可以根据项目包名调整。

4.2 第一步：枚举和状态转移表建模，先定义数据与规则

先定义订单状态枚举，并把允许的转移关系集中放在一处：

public enum OrderStatus { PENDING_PAYMENT, PAID, SHIPPING, COMPLETED, CLOSED, REFUNDING, REFUNDED; private static final Map<OrderStatus, Set<OrderStatus>> TRANSITIONS = new EnumMap<>(OrderStatus.class); static { TRANSITIONS.put(PENDING_PAYMENT, EnumSet.of(PAID, CLOSED)); TRANSITIONS.put(PAID, EnumSet.of(SHIPPING, REFUNDING)); TRANSITIONS.put(SHIPPING, EnumSet.of(COMPLETED)); TRANSITIONS.put(COMPLETED, EnumSet.noneOf(OrderStatus.class)); TRANSITIONS.put(CLOSED, EnumSet.noneOf(OrderStatus.class)); TRANSITIONS.put(REFUNDING, EnumSet.of(REFUNDED)); TRANSITIONS.put(REFUNDED, EnumSet.noneOf(OrderStatus.class)); } public boolean canTransitTo(OrderStatus target) { return TRANSITIONS.get(this).contains(target); } }

这段代码把“哪个状态能转移到哪个状态”从散落的 if 条件中集中到了状态枚举内部。之后如果要增加一个“待支付订单可以转成已锁定”的状态，只需要在这个枚举中增加枚举值和转移集合，调用方逻辑不需要大改。

状态转移表也可以画成表格用于评审：

这张表本身就是业务规则的可视化表达。评审需求时先看表，比读代码更容易发现遗漏。

4.3 第二步：用策略和处理器拆分动作，让每个分支只做一件事

状态转移校验确定之后，还需要处理“转移到目标状态时执行哪些动作”。把这些动作从一个大方法中拆成独立的处理器，每个处理器只负责一种目标状态。

定义动作接口：

public interface OrderAction { void execute(OrderContext context); }

每个状态对应一个实现。例如支付成功动作：

public class PaidAction implements OrderAction { private final OrderNotifySender notifySender; public PaidAction(OrderNotifySender notifySender) { this.notifySender = notifySender; } @Override public void execute(OrderContext context) { context.getOrder().setPaidTime(context.getNow()); notifySender.sendPaid(context.getOrder()); } }

发货动作：

public class ShippingAction implements OrderAction { private final WarehouseClient warehouseClient; public ShippingAction(WarehouseClient warehouseClient) { this.warehouseClient = warehouseClient; } @Override public void execute(OrderContext context) { warehouseClient.createShipment(context.getOrder().getOrderNo()); } }

这些处理器类都很短，每个类只有一个职责。后续如果支付动作要增加优惠券核销，只需要修改PaidAction，不需要动订单状态机。

状态机核心负责统一校验和分发：

public class OrderStateMachine { private final Map<OrderStatus, OrderAction> actions; public OrderStateMachine(Map<OrderStatus, OrderAction> actions) { this.actions = actions; } public void move(Order order, OrderStatus target, OrderContext context) { OrderStatus current = order.getStatus(); if (current == target) { return; } if (!current.canTransitTo(target)) { throw new IllegalStateException( "订单状态不允许从 " + current + " 转移到 " + target ); } OrderAction action = actions.get(target); if (action != null) { action.execute(context); } order.setStatus(target); } }

原来的大 if 方法被替换为一个状态转移表加一组动作处理器。新增状态时，通常只需要加枚举项、配置转移关系、写新动作实现。

4.4 第三步：参数与依赖注入，测试时能替换外部服务

OrderContext用于传递本次操作需要的上下文，避免状态机方法出现过长参数列表。

public class OrderContext { private final Order order; private final LocalDateTime now; public OrderContext(Order order, LocalDateTime now) { this.order = order; this.now = now; } public Order getOrder() { return order; } public LocalDateTime getNow() { return now; } }

外部依赖通过构造器传入。状态机本身不负责创建PaidAction或ShippingAction，由组合根或者依赖注入容器装配。这样在单元测试中可以使用内存实现替换消息通知和仓库客户端，不需要真实调用外部系统。

一个典型的测试片段如下：

@Test void pendingPaymentToPaidShouldSendNotify() { Order order = new Order(OrderStatus.PENDING_PAYMENT); OrderContext context = new OrderContext(order, LocalDateTime.now()); FakeNotifySender sender = new FakeNotifySender(); OrderStateMachine machine = new OrderStateMachine( Map.of(OrderStatus.PAID, new PaidAction(sender)) ); machine.move(order, OrderStatus.PAID, context); assertEquals(OrderStatus.PAID, order.getStatus()); assertTrue(sender.hasSent(order)); }

测试不再需要构造复杂的嵌套条件，只关注“从待支付到已支付”这一条行为链路。外部交互对象换成测试替身，测试速度更快，失败信息也更明确。

4.5 验证与结果对比：重构后圈复杂度、测试覆盖率和可读性变化

重构前的handleOrder方法圈复杂度高，分支判断和动作执行耦合，测试需要覆盖多个 if 组合。重构后：

• 状态转移规则集中在枚举的TRANSITIONS中，新增状态时改动范围小。
• 每个动作类只负责一个目标状态，圈复杂度大部分在 3 以下。
• 状态机move方法只负责校验和分发，逻辑路径有限。
• 测试可以针对单个动作编写，不再需要构造复杂条件组合。

圈复杂度对比可以用静态检查工具在重构前后各跑一次。如果项目里还没有工具，可以先从检查if-else嵌套层数开始。常见规范是单层方法嵌套不超过 3 层，单方法行数不超过 80 行。

需要说明的是，重构不是把代码行数变少，而是把“可理解的单元”变小。重构后总代码量可能增加，但每个单元都能独立阅读、测试和复用。

5. 工程化落地：从代码级方法到团队级机制

5.1 用构建工具和模块边界阻止意外耦合

代码层面的原则需要依靠工具约束，否则长期协作之后边界会慢慢模糊。以 Maven 多模块为例，可以将项目拆成多个模块，并在依赖声明中明确上层对下层的依赖关系。

一个简化的模块化工程结构如下：

<modules> <module>order-api</module> <module>order-domain</module> <module>order-infrastructure</module> <module>order-web</module> </modules>

依赖方向应该从order-web指向order-domain，从order-infrastructure指向order-domain，而order-domain不依赖任何基础设施框架。这样可以通过 Maven 依赖关系限制模块间引用，如果出现反向依赖，构建阶段就会失败。

Gradle 也有类似能力，比如在build.gradle中为模块声明api和implementation依赖。implementation不会把依赖传递给下游模块，可以让调用方不感知中间模块的内部依赖。

5.2 用代码检查、单元测试、CI 流水线守住回归底线

本地开发时只运行测试往往不够，还需要统一在持续集成流水线里执行代码检查、单元测试、集成测试和构建产物检查。

一个简化的 GitLab CI 配置：

stages: - build - test - verify build: stage: build script: - mvn clean compile test: stage: test script: - mvn test verify: stage: verify script: - mvn verify -DskipTests=false - mvn checkstyle:check

学习环境里可以只在本地运行mvn test，生产环境流水线还应该增加依赖漏洞扫描、制品签名、镜像构建、自动化回滚等步骤。学习阶段的重点是让每次提交都经过自动化检查和测试，避免“我本地能跑”变成唯一依据。

对于测试本身，要区分单元测试、集成测试和端到端测试。单元测试应该快速、不依赖网络和数据库；集成测试可以连接真实数据库或中间件；端到端测试数量少，只覆盖核心链路。把大量测试都写成端到端测试会让流水线变慢，最后团队会因为等待时间过长而跳过测试。

5.3 用可观测性和日志帮助线上排查

结构再清晰的系统，上线后也可能出现不可预见的异常。可观测性的价值是：当异常发生时，能从日志和指标中逆向还原出当时的状态。

日志至少要包含关键上下文信息，例如订单号、用户标识、状态转移前后值。一段比较合理的日志写法：

logger.info("order status changed, orderNo={}, before={}, after={}, operator={}, traceId={}", order.getOrderNo(), before, after, operator, traceId);

不要只输出“支付成功”或“操作成功”这种没有上下文的信息。排查问题时，真正有用的是“哪个订单、从什么状态、变成什么状态、由谁触发、对应的全链路追踪 ID 是什么”。

生产环境建议使用结构化日志和统一日志采集平台，并在接口入口生成 traceId。小型项目可以从规范日志格式开始，至少保证每个关键业务动作都有上下文。

5.4 给项目设置复杂度预算：哪些指标要盯，哪些地方要允许临时复杂

复杂度管理不是一次性重构，而是长期约束。一个实用做法是为项目设置复杂度预算，让团队知道哪些指标超过阈值时必须处理。

允许临时复杂的场景也是存在的。比如紧急修复生产问题，可以先以最快方式止血，但必须在问题解决后补一个技术债务卡片，明确后续重构方向。复杂度预算最怕的是“临时”变成“永久”。

6. 常见问题排查：为什么用尽方法仍然越改越乱

6.1 重构后测试失败，是测试问题还是设计问题

现象：按新结构拆分代码后，原有测试开始大量失败，修复一个测试又引起另一个测试失败。

处理这个问题的第一步不是立刻改测试，而是先定位失败原因。常见原因是测试之间共享了可变状态。例如测试使用了同一个全局订单号生成器，或者同一个内存数据库在不同测试之间没有清空。重构把原先的顺序依赖暴露成了错误，这是好事。

检查顺序建议：

修复方式是让每个测试拥有独立上下文，不共享可变状态，外部依赖全部使用测试替身。如果测试本身写得很细，但都在验证实现细节，重构时也会大量失败，这时需要把测试从“验证怎么实现”改为“验证行为结果”。

6.2 抽象泄漏：接口越来越多，调用方还是需要知道内部细节

现象：接口层定义了很多方法，每个方法语义都很模糊，调用方不阅读实现代码就不知道应该调用哪个，以及调用后会发生什么。

这通常是因为接口设计不是基于调用方需求，而是基于实现类的方法照搬。接口没有隐藏细节，只是给每个方法加了一层壳。

解决方法是重新审视接口语义。接口方法应该描述“做什么”，而不是“怎么调”。例如OrderService的接口不应该是updateStatus和setShippingCode，而应该是markPaid和shipOrder。从调用方视角设计方法，才能避免抽象泄漏。

6.3 分层僵化：为了分层而分层，业务被切碎到无法理解

现象：代码目录严格按 controller、service、dao 分层，但一个简单业务操作要横穿四五个类，每个类只负责一行代码，阅读业务逻辑时需要来回跳转。

这种情况说明分层没有服务于业务分区，而是变成了机械的代码放置规则。分层通常适合按技术维度组织，但业务逻辑应该按领域聚合。如果一个业务操作必须分布在多个技术层中，可以考虑把业务相关的规则内聚到领域对象或服务内部，而不是强制每一层都只做一项技术操作。

判断标准很简单：一个新成员阅读一段业务逻辑，能否在一个文件里看到完整流程。如果必须同时打开八个类，业务的内聚性已经不足。

6.4 多人协作时的“局部最优导致全局混乱”如何避免

现象：每个模块单独看都很合理，但整体系统结构混乱。这是因为每个开发者只关注自己负责的局部，缺少全局约束。

工程化手段可以在一定程度上缓解。模块依赖规则、公共 API 评审、代码所有权、变更影响面评审都应该有明确约定。团队在技术评审中应该关注“这个改动会不会让模块边界变得模糊”，而不是只讨论功能实现细节。

代码评审中建议加入三个固定问题：

• 这个改动把复杂度放到了哪个位置？
• 新增依赖是否符合既定依赖方向？
• 如果下个月要替换掉其中一个外部系统，改动范围有多大？

这三个问题可以推动团队成员在做技术决策时主动考虑复杂度管理。

7. 最佳实践与扩展方向

7.1 复杂度自检清单：每次提交前过一遍

下面的清单可以作为日常开发的自检工具，不需要等待架构评审时才使用。

这套清单不需要一次全部满足，但每次提交代码前至少检查前三项。很多结构腐烂都是从一个小 if 分支开始的，越早处理成本越低。

7.2 从软件工程到机器视觉：复杂性思维的可迁移性

有人会问“软件工程专业能不能转机器视觉”，这个问题背后的实际诉求是“软件工程的训练对新领域有没有价值”。答案是有，而且粒度很细。

机器视觉或人工智能项目同样面对复杂问题：数据处理、模型训练、评估、部署、监控、迭代都会产生大量分支。如果不管理复杂度，数据集版本会混乱，实验过程无法复现，模型上线后无法快速定位问题。

软件工程里的可复现性、模块化、版本管理、自动化测试、可观测性等思维，在机器视觉项目里可以对应为：实验配置化管理、数据版本控制、训练脚本参数化、评估指标自动化、模型上线后的监控与回滚。技术栈不同，工程化诉求相同。

7.3 学习路径建议：从课程到毕业设计再到真实项目

对于还没有太多项目经验的读者，建议按下面的路径练习复杂性管理。

先完成软件工程导论课程的核心概念，理解生命周期、需求、设计、测试、维护之间的关系。然后选一个中等规模的毕业设计项目，例如带订单、库存、用户角色的电商后台，把状态机、分层、依赖注入、单元测试在实际项目里用起来。

之后可以逐步阅读设计模式、整洁架构、领域驱动设计相关的资料。设计模式解决的是局部代码的重复问题，领域驱动设计解决的是业务复杂度的建模问题。真正理解这些方法后，再去看微服务、事件驱动、分布式事务等方向，会更容易判断哪些复杂度是必须承担，哪些其实可以用简单结构避免。

管理复杂性是一项长期能力，它不依赖某个特定技术栈。能够在代码、测试、文档、协作中持续控制复杂度的人，才能在一个项目长期演进后仍然保持掌控力。建议从今天开始，先为当前项目画一张清晰的模块依赖图，然后从最严重的一处分支代码开始拆分。