历史与人物folklore.org编辑精选
负 2000 行代码
-2000 Lines of Code
2014 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 folklore.org 上 Andy Hertzfeld 记录的一则苹果 Macintosh 开发轶事：Bill Atkinson 被问到写了多少行代码时，回答“-2000 行”，因为他通过删减和简化，让 QuickDraw 净减少了约两千行代码。故事借此讽刺把代码行数当成生产力指标的荒谬。
为什么经久不衰：用一个简短有力的真实轶事说明代码行数（LOC）无法衡量软件工作的价值，几十年来对工程管理与绩效评估始终有启发。
HN 评论精选
用物流课上的例子说明把单一指标套到人身上是过度推广。
前几天在物流课上，教授跑题到我以为是胡说八道的内容。他先分析一台机器每天能生产多少件，还算合理，又扩展到不同的产能比率。然后他试图把这个模型推广到所有机器，包括人。他的例子是：“你怎么衡量一个法务团队的能力？”我以为这是陷阱题，就回答（大意）：“不能用衡量机器的方式回答，你给不出单一指标。”他说我错了，正确的衡量方式是每天总工作小时数。我本想反驳，这个类比漏洞百出——他衡量机器用件/天，衡量法务团队却用小时/天；分析机器时考虑效率，对人却不这么做。我觉得这正是那篇文章里发生的事：管理者、物流学者、经济学家特别容易掉进这种过度推广的陷阱。
josalhor查看英文原文
Just the other day I was in my logistics class and the professor started deviating into something that I believe was pure nonsense. He started the lecture by analyzing how many pieces a machine could manufacture per day. Fair enough. He extended the model to measure different ratios of capacity. Makes sense. Then he tried to extend the model to all machines, including humans. His example was: "How do you measure the capacity of a legal team?". I thought it was a trick question, so I answered (paraphrasing) "You can't answer that question the same way you answer for the machine. You can't give a single metric." He told me I was wrong and that the _right_ measure would be (total number of working hours/day). I was tempted to try to convince him otherwise. The analogy was deeply flawed. He certainly measured the machines in (number of pieces / day) but measured the legal team in (hours/day). So, in analyzing a machine, you take into account its efficiency, but you don't do the same thing for humans. I believe that is exactly the same thing that is going on in the post. Managers/Logistics/Economists are very susceptible to this kind of generalization pitfalls. Edit: Given that this answer has generated some discussion I feel the need to expand on it. The legal team was not expected to sell their services "by the hour". In fact, any discussion about how their services were sold was shut down by the professor. From his point of view, the lawyers were machines and he was asking the question "how much can this machine produce?" Yes, other students also suggested taking the number of billable hours/revenue into account, but that's not the answer the professor was looking for. I don't criticize whether his answer is not technically right, but I feel it holds no real-world meaning. It was a purely academic question that leads nowhere instead of having a debate about how you measure the productivity of a group of human beings. And on top of that, his final answer was definitive and (from his point of view) was irrefutable.
删减代码让驱动更小、覆盖更全、与规格一致。
我最自豪的成就之一是把一个驱动从约3000行减到约800行。这个文件有15年历史，被很多人改过：有永远走不到的条件分支、多年前废弃的功能、重复代码，还有大量与代码不符的注释。改完并加了几个新测试后，驱动达到了完整的MCDC覆盖率，代码也真正与设备规格对上了！
cbsks查看英文原文
One of my most proud accomplishments was reducing the size of a driver from ~3000 lines of code to ~800. The file was 15 years old and had been modified by many people since. There were conditionals that were impossible to hit, features that had been abandoned years ago, duplicate code, and lots of comments that didn’t match the code anymore. After my changes and a few new tests, the driver had full MCDC code coverage and the code actually matched the device specification!
删掉5k行换成300行解决了问题，结果LOC统计为负数，正好呼应原文。
几年前我几乎遇到一模一样的事。公司招了个挂着架构师头衔的糟糕家伙，做的只是很简单的第三方集成，把交易明细发给会计服务商。他不从数据库读，而是决定在存库前拦截，因为有些数据根本没存下来（这只对会计有问题，但大多数客户根本不用会计服务商）。他在这上面花了一年多然后转去别的项目。我接手后，beta测试客户怨声载道。我和经理跟他谈，毫无进展。我提议：“我还能再花一年，也可能永远搞不定。不如让我把他那堆垃圾扔掉重做？”几个月后获批。我把那部分约5k行代码全删了，换成约300行，之后再没出过问题。很快来了新的产品负责人，第一件事就是问我们过去一年写了多少行代码。呃……我从版本控制里拉出统计，哎，是负3000行左右。
mrjin查看英文原文
That was almost exactly what happened to me a couple of years ago. The company hired a terrible guy with an architect title. What he did was some really simple 3rd party integration sending some transaction details to an accounting provider. Instead of reading from db, he decided to intercept those before saving to db coz some of those were not saved at all (only a problem for accounting, but most of the customers did not use accounting providers anyway). So, he spent over a year on that and moved on to another project. I took the project over and lots of complaints from beta testing customers. My manager and I spoke to him about it and never get anywhere. "Look, I can spend another year on this, and it might never really work. How about let me scrap his sh*t and start over?" I proposed. Months later, green light I got. So I deleted all his code solely for that part, around 5k lines and replaced with merely ~300 lines, never had an issue since then. Soon we hired a new Product Lead, the first thing he did was asking how many lines code we wrote in the past year. Errr, okay, so I pulled out stats from source control. Ouch, it was minus ~3k lines.
唱反调：字数和LOC类似，可作粗略参考，但用来付钱或评估会导致激励错位。
让我唱个反调：大多数好作家都会说越短越好，用最简洁的方式表达，删掉多余再交给编辑继续删。可很多作家仍按字数拿稿费，很多图书合同仍规定目标页数。因为尽管越短越好，一段文字的最短可能长度仍能粗略反映其广度和复杂度。代码有什么不同吗？是的，按LOC付钱或评估程序员会导致激励错位，但我不认为这种动态比散文更糟。Bill Atkinson花一周删QuickDraw的多余代码，作家可能花一周删小说里多余的情节，字数对作家仍是有用指标。也许区别在于非作家比非程序员更熟悉写作过程；又或者字数测量其实也在让所有人的文笔变差，我们也该把它废掉。
Wowfunhappy查看英文原文
Allow me to play devil's advocate for a moment: Most good writers will tell you that shorter is almost always better. You want to express your thoughts in the most succinct way possible. Review your own writing to remove as much as you can, then hand your draft off to an editor who'll try to cut even more. And yet, many writers are still paid by the word, and many book contracts still specify target page counts. Because even though shorter is better, the shortest possible length of a given text still serves as a rough measure of that text's breath and complexity. Is code any different? Yes, paying or evaluating programmers by lines of code is going to lead to misaligned incentives. However, I'm not convinced the dynamic is any worse than for prose. Bill Atkinson spent a week removing extraneous code from QuickDraw; an author might spend a week cutting extraneous subplots from a novel. Word count is still a useful metric for the author. Perhaps the difference is that non-writers tend to be more familiar with the writing process than non-programmers are with coding. If an author was working on revising a novel, no one would ask them how many words they'd written that week. Or maybe word count measurements are in fact making everyone's prose worse and we should do away with them too.
历次讨论
同类还值得读
开发者无薪坚持完成 Mac 图形计算器：一个秘密项目的故事
Dev stays without pay to finish Mac Graphing Calculator as skunkworks project
苹果 Mac 图形计算器（Graphing Calculator）开发者的亲述：在项目被砍后，几位工程师在没有报酬、没有正式授权的情况下，以“地下项目”方式偷偷留在公司把软件做完…
历史与人物上首页 6 次 · 2009–2022pacifict.com理查德·费曼与 Connection Machine
Richard Feynman and the Connection Machine
长文回忆费曼晚年参与 Connection Machine 并行计算机项目的经历：他分析路由器、用自创的并行 Basic 编写 QCD 程序，也涉足细胞自动机等主题。
历史与人物上首页 5 次 · 2010–2021longnow.org编辑精选Dennis Ritchie 的第一版 C 编译器（约 1972 年）
Dennis Ritchie’s first C compiler (c. 1972)
这个 GitHub 仓库保存了 Dennis Ritchie 约 1972 年编写的最早 C 编译器源码，是 C 语言和 Unix 早期历史的一手材料。
历史与人物上首页 4 次 · 2013–2025github.com一位破解赛马密码的赌徒
A Gambler Who Cracked the Horse-Racing Code (2018)
彭博社 2018 年的长篇特写，讲述数学家 Bill Benter 如何用统计模型和算法在赛马博彩中持续盈利、累计赢得近十亿美元的故事。
历史与人物上首页 4 次 · 2018–2024bloomberg.comDB-19：复活一个过时的连接器
DB-19: Resurrecting an Obsolete Connector
讲述作者如何为一个已经停产的 DB-19 连接器寻找制造途径，并最终小批量复刻出来。
历史与人物上首页 4 次 · 2016–2024bigmessowires.com