重复代码比错误的抽象更廉价，应优先选择重复而非错误的抽象。程序员常因看到重复而提取抽象，但这可能带来更严重的问题。

文章核心观点：警惕“错误抽象”的陷阱

本文作者Sandi Metz基于自身经验，揭示了软件开发中一个常见但代价高昂的问题——“错误抽象”。她指出，程序员在发现代码重复时，往往会提取出抽象（如方法或类），但随着时间的推移，当新需求出现时，原有抽象可能不再完全适用。此时，程序员为了保留已有抽象，会通过添加参数和条件逻辑来“修补”代码，导致抽象逐渐偏离初衷，最终变得复杂、难以理解和维护。

作者强调，重复代码的成本远低于错误的抽象。面对这种情况，最有效的策略不是继续在错误抽象上“打补丁”，而是“退一步”：将抽象代码重新内联回调用处，删除不必要的部分，让每个调用者只保留自己需要的代码。这不仅能消除抽象和条件逻辑，还能为重新提取更合理的抽象提供清晰的基础。

文章最后提醒，不要被“沉没成本谬误”所困——不要因为已经投入了大量精力而强行保留错误的抽象。当抽象被证明错误时，及时放弃并重新设计，才是更高效的前进方式。

根据评论内容，主要围绕“代码重复与错误抽象”的权衡展开讨论，观点呈现明显分歧：

支持“代码重复优于错误抽象”的观点（评论12、23、24、27）： - “it’s far easier to work with an under engineered code base than an over engineered one”（评论12） - “Overengineering, abstractions and premature optimisation are the 3 worst plagues of engineering”（评论23） - 评论27通过实际案例说明：为消除重复而强行抽象，导致3周重构不如1天复制代码高效

反对过度重复、主张合理抽象的观点（评论14、20、30）： - “any abstraction you can maintain is better than code duplication once you are past a de minimis threshold”（评论14） - “I’d rather refactor bad abstraction than 10x duplication”（评论20） - 评论30强调“single source of truth”原则：当重复代码存在“不同步即产生bug”的耦合时，必须抽象

平衡性观点（评论28、11、19）： - “Part of being a good engineer is finding the right balance”（评论28） - 评论11区分两类抽象：消除重复的底层抽象（易回退）与“架构宇航员”式顶层抽象（风险高） - 评论19提出关键判断标准：需区分“偶然重复”（如两个税种用相同公式）与“本质重复”（如物理公式在多处使用）

实践警示（评论7、26、29）： - 评论7描述强制抽象导致系统崩溃的教训 - 评论26指出“复制粘贴”策略可能被滥用于制造技术债 - 评论29警告：95%声称“先重复后抽象”的团队最终不会进行后续重构