"懒"的真功夫AI 时代的"懒"哲学那些"不该写"的代码尾声
上个月，我们团队来了个新人，985 科班出身，ACM 拿过奖，一上来就哐哐哐写代码，三天搞了一个微服务框架，五天搭了一套完整的 CI/CD 流水线。所有人都觉得——这小子是个猛人。
唯独老张，瞟了一眼他的代码，没说啥，端起保温杯走了。
老张是我们组最"懒"的程序员。十年工龄，写代码出了名的慢。别人一天提十几个 PR，他有时候三天才提一个。每次代码评审，他的 PR 改动量都小得可怜，经常就几十行。
但奇怪的是，老板从来没说过他。
事情爆发在一次线上事故。
新人的微服务上线第三天，凌晨两点，报警电话把整个后端组炸醒了——数据库连接池被吃光了，大量请求超时，用户端直接 502。
查了两个小时，最后定位到新人的代码。
他写了个很"优雅"的装饰器模式来做请求日志，层层封装，看起来教科书一样完美。但问题就出在——每一层封装都创建了一个新的数据库连接对象，在高并发下直接撑爆了连接池。
老张那天也被拉起来处理事故。他看了一眼代码，没说话，打开自己的编辑器，二十行代码把整个日志模块重写了。不用装饰器，不用设计模式，就是最简单的一个中间件函数。跑了一晚上压测，稳得一批。
新人脸都绿了。
后来我私下问老张，为啥他写代码总是那么"抠"。
他说了一句我记到现在的话：
"你写的每一行代码，都是你未来要背负的债。能不写，就别写。"
他说刚入行那会儿，他也是个"代码艺术家"，觉得设计模式用得越多越牛逼，抽象层级越深越高级。直到有一次，他接了一个离职同事的项目，七层继承、五个工厂类、三个观察者模式——看起来无比牛叉，但改一个按钮颜色要翻八个文件。
那次之后他悟了。
代码不是写给人看的，也不是写给机器跑的——是写给六个月后那个改 Bug 的自己看的。
你写得越复杂，未来的你就越痛苦。
最近 AI 写代码火得一塌糊涂。什么 vibe coding，什么 Copilot 一键生成。新人特别吃这套——让 AI 写一坨代码，自己改吧改吧就提 PR 了。
但老张的态度很有意思。他说 AI 写代码是个好东西，但前提是你得知道什么代码不该写。
他给组里定了个规矩：每次提 PR 之前，先删掉三分之一的代码。删不掉的，说明你写多了。
这听起来有点极端，但效果是真的好。三个月下来，我们组的线上 Bug 率降了 60%，部署速度翻了一倍。
说白了，少即是多这件事，放在写代码上再合适不过了。
我观察了一段时间，发现老张说的"不该写的代码"大概分这么几类：
第一，过早优化的代码。流量还没到百万呢，先把缓存、分库分表、消息队列全上了。架构是"高可用"了，但交付周期从三天变成了三周。等业务真起来了，这套架构可能已经不合适了，还得重写。
第二，过度抽象的代码。为了"万一以后扩展"，搞一堆接口、抽象类、工厂模式。结果过了一年，那个"万一"压根没发生，代码倒是多了三倍。
第三，为了用技术而用的技术。一个简单的 CRUD，非要上 Event Sourcing。一个几百人的内部工具，非要搞微服务。这不叫架构，这叫炫技。
前两天组里又来了个新人，名校毕业，热情高涨。第一天就在群里问："咱们用的技术栈是什么？DDD 搞了没？"
老张没回消息。
下午我路过他的工位，看见他正带着新人改一个 Bug。那个 Bug 的修复方案，老张只写了三行。
新人盯着屏幕看了半天，说了一句："卧槽，还能这样？"
老张嘿嘿一笑，端起保温杯又走了。
你有遇到过那种写代码特别"少"但特别靠谱的同事吗？或者你自己就是那个"懒"程序员？评论区聊聊你的故事
热门跟贴