代码复杂度的代价远比你想象得大

引言：复杂度的代价远比你想象得大

在 Java 后端系统演进过程中，代码复杂度是影响可维护性、稳定性和迭代效率的核心因素。然而，复杂度往往被忽视，直到一次“小改动”引发线上事故，才被重新审视。
本文以“复杂度战争”为主题，系统性地探讨如何识别、评估和治理代码中的复杂性。本文不会停留在抽象原则，而是结合真实案例、Java 代码示例和可落地的工程实践，让你了解你应用的代码复杂度，以及一个优秀的开发同学应该做到的避免代码”腐烂“的最佳实践。
让我们以一些代码案例引入今天的话题。（文中代码案例皆为模拟案例）
案例一：圈复杂度过高导致大事故

在某一个大促开始的日子，订单创建接口在高峰期响应时间飙升，错误率突破 XX%。  紧急回滚？没有最近的发布记录。  最终排查日志发现，数据库连接池被耗尽，而根源竟是一次两周前的“微小优化”。
开发同学为了支持一个新的促销规则，在 OrderService.createOrder() 方法中加了这么一段逻辑：

1. if (user.isVip() && order.getTotalAmount().compareTo(BigDecimal.valueOf(100)) > 0) {
2.     try {
3.         Discount discount = promotionClient.getDiscount(order);
4.         if (discount != null && discount.isValid()) {
5.             order.setFinalPrice(order.getTotalAmount().subtract(discount.getValue()));
6.         } else {
7.             order.setFinalPrice(order.getTotalAmount());
8.         }
9.     } catch (Exception e) {
10.         // 静默失败，使用原价（开发本意是防崩）
11.         order.setFinalPrice(order.getTotalAmount());
12.     }
13. }

复制代码

问题来了：这个 catch (Exception e) 不仅吞掉了业务异常，还捕获了 数据库连接超时异常（SQLException），导致外层事务未及时中断，线程持续等待，最终拖垮连接池。
而这个方法本身已有 350 行，嵌套层级达 6 层，圈复杂度高达 38 —— 没有人意识到，这次“小修”成了压垮系统的最后一根稻草。
这不是孤例。类似的复杂度事故，正在无数系统中悄然上演。
案例二：重复代码引发的数据错乱

支付网关中，签名计算逻辑在 AlipayProcessor、WechatPayProcessor 等 7 个类中重复出现：

1. String sign = DigestUtils.md5Hex(data + secretKey).toUpperCase();

复制代码

某天，安全团队要求升级为 SHA-256，但只改了其中 4 个实现类。剩下的 3 个渠道继续用 MD5，导致“无效签名”错误激增，影响数万笔交易。
工具扫描显示：重复代码率达 12%，而这些“看起来一样”的代码，分散在不同模块，无人统一维护。
案例三：“上帝类”无人敢动

CRM 系统中的 CustomerManager 类长达 2800 行，承担着客户创建、积分计算、消息推送、审计日志、缓存同步等 8 种职责。
更可怕的是，每次调用 updateCustomer()，都会触发一连串隐式行为：

1. public void updateCustomer(Customer customer) {
2.     customerRepo.save(customer);
3.    
4.     // 更新积分（即使只是改了个电话）
5.     rewardService.calculateReward(customer);
6.    
7.     // 推送消息（同步阻塞）
8.     messageQueue.send(buildUpdateMessage(customer));
9.    
10.     // 写审计日志
11.     auditLogService.log("UPDATE", customer.getId(), getCurrentUser());
12.    
13.     // 刷新缓存
14.     cacheService.evict("customer:" + customer.getId());
15. }

复制代码

新来的工程师想改个字段校验逻辑，结果测出 5 个副作用 bug。从此，这个类成了团队心中的“禁区”。
案例四：微服务拆分后更慢了

物流平台将单体拆分为订单、路由、运力三个服务后，原本本地调用 routeService.findOptimalRoute() 的耗时从 50ms 变成 350ms（含网络+序列化+重试）。
而最致命的是，当路由服务不稳定时，订单服务因未配置熔断，持续重试，反向拖垮整个链路。
复杂度没有消失，只是从“代码层面”转移到了“分布式层面”。
这些事件背后，都有一个共同敌人：失控的代码复杂度。
它不像内存泄漏那样立刻崩溃系统，也不像权限漏洞那样被安全扫描抓出。它潜伏在每一次“先上线再说”的妥协里，在每一个没人敢动的类中，在每一段“还能看懂”的嵌套逻辑中，缓慢侵蚀系统的生命力。
而作为 Java 后端开发者，尤其是架构师，我们必须清醒地认识到：

系统的可维护性，不取决于功能多强大，而取决于它的复杂度是否可控。

在这场看不见硝烟的 复杂度战争 中，我们不能靠运气取胜。我们需要工具来度量它，需要原则来约束它，更需要实战策略来持续降低它。
接下来，我们将深入探讨：

• 哪些指标能真正衡量代码复杂度？
  
• 如何用合理的工具发现系统中的“复杂度热点”？
  
• 在日常编码中，如何写出高质量、低复杂度的 Java 代码？
  
• 架构层面，又该如何从源头控制复杂度的增长？
  

代码复杂度的主流定义

当我们说一段代码“太复杂”时，往往是一种直觉判断。但真正的工程实践需要可量化、可检测、可改进的指标。所谓“复杂度”，并不是指代码行数多，而是指理解、维护、修改它的认知成本高。
在软件工程领域，已有多个被广泛认可的复杂度维度，它们从不同角度揭示代码的“健康状况”。
我们将逐一介绍这些指标的含义和实际案例，并按照其作用粒度分为三个层次：方法级、类级、继承结构级，帮助你系统化地识别和治理复杂度。
1. 圈复杂度（Cyclomatic Complexity）

定义

由 Thomas McCabe 提出，衡量程序中独立执行路径的数量。路径越多，测试难度越大，出错概率越高。
计算规则：每有一个 if、for、while、case、catch，复杂度 +1；else 不加分。总分>5 需关注
危害

• 路径爆炸 → 难以覆盖所有分支
  
• 异常处理易遗漏
  
• 修改风险高，容易引入副作用
  

实际案例

1. public BigDecimal calculateFinalPrice(Order order, User user, boolean hasCoupon) {
2.     BigDecimal total = order.getItems().stream()
3.         .map(Item::getPrice)
4.         .reduce(BigDecimal.ZERO, BigDecimal::add);
6.     if (total.compareTo(BigDecimal.valueOf(100)) > 0) {           // +1
7.         if (user.isVip()) {                                       // +2
8.             total = total.multiply(BigDecimal.valueOf(0.9));      // VIP 9折
9.         } else if (hasCoupon) {                                   // +3
10.             total = total.subtract(BigDecimal.valueOf(10));       // 减10元
11.         }
12.     }
14.     try {
15.         Promotion promotion = promotionClient.getActivePromotion(); // +4
16.         if (promotion != null && promotion.isValid()) {             // +5
17.             total = total.subtract(promotion.getDiscount());
18.         }
19.     } catch (RemoteException e) {                                   // +6
20.         log.warn("Failed to fetch promotion, using base price");
21.     }
23.     return total;
24. }

复制代码

该方法圈复杂度 = 6
虽然不算极端，但已接近警戒线（>5 需关注）。若未来增加节日折扣、地区限制等条件，极易突破 10。
改进方向

使用策略模式或规则引擎解耦判断逻辑，或将促销计算抽象为独立服务。
2. 嵌套深度（Nesting Depth）

定义

代码块的嵌套层级，如 if 中套 if，再套 for 或 try。每增加一层，理解成本呈指数上升。。推荐阈值：≤3 层，超过即应重构。
实际案例：“左箭头综合征”

1. public boolean processRefund(RefundRequest request) {
2.     if (request != null) {
3.         Order order = orderService.findById(request.getOrderId());
4.         if (order != null) {
5.             if (order.getStatus() == OrderStatus.PAID) {
6.                 PaymentRecord record = paymentService.findByOrder(order);
7.                 if (record != null) {
8.                     try {
9.                         RefundResult result = paymentGateway.refund(record);
10.                         if (result.isSuccess()) {
11.                             refundRepo.save(new Refund(record, SUCCESS));
12.                             return true;
13.                         } else {
14.                             log.error("Refund failed: {}", result.getMessage());
15.                             return false;
16.                         }
17.                     } catch (PaymentException e) {
18.                         log.error("Payment system error", e);
19.                         return false;
20.                     }
21.                 } else {
22.                     return false;
23.                 }
24.             } else {
25.                 return false;
26.             }
27.         } else {
28.             return false;
29.         }
30.     } else {
31.         return false;
32.     }
33. }

复制代码

嵌套达 6 层，阅读需不断“缩进-回退”，极易漏判条件。
改进方向

使用卫语句（Guard Clauses）提前返回

1. public boolean processRefund(RefundRequest request) {
2.     if (request == null) return false;
4.     Order order = orderService.findById(request.getOrderId());
5.     if (order == null || order.getStatus() != OrderStatus.PAID) return false;
7.     PaymentRecord record = paymentService.findByOrder(order);
8.     if (record == null) return false;
10.     try {
11.         RefundResult result = paymentGateway.refund(record);
12.         if (result.isSuccess()) {
13.             refundRepo.save(new Refund(record, SUCCESS));
14.             return true;
15.         } else {
16.             log.error("Refund failed: {}", result.getMessage());
17.             return false;
18.         }
19.     } catch (PaymentException e) {
20.         log.error("Payment system error", e);
21.         return false;
22.     }
23. }

复制代码

逻辑扁平化，可读性显著提升。
3. 方法长度 & 类长度

定义

• 方法长度：单个方法的代码行数（不含空行和注释）
  
• 类长度：单个类的总行数
  

经验阈值：

• 方法 ≤ 50 行
  
• 类 ≤ 500 行
  

超出即可能违反 单一职责原则（SRP）
实际案例：上帝方法

1. // 一个长达 320 行的 createOrder() 方法
2. // 包含：参数校验、库存扣减、价格计算、优惠应用、积分发放、消息推送、日志记录、异常重试……
3. public Order createOrder(CreateOrderRequest request) {
4.     // ... 320 行混合逻辑 ...
5. }

复制代码

• 无法单元测试所有路径
  
• 任何改动都可能引发未知副作用
  
• 新人完全看不懂执行流程
  

改进方向

1. public Order createOrder(CreateOrderRequest request) {
2.     validateRequest(request);                    // 校验
3.     InventoryResult inv = inventoryService.deduct(request); // 扣库存
4.     PriceCalculation calc = priceEngine.calculate(request); // 算价
5.     Order order = orderRepo.save(mapToEntity(request, calc)); // 保存
6.     rewardService.awardPoints(order);            // 发积分
7.     eventPublisher.publish(new OrderCreatedEvent(order)); // 发事件
8.     return order;
9. }

复制代码

每个步骤独立，便于替换、测试、监控。
4. 类级复杂度：CK Metrics 四大经典指标

在面向对象系统中，仅看行数和方法数量还不够。我们需要更精细的指标来评估一个类的设计质量。以下四个指标合称 CK Metrics Suite（Chidamber & Kemerer），是业界公认的类复杂度评估标准。
（1）WMC（Weighted Methods per Class）

类的方法圈复杂度加权和

• 含义：一个类中所有方法的圈复杂度之和
  
• 示例：若某类有 5 个方法，圈复杂度分别为 6、8、5、12、4，则 WMC = 35
  
• 危害：WMC 越高，表示该类整体逻辑密度大，维护和测试成本高
  
• 建议阈值：≤45，否则应考虑拆分
  

WMC 是对“类长度”的深化 —— 它不仅看有多少方法，更关注这些方法有多复杂。

（2）CBO（Coupling Between Object Classes）

类间耦合度

• 含义：一个类所依赖的外部类的数量
  
• 关联概念：你在“依赖复杂度”一节中提到的 Efferent Coupling（Ce） 本质上就是 CBO
  
• 危害：CBO 高 → 耦合强 → 变动牵一发而动全身，不利于复用
  
• 建议阈值：≤7
  

小结：CBO 和 Efferent Coupling 指标一致，只是术语来源不同。现代工具如 SonarQube 使用后者，但在学术和架构评审中，“CBO”仍是通用说法。

（3）RFC（Response for a Class）

类的响应集

• 含义：一个类能直接或间接响应的方法总数，包括自身方法 + 它调用的外部方法
  
• 示例：OrderService.create() 调用了 paymentService.pay() 和 rewardService.award()，则这两个调用也计入 RFC
  
• 危害：RFC 越大，表示该类的行为影响面越广，测试组合爆炸，理解成本上升
  
• 建议阈值：≤50
  

（4）LCOM（Lack of Cohesion in Methods）

方法间内聚性缺失

• 含义：衡量类中方法是否共享相同的字段。如果方法分为几组，各自操作不同的属性，则 LCOM 高
  

1. class User {
2.     private String name, email;
3.     private int loginCount;
4.     // updateProfile() 只用 name/email
5.     // incrementLogin() 只用 loginCount
6.     // → LCOM 高，说明职责不聚焦
7. }

复制代码

• 危害：LCOM 高 → 类缺乏内聚性 → 实际上承担了多个职责 → 应拆分
  
• 改进方向：识别方法访问的字段簇，按业务边界进行类拆分
  

5. 继承结构复杂度

当系统使用继承时，还需关注类层次结构本身的复杂性。
（1）DIT（Depth of Inheritance Tree）

继承树深度

• 含义：从当前类到根类的最大路径长度
  
• 示例：Animal → Mammal → Dog，Dog 的 DIT = 2
  
• 危害：DIT 越深，行为越难预测（父类逻辑隐式传递），调试困难
  
• 建议：DIT ≤ 3，过深应考虑改用组合
  

（2）NOC（Number of Children）

子类数量

• 含义：一个类的直接子类个数
  
• 危害：NOC 过大（如 >10）说明父类抽象不够通用，或继承体系设计不合理
  
• 改进方向：提取共性接口，或使用策略模式替代继承
  

6. 重复代码率（Duplication）

定义

系统中相同或高度相似代码块的比例。违背 DRY（Don't Repeat Yourself）原则。
实际案例：到处复制的签名逻辑

1. // 在 AlipayProcessor 中
2. String sign = DigestUtils.md5Hex(data + apiKey).toUpperCase();
4. // 在 WechatPayProcessor 中（一模一样）
5. String sign = DigestUtils.md5Hex(data + apiKey).toUpperCase();
7. // 在 UnionpayProcessor 中（还是一样）
8. String sign = DigestUtils.md5Hex(data + apiKey).toUpperCase();

复制代码

改进：提取公共服务

1. @Component
2. public class SignatureService {
3.     public String sign(String data, String key) {
4.         return DigestUtils.sha256Hex(data + key).toUpperCase();
5.     }
6. }

复制代码

总结

层级指标推荐阈值主要危害方法级圈复杂度≤10路径爆炸，难测试嵌套深度≤3可读性差方法长度≤50 行职责不清类级类长度≤500 行上帝类风险WMC≤45整体逻辑密度过高CBO / Ce≤7耦合高，难维护RFC≤50行为泛滥，测试难LCOM值越高越差内聚不足，应拆分继承级DIT≤3行为隐式传递NOC不宜过大抽象不充分重复代码DRY不宜过多不要重复自己复杂度评估工具

要打赢复杂度战争，光靠人工 Code Review 远远不够。我们需要一套自动化的评估体系，在开发、提交、构建、部署的每个环节持续监控代码质量。
以下是目前 Java 生态中主流的复杂度评估方案与工具框架，它们可以单独使用，也可集成形成完整的质量门禁体系。
1. SonarQube：行业标准的静态分析平台

SonarQube 是目前最广泛使用的代码质量管理平台，支持对圈复杂度、重复率、代码坏味、测试覆盖率等指标进行可视化分析和阈值控制。
核心能力：

• 自动计算每个方法的圈复杂度，并标记 >10 的热点
  
• 检测重复代码块，支持跨文件识别
  
• 提供“技术债”估算：修复所有问题需要多少人天
  
• 支持 Quality Gate（质量门禁）：CI 中断机制
  

集成方式：

1. <plugin>
2.     <groupId>org.sonarsource.scanner.maven</groupId>
3.     sonar-maven-plugin</artifactId>
4.     <version>3.9.1.2184</version>
5. </plugin>

复制代码

执行扫描：

1. mvn sonar:sonar \ -Dsonar.projectKey=my-app \ -Dsonar.host.url=http://localhost:9000 \ -Dsonar.login=your-token

复制代码

推荐规则集：

• cognitive-complexity：认知复杂度警告
  
• nested-if-else-depth：嵌套深度检测
  
• function-complexity：方法复杂度阈值
  
• duplicated-blocks：重复代码告警
  

2. IntelliJ IDEA 内置分析工具

IntelliJ 提供了强大的本地静态分析功能，开发者无需离开 IDE 即可发现复杂度问题。
由于 IDEA 迭代很快，使用方式各位开发同学可以自行搜索，
优点：即时反馈，适合在编码阶段预防问题。
3. PMD 与 Checkstyle：轻量级静态检查工具

两者常配合使用，用于 CI/CD 流水线中的自动化检查。
PMD 特点：

• 专注代码结构问题
  
• 内建规则：ExcessiveMethodLength, CyclomaticComplexity, NestedIfDepth
  

具体使用方式不展开描述了，大家可以自行查阅。
4. ArchUnit：架构层面的依赖约束

ArchUnit 允许你用 Java 代码定义架构规则，防止模块间非法依赖。
5. GitHub Actions / Jenkins 集成：将复杂度检查纳入 CI

通过 CI 脚本自动运行分析工具，实现“不达标不合并”。
GitHub Actions 示例：

1. name: Code Quality
2. on: [push, pull_request]
3. jobs:
4.   sonar:
5.     runs-on: ubuntu-latest
6.     steps:
7.       - uses: actions/checkout@v3
8.       - name: Set up JDK
9.         uses: actions/setup-java@v3
10.         with:
11.           java-version: '17'
12.       - name: Run SonarQube Analysis
13.         run: mvn verify sonar:sonar -Dsonar.qualitygate.wait=true
14.         env:
15.           SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
16.           SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}

复制代码

当质量门禁失败时，PR 将被阻断，强制开发者先修复问题。
总结

工具适用场景关键能力SonarQube团队级质量管控可视化 + 质量门禁IntelliJ个人开发阶段实时提示PMD / CheckstyleCI 自动化检查规则驱动ArchUnit架构治理依赖断言CI/CD 集成流程卡点强制合规面向低复杂度的代码最佳实践

知道什么是复杂度还不够，关键是如何在日常编码中主动降低它。本着面向代码最佳实践的原则，尝试总结几条有效降低代码复杂的 Best Practise
原则一：单一职责

一个类或方法应该只做一件事。职责越清晰，修改影响面越小。
反例：多功能服务类

1. @Service
2. public class OrderService {
3.     public void createOrder() { /* 创建 */ }
4.     public void sendNotification() { /* 发送通知 */ }
5.     public void calculateReward() { /* 计算积分 */ }
6.     public void logAudit() { /* 写审计日志 */ }
7. }

复制代码

这个类承担了订单生命周期的多个角色，任何变更都可能引发副作用。
改进：按职责拆分

1. @Service
2. public class OrderCreationService { ... }
4. @Service
5. public class OrderNotificationService { ... }
7. @Service
8. public class OrderRewardCalculationService { ... }

复制代码

职责分离后，各模块可独立测试、演进。
原则二：优先组合，而非继承

继承容易导致深层类层次结构，增加理解和维护成本。组合更灵活、更可控。
反例：继承滥用

1. class BasePaymentProcessor { }
2. class AlipayProcessor extends BasePaymentProcessor { }
3. class WechatPayProcessor extends BasePaymentProcessor { }
4. class HybridAlipayProcessor extends AlipayProcessor { } // 多层继承

复制代码

子类隐式继承父类行为，难以预测执行逻辑。
改进：使用策略模式 + 组合

1. public interface PaymentStrategy {
2.     PaymentResult pay(BigDecimal amount);
3. }
5. @Service
6. public class AlipayStrategy implements PaymentStrategy { ... }
8. @Service
9. public class WechatPayStrategy implements PaymentStrategy { ... }
11. // 组合使用
12. public class UnifiedPaymentService {
13.     private final Map<String, PaymentStrategy> strategies;
15.     public UnifiedPaymentService(Map<String, PaymentStrategy> strategies) {
16.         this.strategies = strategies;
17.     }
19.     public PaymentResult pay(String type, BigDecimal amount) {
20.         return strategies.get(type).pay(amount);
21.     }
22. }

复制代码

解耦清晰，扩展性强。
原则三：善用函数式编程减少状态污染

Java 8 引入的 Optional 和 Stream 不仅是语法糖，更是对抗复杂度的利器。
反例：消除 null 嵌套判断

1. // 传统写法：多层 if 判断
2. if (user != null) {
3.     Cart cart = user.getCart();
4.     if (cart != null) {
5.         List<Item> items = cart.getItems();
6.         if (items != null && !items.isEmpty()) {
7.             return items.stream().map(Item::getPrice).reduce(BigDecimal::add).orElse(ZERO);
8.         }
9.     }
10. }
11. return ZERO;

复制代码

改进：改为 Optional 链式调用

1. return Optional.ofNullable(user)
2.     .map(User::getCart)
3.     .map(Cart::getItems)
4.     .filter(items -> !items.isEmpty())
5.     .flatMap(items -> items.stream().map(Item::getPrice).reduce(BigDecimal::add))
6.     .orElse(ZERO);

复制代码

逻辑扁平化，无嵌套，可读性显著提升。
原则四：设计模式不是炫技，而是解耦武器

合理使用设计模式可以有效分解复杂逻辑，但切忌过度设计。
反例：if-else

1. // 反例：一堆 if-else
2. if ("alipay".equals(type)) {
3.     return alipayClient.pay(amount);
4. } else if ("wechat".equals(type)) {
5.     return wechatClient.pay(amount);
6. } else if ("unionpay".equals(type)) {
7.     return unionpayClient.pay(amount);
8. }

复制代码

改进： 合理的设计模式

1. @Component
2. public class PaymentRouter {
3.     private final Map<String, PaymentClient> clients;
5.     public PaymentRouter(List<PaymentClient> clientList) {
6.         this.clients = clientList.stream()
7.             .collect(Collectors.toMap(PaymentClient::getType, c -> c));
8.     }
10.     public PaymentResult pay(String type, BigDecimal amount) {
11.         PaymentClient client = clients.get(type);
12.         if (client == null) throw new UnsupportedPaymentTypeException(type);
13.         return client.pay(amount);
14.     }
15. }

复制代码

新增支付方式只需实现接口并注册 Bean，无需修改路由逻辑。
原则五：命名即文档，好名字胜过千行注释

变量、方法、类的命名应准确传达其意图，避免缩写和模糊词汇。
反例：含义不明的数值枚举

1. public List<Order> getList(int status) { ... } // status 是什么？1 表示成功？

复制代码

改进：明确的枚举

1. public List<Order> findOrdersByStatus(OrderStatus status) { ... }

复制代码

再如：

1. // 不清楚用途
2. private boolean flag;
4. // 明确语义
5. private boolean isEligibleForDiscount;

复制代码

清晰的命名能让代码自解释，大幅降低理解成本。
原则六：防御性编程 + 清晰的错误处理

提前拦截非法输入，明确异常路径，避免静默失败。
正例：使用卫语句提前返回

1. public Order createOrder(CreateOrderRequest request) {
2.     if (request == null) {
3.         throw new IllegalArgumentException("Request cannot be null");
4.     }
5.     if (request.getItems() == null || request.getItems().isEmpty()) {
6.         throw new IllegalArgumentException("Order must have items");
7.     }
8.     // 正常逻辑开始……
9. }

复制代码

正例：异常不要被吞掉

1. // 错误做法
2. catch (Exception e) {
3.     log.warn("Ignore error"); // 静默吞掉
4. }
6. // 正确做法
7. catch (PaymentTimeoutException e) {
8.     log.error("Payment system timeout", e);
9.     throw new OrderCreationFailedException("Payment failed due to timeout", e);
10. }

复制代码

确保异常传播路径清晰，便于定位问题。
小结：高质量代码的共同特征

原则关键动作效果单一职责拆分类与方法降低变更风险组合优于继承使用接口 + 注入提升灵活性函数式思维使用 Optional/Stream减少嵌套设计模式策略、工厂、责任链解耦复杂逻辑清晰命名表达业务意图自解释代码防御性编程提前校验 + 明确异常提高健壮性这些原则不是教条，而是在长期实践中总结出的经验。坚持使用，你会发现自己写的代码越来越干净，系统也越来越稳健。
总结：坚持做正确的事

我们回顾一下最初的那几个问题：

• 一个 catch (Exception e) 真的只是“防崩”吗？
  
• 一段重复的签名逻辑，值得花几分钟复制粘贴吗？
  
• 一个 2800 行的类，真的是“历史原因”无法改动吗？
  

答案从来都不是“代码本身有多难”，而是我们是否愿意为系统的长期健康付出短期成本。
优秀的程序员不追求炫技式的“高复杂架构”，而是坚持写低复杂度、高表达力的代码。他们知道，可维护性才是系统最核心的非功能需求。
工具可以帮助我们发现问题，原则可以指导我们重构代码，但最终，守护系统整洁的，是每一位工程师对质量的敬畏之心。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！