代码复用最佳实践：现代软件开发避坑指南

在软件工程领域，代码复用始终是提升开发效率与可维护性的核心手段，但实践中稍有不慎便会陷入过度抽象的困境。面试常问“如何消除重复代码”，日常开发也在不断提取公共逻辑。合理复用能显著降低维护成本，但盲目复用可能引入更高耦合与更复杂的系统结构。

园友@码农札记 一语中的：“复用是一把双刃剑，用得好能提升团队效率，用不好反而会拖累协作。”

为什么需要代码复用？

在深入讨论之前，先明确复用的根本价值：

• 提升开发效率：基于已验证的模块快速构建，避免重复造轮子
• 降低维护成本：一处修复，全局受益，减少bug传播范围
• 增强代码可靠性：经过充分测试的复用单元更稳定
• 保证逻辑一致性：消除业务规则在不同位置的“分歧”

代码复用的主流实现方式

函数/方法复用

最基础的复用形式，但提取时需讲究内聚性：

// 反例：验证逻辑重复
public void CreateUser(string email, string phone)
{
    if (string.IsNullOrEmpty(email) || !email.Contains("@"))
        throw new ArgumentException("邮箱格式错误");
    // 业务逻辑...
}

public void UpdateUser(string email, string phone)
{
    if (string.IsNullOrEmpty(email) || !email.Contains("@"))
        throw new ArgumentException("邮箱格式错误");
    // 业务逻辑...
}

// 正例：抽取独立校验方法
private void ValidateEmail(string email)
{
    if (string.IsNullOrEmpty(email) || !email.Contains("@"))
        throw new ArgumentException("邮箱格式错误");
}

public void CreateUser(string email, string phone)
{
    ValidateEmail(email);
    // 业务逻辑...
}

继承（Inheritance）

面向对象三大特性之一，适用于纯 is-a 关系。但继承是强耦合机制，滥用会导致“脆弱基类”反模式。优先考虑组合而非继承。

public abstract class DataExporter
{
    public abstract byte[] Export();

    public void LogExport() { Console.WriteLine($"导出 {this.GetType().Name} 数据"); }
}

public class PdfExporter : DataExporter
{
    public override byte[] Export()
    {
        // PDF 导出逻辑
    }
}

组合（Composition）

更灵活、推荐的复用方式。通过接口与依赖注入，实现运行时动态组合：

public interface ILogger
{
    void Log(string message);
}

public class FileLogger : ILogger { /* 实现 */ }
public class DbLogger : ILogger { /* 实现 */ }

public class OrderService
{
    private readonly ILogger _logger;
    // 构造函数注入，灵活切换日志实现
    public OrderService(ILogger logger) { _logger = logger; }
}

泛型（Generics）

类型安全的复用，消除类型重复代码。例如通用仓储接口：

// 无需为每个实体编写独立的仓储
public interface IRepository where T : class
{
    T GetById(int id);
    IEnumerable GetAll();
    void Add(T entity);
}

模板方法模式

定义算法骨架，子类实现可变步骤：

public abstract class DataProcessor
{
    // 模板方法
    public void Process()
    {
        LoadData();
        ProcessData();
        Sa veResult();
    }

    protected abstract void LoadData();
    protected abstract void ProcessData();
    protected virtual void Sa veResult() { }
}

复用的陷阱：何时应避免复用？

这部分才是关键。并非所有重复代码都值得提取，经验丰富的开发者深有体会。

陷阱一：过早抽象

“不要为明天写代码，只为今天设计。” 如果未来需求不明确，切勿强行合并两段“看起来相似”的代码。它们可能沿不同方向演化，过早复用将导致每次修改都牵一发而动全身。

陷阱二：上下文耦合的“公共”方法

// 看似通用的校验方法
public void ValidateAndProcess(string input, bool isAdmin, bool isNewUser)
{
    // 根据多个标志位执行不同分支逻辑
    // 方法内部充斥着 if-else
}

当公共方法需要不断添加布尔参数来区分行为时，说明它根本就不是公共逻辑。靠多个状态参数驱动的方法本身就是坏味道。

陷阱三：跨越领域边界的复用

不同模块、不同限界上下文之间的复用要格外谨慎。看似相同的“用户”概念，在订单上下文与权限上下文中可能承载截然不同的业务规则。强行复用只会加剧系统耦合，破坏领域模型的内聚性。

代码复用的原则与最佳实践

正确理解DRY

DRY（Don't Repeat Yourself）的核心不是“杜绝重复代码”，而是“每份知识在系统中只有单一、明确的表示”。两段代码即使字符相同，若代表不同业务含义，就不该合并。就像两个人穿同款衣服，不能因外表相同就认定他们是同一人。

复用三问

在提取公共逻辑前，先自问：

• 变化方向是否一致？ 若未来修改原因不同，别放在一起。
• 是否存在真正的业务共性？ 还是仅仅偶然相似？
• 复用边界是否清晰？ 公共模块的职责是否单一？

实践建议

案例：过度复用的“受害者”

去年团队重构遗留系统，发现一个名为 CommonHelper 的类长达3000多行。邮件发送、日志记录、数据校验、加密解密、Excel导出等职责全混在一起，几乎所有模块都依赖它。每次修改都会触发连锁故障。重构策略很简单：按单一职责拆分为 EmailService、LoggingService、ValidationService 等服务，通过接口组合。两周后，系统的可测试性与可维护性显著提升。

教训：复用 ≠ 大杂烩。被过多地方依赖的类，往往已经承载了过多职责。

总结

代码复用是一把双刃剑。行业共识可归纳为：

• 三次法则（Rule of Three）：同一段代码出现三次再考虑抽象
• 组合优于继承：保持低耦合
• 明确边界：不同上下文勿强行复用
• 保持简单：若复用带来的复杂性超过效益，宁可暂时重复

最后，以园友的一句话收尾：

“代码复用的目标不是写更少的代码，而是让每行代码都更容易理解和维护。”