资深开发者并不写出更好的代码，他们删除的代码更多。
Source: Dev.to
删除悖论
没有人会告诉你的职业发展真相是：你作为开发者的价值与写的代码量成反比。
- 一名初级开发者加入团队后立刻开始贡献。他们实现新 API，添加验证层，编写实用函数，并构建完整的测试套件。在第一年里，他们可能为项目新增 50,000 行代码。大家都对他们印象深刻。
- 同一团队的资深开发者加入后，在第一个月就删除了 15,000 行代码。他们移除三个完整的微服务，剔除两个依赖库，并将四个相似的函数合并为一个。初级开发者的代码贡献图像是高山峰，而资深开发者的则像一条谷底。
猜猜公司更看重哪一个？
Source: …
为什么删除胜过创建
更少的代码 = 更少的问题
每一行代码都是一种负担。它可能会出错，需要维护，产生依赖，并且必须被后来的开发者理解。我曾参与一个项目，将一个 3,000 行 的配置系统缩减到 200 行。错误报告下降了 80 %，性能提升了 40 %。最初编写它的初级开发者感到被冒犯，而用户则欣喜若狂。
维护成本是真实存在的
- 那个你精心设计的抽象？明年会有人花三天时间去理解它。
- 那八个相似却略有不同的函数？每一个都是在需求变化时可能出现的 bug。
- 那覆盖所有边缘情况的全面错误处理？大多数情况根本不会出现，但额外的复杂性会拖慢每一位后续开发者的工作。
认知负荷才是最大的敌人
人类的大脑在工作记忆中大约只能容纳 七个信息块。而你的代码库可能包含 70 万个信息块。每一个不必要的函数、冗余的参数或“以防万一”的特性都会增加认知负荷。资深开发者明白，降低认知负荷比增加功能更有价值。
Source: …
战略性删除的艺术
先删除冗余代码
寻找相同逻辑出现多次且只有细微差别的模式。我最近把十二个不同的 “send notification” 函数合并为一个可配置的函数，删除了 400 行代码，降低了 bug 率，并简化了测试。
移除未使用的功能
- 那个没人看的分析仪表盘？删除它。
- 只被 QA 团队用于测试的 API endpoint？删除它。
- 已经启用两年的 feature flag？删除该标记并将行为设为永久。
未使用的代码并非中性——它会主动造成误导性的复杂度。
消除过早的优化
初级开发者常常为根本不会出现的性能场景进行优化。我见过：
- 为每月只会变更一次的数据添加缓存层。
- 为每分钟峰值仅 10 请求的负载编写复杂算法。
- 为拥有 99.99 % 可用性要求的服务构建精细的故障转移系统。
删除这些优化，看看是否有人注意到。答案是：不会。
杀掉你的心头好（以及依赖）
- 那个你写的优雅辅助库？如果只在三个地方被使用，也许直接复制 20 行代码就行，而不是维护整个模块。
- 那个正好满足需求的流行 npm 包？如果你只用了它 5 % 的功能，考虑直接实现这些特性并去掉该依赖。
培养你的删除本能
- 衡量正确的指标。 跟踪删除的代码行数，而不是编写的代码行数。
- 庆祝已退役的功能，而不是新的功能。
- 提出正确的问题：“我们如何避免添加此功能？”而不是“我们如何添加此功能？”
实践10× 规则：你编写的每一行代码将被阅读 10 次，修改 3 次，调试 2 次。确保这样做是值得的。
在编写任何新代码之前，花30 分钟寻找可以删除的现有代码。你会惊讶于通过删除旧问题来解决“新”问题的频率有多高。
反直觉的真相
作为开发者，你能做的最有成效的事并不是写更多的代码，而是写更少但更有作用的代码。最快交付功能的方式不是添加功能，而是消除阻碍功能开发的障碍。
资深开发者本能地明白这一点。他们曾多次因为自己的巧妙代码而吃亏，因而知道简洁胜过复杂。他们维护了足够多的遗留系统，深知每一行代码都是对未来维护的承诺。
下次准备实现新功能时，问问自己： 我还能删掉什么？ 你的未来的自己会感谢你。你的团队成员会感谢你。你的用户也会感谢你，即使他们从未意识到为什么应用突然变得更快、更可靠。
最好的代码是不存在的代码。最好的开发者是那些保持代码不存在的人。