现代软件开发代码复用：最佳实践与常见陷阱

在软件开发领域，代码复用始终是开发者们反复探讨的核心议题。无论是面试中被问及“如何避免重复代码”，还是日常工作中为提炼公共逻辑而费尽心思，这几乎已成为每位程序员的必修技能。合理运用代码复用，确实能大幅提升开发效率、降低后期维护成本，然而若不加节制，也容易陷入“过度复用”的陷阱。

正如园友@码农札记 所言：“复用是银弹，但银弹也会误伤队友。”

为何要追求代码复用？

在深入探讨具体方法之前，不妨先简要回顾一下代码复用的核心价值：

• 提升开发效率：借助已有成果，避免重复造轮子
• 降低维护成本：修复一处漏洞，所有使用处同时受益
• 增强代码质量：经过充分测试的复用模块通常更稳定可靠
• 保持行为一致：相同的业务逻辑不会在不同位置“走样”

常用的代码复用方式

函数 / 方法复用

这是最基础也最直接的复用形式，但在实现时也有讲究：

// 不推荐的做法：存在重复的验证逻辑
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）

作为 OOP 三大特性之一，继承适合表示 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）

提供类型安全的复用，避免为不同数据类型重复编写相同逻辑。例如通用 Repository 接口：

// 无需为每个实体类型单独编写 Repository
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() { }
}

复用的陷阱：何时不该复用？

这才是本文的重点。并非所有重复代码都值得复用，踩过坑的人对此深有体会。

陷阱一：过早复用

“Don't write code for tomorrow, write code for today.” 如果对未来的需求不确定，就不要轻易将两段“看起来相似”的代码强行合并。它们未来可能朝不同方向演化，强行复用只会让后续修改变得异常痛苦。

陷阱二：上下文耦合的复用

// 看似公共的验证方法
public void ValidateAndProcess(string input, bool isAdmin, bool isNewUser)
{
    // 根据各种标志位执行不同的逻辑
    // 天哪，这个方法内部已经充满了 if-else
}

当公共方法需要越来越多的“模式切换”参数时，说明它已经不再是真正的公共逻辑。一个方法依赖多个布尔值来区分行为，本身就是代码坏味道。

陷阱三：跨越边界的复用

不同模块、不同服务、不同限界上下文（bounded context）之间的复用必须格外谨慎。看似相同的“用户”概念，在订单上下文中与权限上下文中可能包含截然不同的业务规则。强行复用只会导致系统耦合度急剧攀升。

复用的原则与最佳实践

DRY 的正确理解

DRY（Don't Repeat Yourself）并非“不写重复代码”，而是“每一片知识在系统中只有单一、明确、权威的表达”。即使两段代码字面相同，若其代表不同的业务含义，就不应强行复用。就像两个人穿着同款衣服，但一个是因为工作需要，一个是因为个人喜好，不能因为穿着相同就把他们视为同一人。

复用三问

在抽取公共逻辑之前，先问自己三个问题：

• 变化方向是否一致？ 如果未来修改的原因不同，就不要放在一起。
• 是否存在真正的业务共性？ 还是仅仅目前巧合地相似？
• 复用的边界是否清晰？ 公共模块的职责是否单一？

实践建议

案例分享：一个过度复用的“受害者”

去年团队接手了一个遗留系统，发现一个名为 CommonHelper 的类竟然有 3000 多行代码。邮件发送、日志记录、数据校验、加密解密、Excel 导出……几乎所有业务都依赖它。结果每次修改这个类，都会引发一连串意想不到的问题。重构方案很简单：按职责拆分为 EmailService、LoggingService、ValidationService 等独立服务，并通过接口进行组合。经过两周的拆分，系统的可测试性与可维护性都得到了大幅提升。

教训深刻：复用 ≠ 大杂烩。一个类被过多地方依赖，恰恰说明它可能承担了过重的职责。

总结

代码复用是一把双刃剑，用好了事半功倍，用滥了反受其害。行业共识可归纳为以下几点：

• Rule of Three：同一段代码出现三次再考虑抽象
• 组合优于继承：保持低耦合
• 明确边界：不同上下文不要强行复用
• 保持简单：如果复用带来的复杂性超过了它的价值，那就别复用

最后，借用园友的一句话结束本文：

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