编程与软件工程programmingisterrible.com编辑精选
写容易删除的代码，而不是容易扩展的代码
Write code that is easy to delete, not easy to extend
2016 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇经典博文主张：写代码时应优先考虑“容易删除”，而不是一开始就设计成“容易扩展”。它认为重复、直白的实现可以先接受，但每轮迭代都要清理；过早追求 DRY 和模块化会制造错误抽象，把约束散落到各处。真正的抽象应来自对实际变化的观察，而不是对未来扩展的猜测。
为什么经久不衰：它把“先让代码工作、再从实际变化中提炼抽象”讲得具体，提醒我们别为想象中的未来扩展付出高昂维护代价。
HN 评论精选
先允许重复和混乱，再在看清模式后清理；过早去重会制造错误抽象。
诀窍归根结底是：先乱写，但要清理。如果你不做每一对里的后半部分（复制粘贴 / 不要复制粘贴），最终会得到无法维护的烂摊子；如果太早做后半部分，就会得到错误的抽象。Sandi Metz 也谈过这个问题。
netghost查看英文原文
The trick really boils down to: be messy, but clean up. If you don't do the second half of each thing (copy and paste / don't copy and paste), then you end up with that unmaintainable mess. If you do the second part too early, you end up with the wrong abstraction. Sandi Metz also talks about this: http://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction
匆忙开发会跳过试错直接抽象，导致错误抽象和企业框架臃肿。
我觉得这凸显了开发匆忙（或感觉匆忙）时的一个常见问题。你要么让开发者只完成每一对中的前半部分（重复自己、一团泥等），没时间在每次迭代中清理；要么让开发者直接追求后半部分（DRY、模块化等）却没做前半部分，于是得到毫无意义的抽象、为追求 DRY 在共享函数里产生的过度复杂交互等。后一种情况也促成了很多“企业级”单体框架（如 Spring）：框架强加一套预先确定的架构，一旦深入处理古怪边界情况，开发者就只能打补丁，或者框架为了覆盖常见情况而膨胀。
lostcolony查看英文原文
I think this highlights a common issue when development is (or feels) rushed. You either end up with developers having only done the first part of each of these pairs (repeating themselves, ball of mudding, etc), without time to clean up as part of each iteration, or, you find developers immediately shooting for the latter half of each pair (DRY, modular, etc) without having done the former, and so you get abstractions that make no sense, overly complex interactions in a shared function as they attempt to be DRY, etc. This latter is also, I feel, what informs a lot of the monolithic frameworks used for 'enterprise' development, Spring and the like, where a predetermined architecture and structure of the app is imposed by the framework, and which leads to, once you get down in the weeds of dealing with odd edge cases and things, hackery on the part of the developer, or framework bloat if the framework attempts to address the most frequent of those cases.
“易删除”可追溯到 Parnas 的扩展与收缩思想，核心是移除局部而不影响其他部分。
这其实是扩展最初理念的一部分。David Parnas 在 1970 年代推广该术语的论文题为《为易于扩展和收缩而设计》，其中“易于收缩”指可子集化，即删除代码的一部分而不必改动其他部分。这些原始论文很值得一读！
kqr查看英文原文
This was part of the initial idea of extension. David Parnas' 1970's paper that popularised the term was called Designing for the Ease of Extension and Contraction where "ease of contraction" refers to subsettability, i.e. removing parts of the code without having to change other parts. These original papers are well worth a read!
易删代码会逐渐演化成难删代码，最终反而阻碍替换。
这条（非常好的）建议有个不幸的副作用：所有容易删除的代码最终都会被替换成难以删除的代码，因此最终会变得无法删除，也就无法再替换成更好的东西。
flohofwoe查看英文原文
The unfortunate side effect of this (very good) advice is that all code that's easy to delete will eventually be replaced with code that's hard to delete (and thus will eventually be impossible to delete in order to be replaced with something better).
历次讨论
同类还值得读
开源应用架构
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编辑精选