编程与软件工程folklore.org编辑精选
负 2000 行代码（2004）
-2000 Lines of code (2004)
2024 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇来自 folklore.org 的苹果早期轶事：Bill Atkinson 在精简代码、删掉约 2000 行后，面对每周代码行数报表，直接填了“-2000”。故事用一个小插曲挑战了把代码行数当作产出的管理惯例，说明删代码也可以是重要的工程进步。
为什么经久不衰：它戳中软件工程里一个经久不衰的误区：代码是成本而非资产，最好的代码往往是从未写过的代码，因此每次重上首页都能引发共鸣。
HN 评论精选
用亲身经历说明大规模删代码可以带来算法和架构上的巨大收益。
我最棒的提交之一是删掉约 6 万行代码：那是 2000 年代初的一个完整“服务器”，所有状态都得放在内存里；我把它换成了约 5000 行逻辑，轻量到可以挂进另一个服务，而且完全没有内存状态。这是纯粹的算法胜利——我发现某种特定的有导向子图同构（目标是一棵树：有向无环、只有一个根）可以只通过一次遍历原始的有向二部图来完成，同时向输出树发出顶点和边，只需在进程内维护一个小的可窥视栈，记录从根出发、可能影响当前生成步骤的路径。我至今记得那个“-60000 行（左右）”的庞然大物提交，那是我推过最好的提交。
bironran查看英文原文
One of my best commits was removing about 60K lines of code, a whole "server" (it was early 2000's) with that had to hold all of its state in memory and replacing them with about 5k of logic that was lightweight enough to piggyback into another service and had no in-memory state at all. That was pure a algorithmic win - figuring out that a specific guided subgraph isomorphism where the target was a tree (directed, non cyclic graph with a single root) was possible by a single walk through the origin (general) directed bi-graph while emitting vertices and edges to the output graph (tree) and maintaining only a small in-process peek-able stack of steps taken from the root that can affect the current generation step (not necessarily just parent path). I still remember the behemoth of a commit that was "-60,000 (or similar) lines of code". Best commit I ever pushed. Those were fun times. Hadn't done anything algorithmically impressive since.
复制粘贴式开发导致代码膨胀和 bug 重复，删掉四分之三代码库才解决问题。
大学时我在一家公司工作，他们的目标是想证明自己的管理方法能让一群大一新生写出高质量代码。他们没做到。我会找到导致 bug 的代码并修好，却发现 bug 还在，因为之前的学生不是给函数加参数，而是复制一份再稍微改改。那年秋天我删掉了他们大约四分之三的代码库（数千行 Turbo Pascal）。 bonus：客户是美国能源部，这个程序管理核材料库存。安心睡吧。
jfengel查看英文原文
In college I worked for a company whose goal was to prove that their management techniques could get a bunch of freshman to write quality code. They couldn't. I would go find the code that caused a bug, fix it and discover that the bug was still there. Because previous students had, rather than add a parameter to a function, would make a copy and slightly modify it. I deleted about 3/4 of their code base (thousands of lines of Turbo Pascal) that fall. Bonus: the customer was the Department of Energy, and the program managed nuclear material inventory. Sleep tight.
清理功能开关应算功能工作的一部分，而不是被归入技术债。
我现在算是公司里主要负责删代码的人。部分是因为我在团队待得最久，既有知识也有底气说某个功能已经死了、可以删掉；部分是因为上线后清理发布开关这类事总得有人做。我想让团队养成这个习惯，但很难。倒不是有人反对，而是“清理功能开关”总被扔进技术债堆。在我看来那是功能工作，只不过发生在上线之后而不是之前。既然当初决定做这个功能时就承诺了这项工作，那它就不该被当成开发中冒出来的意外问题放进技术债看板。我有时担心自己太教条，想听听别人的看法。
dml2135查看英文原文
I've become something of the guy that's the main code remover at my current job. Part of it is because I've been here the longest on the team, so I've got both the knowledge and the confidence to say a feature is dead and we can get rid of it. But also part of it is just being the one to go in and clean up things like release flags after they've gone live in prod. I'm trying to socialize my team to get more in the habit of this, but it's been hard. It's not so much that I get pushback, it's just that tasks like "clean up the feature flag" get thrown into the tech debt pile. From my perspective, that's feature work, it just happens to take place after the feature goes live instead of before. But it's work that we committed to when we decided to build the feature, so no, you don't get to put it on the tech debt board like it was some unexpected issue that came up during development. Curious to hear other perspectives here, I do worry that I'm a bit too dogmatic about this sometimes. Part of it maybe comes from working in shared art / maker spaces a lot in the past, where "clean up your shit" was rule #1, and I kind of see developers leaving unused code throughout the codebase for features they owned through the same lens.
代码是昂贵的手段而非资产，解决问题比写代码更重要。
这里有个更深的教训：有人把代码行数当成了资产而不是成本。写代码的初级程序员也常犯这个错。这个教训对我们爱写代码的人很残酷，至少对我如此：代码是达成目的的手段，而且很昂贵。最好的代码是从未写过的代码。我们的工作是解决问题，不是写代码。你可以把代码行数当作粗略的进度指标，就像用用了多少吨混凝土来衡量建摩天楼的进度一样。
hyperman1查看英文原文
There is a deeper lesson here: Someone was thinking of lines of code as an asset, not a cost. It's a an error you also see in junior programmers writing reams and reams of code. The lesson is a harsh one for us code lovers, at least it was for me: Code is a means to an end, and an expensive one at that. The best code is the code never written. Our job is to solve problems, not to write code. You can use LOC as a crude measure of progress, in the same way as tons of concrete used is a crude measure of progress when building a skyscraper.
历次讨论
同类还值得读
开源应用架构
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编辑精选