何时适合复制粘贴微调代码而非composition？行业现状及转换时机

1. 何时更适合复制粘贴微调代码 #

• 线上紧急bug修复：生产环境出问题时，重构代码（比如搞组合模式）得花时间写逻辑、测用例，远不如复制现有可用代码改点关键参数快速上线靠谱。先把故障解决，事后再回头收拾技术债。
• 表面相似但核心逻辑差异大：两段代码看起来结构像，但业务规则、边界条件、依赖的系统完全不同，强行抽象成通用模块会导致代码堆满分支判断，反而越改越乱。比如电商订单退款和会员退费，虽然都叫“退款”，但计算规则、审核流程、异常处理天差地别，各自实现反而更清晰。
• 原型/快速验证阶段：做产品原型、功能demo时，优先追求快速落地，不用纠结长期维护。复制现有代码微调能最快验证需求可行性，等需求确定后再重构也不迟。
• 依赖不可修改的外部代码：如果要复用的代码来自第三方库、老系统且没法改，复制出来做适配性修改，比费劲搭一层复杂的适配组合要高效得多。

2. 复制粘贴策略的行业现状与切换时机 #

复制粘贴微调是行业里非常普遍的操作，尤其是在快速迭代的创业团队、业务压力大的项目中，为了赶进度，很多开发者都会选这种“先解决问题再说”的方式。但这本质是短期妥协，攒多了就是技术债。

该改用其他方案的时机：

• 重复代码出现第三次时：遵循“三次法则”——第一次写、第二次复制还能忍，第三次再出现就必须抽象成通用模块（比如组合类、工具函数、基类），不然以后改一处要改N份，容易漏还费时间。
• 业务进入稳定维护阶段：当功能需求不再天天变，项目进入长期维护期，就得开始整理技术债，把之前复制粘贴的重复代码重构为可复用结构，降低后续维护成本。
• 需要统一修改逻辑时：比如要给某段逻辑加全局日志、改校验规则、适配新依赖，要是有好几份复制的代码，改起来不仅麻烦还容易漏，这时候必须重构。
• 团队推行代码规范时：当团队开始重视代码质量、制定规范，消除重复代码会是重点工作之一，这时候就得把复制粘贴的代码替换成合适的设计模式或复用方案。

内容的提问来源于stack exchange，提问作者Developer700