浙江
"懶"的真功夫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 的修復方案，老張只寫了三行。
新人盯著屏幕看了半天，說了一句："臥槽，還能這樣？"
老張嘿嘿一笑，端起保溫杯又走了。
你有遇到過那種寫代碼特別"少"但特別靠譜的同事嗎？或者你自己就是那個"懶"程序員？評論區聊聊你的故事
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
