我们是如何用AOP、IoC和设计模式拯救祖传代码的

去年接手了一个"祖传"项目，代码写于2015年，经过20多位程序员的"精心呵护"，已经进化成了一坨谁都不敢动的意大利面。最夸张的是，有个Service类居然有8000多行，构造函数要传37个参数！

老板说："这系统太难维护了，但不能推倒重来，你们想办法重构一下。"看着这坨代码，我差点当场辞职。但最终，我们用了3个月时间，通过引入AOP、IoC容器和合理的设计模式，把这个项目从地狱拉回了人间。

噩梦的开始：祖传代码有多可怕

先给大家看看重构前的代码是什么样的：

public class UserService {
    private DBConnection dbConnection;
    private LogWriter logWriter;
    private CacheManager cacheManager;
    private EmailSender emailSender;
    // ... 还有30多个依赖
    
    public UserService() {
        this.dbConnection = new MySQLConnection("localhost", 3306, "root", "123456");
        this.logWriter = new FileLogWriter("/var/log/app.log");
        this.cacheManager = new RedisCacheManager("localhost", 6379);
        this.emailSender = new SMTPEmailSender("smtp.gmail.com", 587);
        // ... 初始化其他30多个依赖
    }
    
    public User getUserById(String userId) {
        // 记录日志
        logWriter.write("Getting user: " + userId);
        long startTime = System.currentTimeMillis();
        
        try {
            // 检查缓存
            User cachedUser = (User) cacheManager.get("user_" + userId);
            if (cachedUser != null) {
                logWriter.write("Cache hit for user: " + userId);
                return cachedUser;
            }
            
            // 查询数据库
            User user = dbConnection.executeQuery("SELECT * FROM users WHERE id = ?", userId);
            
            // 放入缓存
            cacheManager.put("user_" + userId, user, 3600);
            
            // 记录性能日志
            long endTime = System.currentTimeMillis();
            logWriter.write("Get user took: " + (endTime - startTime) + "ms");
            
            return user;
        } catch (Exception e) {
            logWriter.write("Error getting user: " + e.getMessage());
            emailSender.send("admin@company.com", "Error in UserService", e.toString());
            throw e;
        }
    }
    
    // 还有200多个这样的方法...
}

看到这代码，我统计了一下问题：

控制反转(IoC)：解开耦合的第一步

什么是控制反转？

简单说，就是把"创建对象"的控制权交出去。以前是自己new，现在让容器帮你创建和管理。

重构第一步，我们引入了Spring IoC容器：

@Service
public class UserService {
    private final UserRepository userRepository;
    private final CacheManager cacheManager;
    
    @Autowired
    public UserService(UserRepository userRepository, CacheManager cacheManager) {
        this.userRepository = userRepository;
        this.cacheManager = cacheManager;
    }
    
    public User getUserById(String userId) {
        return userRepository.findById(userId);
    }
}

IoC带来的改变

引入IoC后的效果对比：

依赖注入(DI)：IoC的具体实现

三种注入方式对比

我们尝试了不同的依赖注入方式：

循环依赖问题

使用DI时遇到的最大坑就是循环依赖：

// A依赖B，B依赖A，Spring启动失败！
@Service
public class ServiceA {
    @Autowired
    private ServiceB serviceB;
}

@Service  
public class ServiceB {
    @Autowired
    private ServiceA serviceA;
}

解决方案和效果：

面向切面编程(AOP)：优雅处理横切关注点

AOP解决了什么问题？

原来的代码里，每个方法都要写日志、处理事务、检查权限，代码重复得令人发指。AOP让我们能够把这些"横切关注点"抽离出来。

实施AOP前后的代码对比：

// Before: 业务逻辑淹没在各种非业务代码中
public User getUserById(String userId) {
    // 权限检查
    if (!hasPermission(userId)) {
        throw new UnauthorizedException();
    }
    
    // 记录日志
    logger.info("Getting user: " + userId);
    long startTime = System.currentTimeMillis();
    
    // 开启事务
    Transaction tx = transactionManager.beginTransaction();
    
    try {
        User user = userRepository.findById(userId);
        tx.commit();
        
        // 性能日志
        long endTime = System.currentTimeMillis();
        logger.info("Operation took: " + (endTime - startTime) + "ms");
        
        return user;
    } catch (Exception e) {
        tx.rollback();
        logger.error("Error: " + e.getMessage());
        throw e;
    }
}

// After: 只关注核心业务
@Transactional
@PreAuthorize("hasPermission(#userId)")
@LogExecution
public User getUserById(String userId) {
    return userRepository.findById(userId);
}

AOP切面统计

我们创建的主要切面：

AOP性能开销

很多人担心AOP的性能开销，我们做了详细测试：

结论：AOP的性能开销几乎可以忽略不计。

单例模式：不是所有东西都要new

单例模式的演进

项目里有些重量级对象（如连接池、配置管理器）被到处new，既浪费资源又容易出问题。我们逐步改造成单例：

Spring中的单例

在Spring容器中，Bean默认就是单例的。我们统计了单例化的效果：

单例模式的坑

但单例也不是万能的，我们踩过的坑：

综合使用：架构的蜕变

重构后的架构

经过3个月的重构，整个项目架构焕然一新：

原架构：
UserController -> UserService(8000行) -> 直接JDBC

新架构：
UserController 
    ↓ (AOP: 日志、权限)
UserService (业务逻辑)
    ↓ (AOP: 事务、缓存)  
UserRepository (数据访问)
    ↓
数据库

所有组件通过IoC容器管理，依赖注入

重构效果数据

团队反馈

更重要的是团队的变化：

经验总结

1. 渐进式重构

不要试图一次改完，我们的策略：

• 第1个月：引入IoC容器，解耦依赖
• 第2个月：应用AOP，消除重复代码
• 第3个月：优化设计模式，提升代码质量

2. 不要过度设计

3. 性能不是借口

很多人说"设计模式影响性能"，但实测证明：

• 良好的设计带来的维护性提升远大于微小的性能损失
• 很多时候，好的设计反而提升了性能（如缓存切面）
• 真正的性能瓶颈往往在IO，不在这些框架开销

写在最后

这次重构经历让我深刻理解了Martin Fowler的话：“任何傻瓜都能写出计算机能理解的代码，但只有优秀的程序员才能写出人类能理解的代码。”

AOP、IoC、设计模式，这些不是为了炫技，而是为了让代码更容易理解、修改和维护。当你的同事（包括三个月后的自己）能轻松理解并修改你的代码时，这些技术就值了。

最后想说，重构祖传代码确实很痛苦，但看到整个系统焕发新生，团队重拾信心，这种成就感是无法替代的。如果你也在维护祖传代码，不要绝望，制定好计划，一步步来，总能看到曙光的。

记住：优秀的代码是重构出来的，不是一次写成的。