编程与软件工程sandimetz.com编辑精选
错误的抽象（2016）
The Wrong Abstraction (2016)
2016 — 2026，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Sandi Metz 的经典文章《错误的抽象》：当两段相似代码被过早合并成一个抽象后，需求分叉时人们往往往抽象里加参数和条件分支，导致代码越来越难懂。她主张遇到这种情况应先复制代码、让重复各自演化，等真正的共性显现后再重新提取抽象。
为什么经久不衰：它挑战了 DRY 这条被奉为金科玉律的原则，指出错误的抽象比重复代码代价更高，十年来反复登上 HN 首页，至今仍是关于何时抽象、何时容忍重复的必读参考。
HN 评论精选
提出 State > Coupling > Complexity > Duplication 的优先级排序，重复是四者中最不重要的。
我按减少状态、耦合、复杂度和代码量这四点来优化代码，顺序很重要：我愿意为了减少状态而增加耦合，为了减少耦合而增加复杂度，为了降低复杂度而容忍重复代码。只有在不增加前三者的情况下才去重代码。
gadrev查看英文原文
I found the following comment very insightful in a past discussion: https://news.ycombinator.com/item?id=11042400 I reproduce the relevant part: Dependencies (coupling) is an important concern to address, but it's only 1 of 4 criteria that I consider and it's not the most important one. I try to optimize my code around reducing state, coupling, complexity and code, in that order. I'm willing to add increased coupling if it makes my code more stateless. I'm willing to make it more complex if it reduces coupling. And I'm willing to duplicate code if it makes the code less complex. Only if it doesn't increase state, coupling or complexity do I dedup code. State > Coupling > Complexity > Duplication. I find that to be a very sensible ordering of concerns to keep in mind when addressing any of those.
提取抽象的真正代价是引入耦合，跨项目共享公共代码尤其要谨慎。
一方面，共享的代码行未必共享同一个想法，不应据此提取抽象；另一方面，当存在清晰、定义良好的共同职责时才值得引入抽象。但即使如此，提取公共依赖也可能让原本不相关的东西产生耦合——如果不同项目变更节奏和质量要求不同，这种耦合可能弊大于利。
shoo查看英文原文
Yup. On the one hand, often there can be shared lines of code without a shared idea, this shouldn't be a candidate for being factored out into some new abstraction. On the other hand, you may want to introduce an abstraction and factor out code into a common library / dependency / framework when there's a shared well-defined concern/responsibility. That said, on the gripping hand, I say may because even if there's the opportunity to introduce a clean future-proof abstraction, introducing it may be at the cost of coupling two things that were not previously coupled. If you've got very good automated test coverage and CI for the new common dependency and its impact upon the places it is consumed, then perhaps this is fine. If the new common dependency is consumed by different projects with different pressures for change / different rates of change / different levels of software quality then factoring out a common idea that then introduces coupling may cause more harm than good.
澄清原文观点：问题不在于过早抽象，而在于抽象过时后仍硬撑着复用它。
我觉得有些评论误解了这篇文章。Sandi Metz 并不是说在看到重复时引入抽象是错的，她说的问题出在后面：当你想复用一个已经过时、不再有用的抽象时。这与她一贯主张的大胆而有条理地重构是一致的。
Tainnor查看英文原文
I feel some people here are misunderstanding the blog post. Sandi Metz IMHO doesn't claim that the problem occurs at step 2 or 3. She doesn't claim that it's wrong to introduce abstraction when there is duplication. What she is saying instead is that the problem occurs from step 6 onwards: when you find yourself wanting to reuse an abstraction that, regardless of whether it made sense in the first place or not, has outlived its usefulness. I think this is in agreement with other points that she often makes, about being bold, but methodical about refactorings. The whole discussion about "you should never abstract away code before you see the third duplication" has little to do with the article, and I'm also really not sure it's good advice.
抽象/重复之争的根源是开发者心态：先想后做 vs 只求快速交付。
随着经验增长，我发现关键区别不在抽象与重复之间，而在开发者的心态之间：有人把开发当成'赶紧把事做完'，快速产出代码关掉工单；而更正确的做法是把开发当作脑力劳动，先思考设计再动手。有了足够的思考，抽象与重复的取舍自然不再是难题。
leto_ii查看英文原文
As I gain more and more experience (I would now call myself more or less a mid-level developer), I find that the distinction that matters is not abstraction vs duplication, but the one between developer mindsets. I have many times met/worked with people who think the main task of the developer is to 'get shit done'. Regardless of their level of experience, these developers will churn out code and close tickets quite fast, with very little regard for abstraction, design, code reuse etc. Conversely, the approach that I feel more and more is the correct one is to treat development as primarily a mental task. Something that you first think about for a while and try to design a little. The actual typing will in this case be a secondary activity. Of course, this doesn't mean you shouldn't iterate on your design if during execution problems come up. Just that the 'thinking' part should come before the 'doing'. My feeling is that with this second approach the abstraction/duplication trade-off will not matter so much anymore. With enough experience you will figure out what you can duplicate and what you can design. And when you design you will develop an understanding of how far you should go. Approaching development as a task of simple execution I think inevitably leads to illegible spaghetti down the line.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选