你的編程能力什麼時候開始突飛猛進？拆解從「能跑」到「能維護」的學習曲線躍遷

編程能力的躍遷極少來自「寫更多程式」，而是來自幾個可辨識的認知轉換節點：第一次為了別人而寫、第一次被自己三個月前寫的程式碼絆倒、第一次讀懂一段讓人驚呼的實作。一個開發者真正的成長曲線，往往不在於寫了幾年，而在於有沒有走過那幾道窄門。

知乎上這則被反覆頂上來的老問題——「你的編程能力從什麼時候開始突飛猛進？」——戳中了一個所有寫程式的人都會撞到的焦慮：為什麼有些人三年就能獨當一面，有些人十年還在原地打轉？答案不在天賦，而在學習曲線的形狀。

關鍵事實

寫程式的學習曲線有一個讓人沮喪的特性：很長一段時間你感覺不到進步，然後某天突然能看懂以前看不懂的東西。這不是錯覺，而是認知科學裡常被討論的高原期（plateau）。

高原期的本質，是大腦還在把零散的技巧整合成可調用的模組。你這段時間寫的每一行程式碼，看起來都在重複，其實是在把「刻意思考」降維成「直覺反應」。真正的躍遷，發生在整合完成、新的抽象層級被打通的那一刻。

這也解釋了為什麼單純堆時數沒有用。每天寫三百行重複的條件判斷，跟每天解一個稍微超出自己能力的新問題，三年後的差距是結構性的。前者只是把同一個高原走得更熟，後者才是在尋找下一個階梯。

多數開發者第一階段的成長，是學會讓程式跑起來；但真正拉開差距的，是從「能跑」到「能維護」的跨越。這一刻通常發生在你第一次需要回頭改自己三個月前、甚至三年前寫的程式碼，而且沒有人可以問的時候。

那種被自己絆倒的經驗，會強制你重新思考變數命名、函式切分、狀態管理。你開始理解，為什麼資深工程師總是執著於「未來那個倒楣的同事」——因為那個同事常常就是你自己。

這也是為什麼只看結果對錯會錯失真正的學習是初學者最容易踩的陷阱：一段程式能跑、能產出正確答案，不代表它是好的工程。躍遷發生在你開始對「過程」有審美標準的那一刻。

很多人以為進步只能靠「自己寫」，但知乎高讚回答裡反覆出現的兩個成長加速器，恰恰相對被動：讀別人的源碼、被別人 review。

讀優秀的源碼，是把自己暴露在更高層級的思考現場。你看一個成熟函式庫怎麼處理邊界條件、怎麼切抽象、怎麼命名，那種「原來還可以這樣想」的瞬間，比寫十個練習專案更能推動躍遷。重點不是模仿，而是看見自己思考維度的上限在哪裡。

code review 則是把你的思考攤開給另一雙眼睛檢驗。被 review 的當下通常不舒服，但每一次「為什麼這樣寫」的追問，都是在強迫你把隱性知識講清楚。能把一段程式碼背後的理由講清楚，本身就代表你的理解已經升級。

職涯社羣裡常聽到一種說法：只要寫滿一萬小時就能成為高手。但這個借自刻意練習理論的口號，被嚴重誤讀了。

刻意練習的核心從來不是時數，而是「在能力邊緣、有回饋、可重試」的條件下練習。機械式地重複已經會的事，再久也無法躍遷。這也解釋了為什麼計算機科系跌出本科收入前十並不等於程式能力貶值——市場正在重新評估學歷的定價，但對真正走過躍遷節點的開發者，需求從未縮減。

真正能複製的成長路徑，是讓自己持續處於「有點難、但還能動手」的區間，並且定期讓別人看見你的程式碼。時數只是副作用，不是原因。

編程能力的突飛猛進，從來不是某個早晨醒來就會了。它是幾個可辨識節點的累積：第一次為了未來的自己寫註解、第一次被舊程式碼教訓、第一次在別人的源碼裡看見更高的維度、第一次在 code review 裡把隱性思考說出口。

這些節點不會因為你寫得更久就自動出現，它們需要被刻意靠近。所以與其問「什麼時候會突飛猛進」，不如問自己一個更實際的問題：今年，我給自己安排了幾次被絆倒的機會？

常見問題 FAQ

Q1：編程能力的「突飛猛進」通常發生在什麼時候？ 多數開發者不是線性變強，而是在承擔「別人會讀的程式碼」、被舊程式碼絆倒、或讀懂一段優秀原始碼之後，出現一次跳躍式升級。躍遷發生在抽象層級被打通的那一刻，而非時數堆滿的那一刻。

Q2：為什麼寫了很多年程式，能力還是原地踏步？ 通常是因為長期重複已經會的工作，沒有把自己放在「能力邊緣」。沒有回饋、沒有重試、沒有更難的問題，高原期會無限延長。

Q3：讀源碼真的有助於提升編程能力嗎？ 有。讀優秀的源碼是把自己暴露在更高層級的思考現場，能看到成熟的函式庫如何處理邊界條件與抽象，這比獨自寫練習專案更容易推動躍遷。

Q4：code review 對成長有多大幫助？ 幫助很大。每一次被追問「為什麼這樣寫」，都強迫你把隱性知識講清楚；能把程式碼背後的理由說出口，本身就是理解升級的訊號。

（作者／沈安，Techroomage 編輯部）