“當時每酣醉，不覺行路難”。
每每有人問我:
程式設計師工作三年，要大致學習到什麼程度才算合格？
這時候，我感覺很難給出一個絕對正確的回答。
我能做的就是，如實的把我做程式設計師三年後的狀態分享出來，供大家參考。
賣油翁今已手熟爾
在我當了程式設計師三年之後，我對開發這事兒已經非常熟練了，熟練主要表現在兩個方面：
- 提給我的業務需求，我已經能毫不費勁的形成技術思路。
- 寫程式碼的時候，我已經能準確而快速的使用開發語言的 API 了。
我認為三年的程式設計師，做到以上兩點是基本條件。幹了三年左右，大部分人都已經很適應程式設計師這個工作了，是團隊中編碼的主力軍，開發工作應該做的很順利了。
如果大家在這方面還沒做到位，我的建議是多寫一些程式碼。這些程式碼可以是一些小工具，也可以是一些刻意練習。
牛客網上求職必備下的程式設計集合和它的基礎提升模組大家可以看看。
說到這裡，我多說一下，如果大家真的很熟練了，大家也要警醒一些。因為這種熟練的開發程式碼就像麻藥一樣，會漸漸地麻痺了大家的精神卻不自知。
我自己對此是有些教訓的。
我當時由於工作比較順利，學習開始不那麼努力了。雖然技術文章還在看，但系統的學習卻停滯不前了。
我沒有去系統性的擴充我的新技術學習，也沒有規劃好如何繼續深入挖掘各種已掌握技術的細節。
直到一年後，公司有了一些變動，我被迫提前做了架構師，才發現自己知識的貧瘠。還好那時我醒悟的還不算晚。否則，我可能就一直沉湎於自己構造的舒適圈，很可能就影響到自己以後的發展。
因此，這裡我想通過我的經歷告訴大家，當你工作了幾年後，一個最基本的要求就是，你得成為一個熟手，能搞定大部分常規的需求。
但是，這種工作上的順利可能會讓你懶惰，這點一定要警惕。幹我們們這行，是需要持續學習的，因為行業變化太快了，各種新技術新理念新架構層出不窮。
打算在這個內卷的行業裡繼續走下去，只有不斷的學習，深挖技術細節夯實基礎，學新技術擴充眼界。
已知曲中意，亦是曲中人
幹了三年，品鑑程式碼的好壞應該成為了自己的基本能力了。
我們至少應該拿到程式碼一看，就知道這程式碼寫的好還是壞，維護容易還是困難。
這個能力是我們們的基礎能力之一，其他基礎能還例如，選第三方工具庫的能力，如何重構程式碼的能力等等
如果你在程式碼方面還有些薄弱，我建議看看《程式碼整潔之道》這本書。
那如果你工作了三年，對程式碼好壞的嗅覺已經非常靈敏了，也千萬不要自得，因為你此時需要克服一個問題，那就是嘚瑟。
這種嘚瑟體現在，你可能會開始評判別人的程式碼了。
回過頭去看看，我當時就是這樣。當看同事程式碼或者接手別人專案的時候，每當看到寫的很難讀，又或者組織很亂的程式碼的時候，我就開始去肆意的批評別人。
但我並不知道，自己也是把二把刀。我並不瞭解為什麼人家程式碼寫的難以維護，可能人家也是被迫的。
後來我接手了一個趕得很急、產品經理又不給力的專案，這時候，我才深刻體會到了那種趕工寫程式碼的無奈。我才知道，自己也是寫這類不可維護程式碼的同類人。
所以，後來我逐漸閉上了自己的嘴巴。當我再看到不好的程式碼，本能還是會反感，因為這增加了我的工作難度。但是，我已經不會再去批評作者了，而是會仔細思考，有沒有更好的實現方式，我怎麼能把程式碼改的更優雅。
自從這麼做以後，我發現自己的程式設計能力竟然也跟著進步了。從很多爛程式碼後面，我學會了一些優化技巧，比如，使用位移去替代正常的加減乘數。
也從一些為了趕時間而寫的不那麼清晰的程式碼後面，看到了一些妥協的工作竅門，比如，使用 coninue label 和 break label 等去簡化複雜的演算法。
所以，工作了三年，品鑑程式碼好壞應該成為你的一種重要能力。
對於好程式碼，我們努力學習其風格；而對於壞程式碼，與其去狂妄的批評程式碼的作者，還不如我們仔細分析為什麼它是壞程式碼，以及如何優化它。僅此而已，因為你自己也可能被迫會寫出類似的壞程式碼。
窮千里目，更上層樓
老實講，工作三年後，我們們至少要深度掌握一些技術了。
比如，我擅長 SQL ，能寫各種效能優異的SQL，對 MySQL 有一定程度的瞭解。
前面我說過，我此時學習態度是很鬆垮的，所以，除了我掌握的，我後續竟然不知道該學什麼方向了。
後來，可能是因為站到了更高的一個位置上，我突然知道了學習目標，那就是：
我的知識體系應該是隨著公司後臺架構的發展而進行擴充的。
比如，公司的架構主要是使用 Redis 做了第三方快取，資料庫是 MySQL，服務之間的通訊方式則是訊息佇列 RabbitMQ。
那麼如果我想讓自己的知識體系建立在公司的專案架構上，我應該怎麼定學習目標？
當時我是這麼分析的，我對 MySQL 瞭解的還算深入，但是對 Redis 和 RabbitMQ 還沒有什麼瞭解，只限於會用而已。所以，我定的目標就是對後兩個技術進行深入學習。這樣學完之後，我的知識體系就成了這樣：
這套知識體系我掌握了，才能從眾多的同事們中脫穎而出，才有可能成為團隊中的核心。
所以，工作三年之後，我們們應該至少要深入掌握一些技術，並以此為基礎，根據公司的技術架構去逐漸完善自己的知識體系。
做到了學習和工作相結合，才能在實力提升的同時也能得到職場上的正反饋。
花相似，人不同
做程式設計師的前三年，大家少不了各種 CV 程式碼。
不過在這三年中，我認為我們的 CV 應該有一些變化。
就說我吧，首先，我拷貝程式碼的來源發生了變化。從在網上隨意找程式碼，變成了主要從 GitHub 上拷程式碼了，因為 GitHub 上的例子更多、更豐富。
其次，我拷程式碼的方式發生了變化。我會仔細研讀要複製的程式碼，並配合官方文件，綜合分析後，會對其做一些修改，變成真正適合我自己專案的程式碼。
最後，我拷程式碼的次數發生了變化。因為拷的程式碼我會仔細讀、會改，所以我拷程式碼的次數在不斷減少，自己獨立寫的程式碼越來越多。
所以，我推薦大家 CV 的時候，一是可以去專門的開源網站上找程式碼示例，二是 CV 前一定要分析下，明白每條語句的目的是什麼，只有這樣，我們們自己才能跟著進步。
現在 CV 是為了以後不 CV。
可言秋日勝春朝
三年工作，我可以獨立解決一些線上問題了。
後來反思，我做的還不夠好。因為我解決問題的方式大部分就是就事論事，只注重解決問題的表象，而不會去深挖問題的根源。
比如，JVM 記憶體溢位了，我的做法是改配置引數或者加記憶體，而不是想著怎麼優化程式碼。
類似這種事情多了之後，由於很多深層次的問題沒有得到解決，導致後期維護專案的時候，bug 越改越多，問題越修復越大，極大的增加了維護成本，慢慢的就變成了一個大“屎山”。
大家解決問題的時候，千萬別學當時的我，只看問題表象。盡力對問題深挖，去根本性的解決問題。這樣除了對專案和公司有好處，對個人成長也極為有利。坑踩的多，填的多，都會變成你的寶貴經驗。
久在樊籠裡，復得返自然
程式碼要寫的儘量可讀，儘量清晰，是我這個時候寫程式碼的主要理念了。我不知道別人工作三年如何，但是我自己是吃夠了這上面的虧。
以前寫程式碼，由於程式設計水平很渣，而且也沒聽過“重構”，經常會寫一些很難讀的程式碼。比如，把很長的邏輯寫到一個方法裡，一個類幾百上千行。結果在維護的時候就懵逼了，自己寫的程式碼自己都看不懂，經常改錯。
後來，我注重了程式碼質量，注重了重構，bug 也隨之減少了很多。後來，團隊 Leader 評價我寫的程式碼“可讀性和工程性都很好”。
建議大家也重視程式碼質量，程式碼要清晰可讀，不要為了炫技而特意寫一些難讀的程式碼。
好雨知時節
三年裡，我經過了很多專案 DeadLine 的考驗。我此時已經明白了一個道理——按時完成任務比完美的完成任務要更重要。
單純從技術角度看，如果我們要達到完美，是需要花費大量的時間的。優雅的程式碼，極致的效能，最優的資源利用，都是體現技術完美的因素。而這些因素，無一不是猛烈吞噬時間的猛獸。
- 優雅的程式碼需要更多的時間去重構程式碼
- 極致的效能需要長時間不同角度的壓測
- 而最優的資源利用更是需要不斷地修改程式碼去不停的嘗試
現實上呢，我們開發的產品，市面上基本都有競品，所以呢，需要我們早做完上線去搶有限的使用者、有限的份額。因此，這就需要我們一定要快，在保證質量的前提下按時完活，應該成為我們們的第一優先保障。
方與人便人稱便
工作了三年，我也明白了技術是為業務服務的這個道理。我也明白，越瞭解業務，我做出來的專案就會越契合業務，而越契合業務，專案、程式碼的價值就越大。這是一個正向迴圈。
所以後來，我每次要開發一套系統的時候，都會去主動學習相關業務知識。
後來我能從技術無縫轉管理，有很大一部分原因是，我能更順利的理順業務和技術之間的裂痕，也能更平滑的將業務需求轉化為技術需求。
你不得不承認，在國內真正技術驅動的公司和產品太少了，大部分現狀是“技術服務於業務”。雖然這個現狀我不喜歡，但是不得不接受，所以我還是想告訴大家：熟悉業務，是我們能突出自己的一個很好的切入點。
寫到這裡基本就寫完了，最後我想說一下，工作三年的程式設計師大概要到什麼程度，真的是千人前面的。每個人所在的公司不同，開發的專案不同，所在的職位不同，自然大家的感悟不同。
我上面說的那些話，除了想分享給大家，有些話也是想說給從前那個我聽的。
你好，我是四猿外。
一家上市公司的技術總監，管理的技術團隊一百餘人。
我從一名非計算機專業的畢業生，轉行到程式設計師，一路打拼，一路成長。
我會把自己的成長故事寫成文章，把枯燥的技術文章寫成故事。
不知不覺，我原創了不少文章，最近把其中的一些精華文章做了個彙總整理，優中選優，整了一份文件——《爬坡》。
《爬坡》裡包括了 15 篇技術文章（包括學習程式設計技巧、架構師、MQ、分散式）和 13 篇非技術文章（主要是程式設計師職場），一共十萬多字。