“一周写了-2000行代码，却让系统快了6倍”，苹果传奇工程师硬刚代码量周报，从此再也没写过…
仅用于站内搜索，没有排版格式，具体信息请跳转上方微信公众号内链接
整理|苏宓
出品|CSDN（ID：CSDNnews）
在许多程序员的工作中，“每天、每周要写多少行代码”似乎成了一个绕不开的话题。有人拿它当KPI，有人拿来卷效率，也有人把它当做衡量开发者价值的量尺。
但真的是写得越多，代表能力越强、贡献越大吗？
最近，在HackerNews上，一则经典回忆被再次顶上热榜：苹果公司早期工程师BillAtkinson曾通过重写算法，不仅使软件性能提升了近六倍，还减少了约2000行代码。
结果，当被管理层要求填写“本周编写的代码行数”的表格时，他毫不含糊地写下了一个数字：-2000。
这既是一种回应，也是一种抗议——他用行动表达了对“用代码行数衡量生产力”这一做法的明确反对。
这段往事不仅再次引发了开发者们对“代码行数vs实际贡献”的老话题争论，也勾起了不少人分享自己删代码删到飞起的高光时刻。
来自1982年的-2000行代码
故事要追溯到1982年，那时候Apple的Lisa团队正在为未来六个月的产品发布冲刺。为了“提升效率”，一些管理者决定用每位工程师每周写了多少行代码，来衡量他们的工作进度。
于是他们设计了一张表格，要求团队所有工程师每周五都得填，里面最关键的一栏就是：“你本周写了多少行代码？”
但这项指标让BillAtkinson感到相当荒谬。
他不是别人，正是QuickDraw图形引擎的作者，也是Lisa和后来的Macintosh项目中最关键的用户界面设计师之一。
在他看来，代码行数根本不是衡量开发效率的好办法。他的目标是让程序尽可能小、尽可能快，而这个所谓的“代码行数指标”只会鼓励大家写出臃肿、混乱、质量低下的代码。
当时他正好在优化QuickDraw的区域计算引擎。他彻底重写了这部分逻辑，采用了一种更简单、更通用的算法。经过一些调优之后，区域操作的性能提高了将近六倍。
与此同时，这次重写还顺带删掉了约2000行代码。
就在他为优化收尾的那一周，他第一次需要填写管理层要求的那张表。当他看到“本周代码行数”那一栏时，想了想，然后写下了一个数字：-2000。
没人知道管理层当时看到这个数字是什么反应，但可以确定的是，几周后他们就再也没有要求Bill填这张表了，而他也乐得不再配合。
代码行数，真的是个伪命题吗？
在这条热帖下，不少网友也现身说法，讲述了自己亲历的“删代码爽过写代码”的高光时刻。
一位名叫bironran的网友评论道：
“我做过最棒的一次提交，是直接删掉了大约6万行代码。那是一个早期服务器项目（2000年代初），所有状态全都要保存在内存里，复杂又脆弱。
我用约5000行更简洁的逻辑取而代之，不再需要在内存中维护任何状态，甚至能顺带集成进另一个服务。
这完全是一场算法胜利——我发现，在目标是树结构（有向、无环、单根图）的情况下，可以通过一次性遍历原始（更通用的）有向双图来完成“特定引导下的子图同构”操作。在遍历过程中，只需维护一个轻量的、可预览的栈，记录从根节点开始的路径步骤，用来影响当前输出图（树）的生成过程中的决策（不一定只是父节点路径）。
我到现在还记得那个庞大的提交记录：-60,000行代码。那是我推送过的最棒的一次提交。
那段时间真有意思。可惜从那以后，再也没写出什么在算法层面上让我自豪的东西了。”
以代码来衡量工作量，殊不知多余的代码总是会以一些令人意外的方式出现。另一位网友jfengel则分享了自己在大学打工时的一段经历：
“我曾在一家尝试用‘管理方法’让一群大一新生写出高质量代码的公司实习。
结果？当然失败了。我经常找到一个bug，修完后却发现问题还在——因为之前的学生并不是在原有函数中加参数，而是直接复制整段函数，稍微改点逻辑，然后另起一份……
那年秋天，我删掉了他们整个TurboPascal代码库大约四分之三的内容，数千行。
更恐怖的是——这个项目的客户是美国能源部，而这套系统的任务是：管理核材料库存。
有人也认同“改得多就是贡献大”
当然，也不是所有人都一边倒地否定“代码改动量”这个指标。
一位团队管理者在评论中分享了自己的观察：
“虽然把代码行数当生产力衡量标准一直被批评得很多，但我今天回头分析了我们团队过去两年的代码提交数据，发现那些我认为真正有生产力的成员，代码的‘改动量’确实比其他人大得多。
这里的改动包括增加和删除，而不是简单看谁写得多。
作为他们的主管，我对这套系统和团队都很熟，所以我的判断并不是拍脑袋瞎猜的。某种程度上来说，改动频率和代码影响力确实是呈相关的。”
这也说明：代码行数可能不是衡量“能力”的好指标，但它有时候确实能反映“参与程度”，尤其在数据样本够大、上下文明确的前提下。
程序员的价值不该只被“写了多少行代码”来定义
事实上，程序员的价值不该只被“写了多少行代码”来定义——这几乎已经是行业共识。
我们需要写的是更好、更清晰、更稳定的代码，而不是更多的“字符”。那些真正优秀的工程师，往往不是用“加法”解决问题，而是通过“减法”来简化逻辑、提升性能、降低风险。
一句话说到底：代码不是写出来才有价值，删掉时也可能是最大的功劳。
那么，你是否经历过“写代码要看行数”的工作环境？你觉得代码改动多，就意味着效率高吗？欢迎在评论区分享你的观点~~
参考：
https ://www. folklore.org/Negative_2000_Lines_Of_Code. html
https ://news. ycombinator.com/item?id=44381252
好啦，今天的内容分享就到这，感觉不错的同学记得分享点赞哦！
PS：程序员好物馆持续分享程序员学习、面试相关干货，不见不散！
点分享
点收藏
点点赞
点在看
