工作五年後的程式設計師，一般怎樣了?

​
本科一般是 22 歲畢業，5 年開發經驗一般是指 27 歲。這個階段，不少程式設計師可能透過多次跳槽，薪資有一定漲幅，但真有可能還在小公司甚至外包公司做增刪改查的業務，然後坐等 30 歲的到來。

就以 Java 為例，一些發展情況一般的程式設計師情況會怎麼樣呢？

1 會用 Spring boot+JPA 等框架做業務，而且由於業務做多了，熟悉框架相關技能，在公司裡也能憑藉做熟業務而幹得風生水起。

2 熟悉日誌，測試，專案部署和問題排查等專案開發技能，但僅限於開發單機版的業務。

3 還是在小公司，乾的活除了是開發以外，更多幹的是打雜扯皮的活。或者說，能憑藉在公司裡幹久了，能在合理利用規則的前提下摸魚。

4 如果再跳槽，大機率還是找小公司。一方面不知道如何面大公司，另一方面估計連面大公司需要你熟悉哪些技術也未必知道，或者是知道了以後也沒有相關技術的專案實踐經驗；或者看下技術大廠還不錯的外包崗機會。

上述情況應該是有 3 到 5 年 java 經驗程式設計師的普遍情況，有一定上進心，但不知道上進途徑。在這個階段接下來怎麼繼續提升呢？下文就從簡到難，給出相關執行步驟（僅限 Java 方向）。

1 多參與解決實際問題，哪怕這個問題不是你管的。同時如果有運維或分散式元件相關的問題，一定要參與。這樣不僅能繼續提升業務水平，而且能立竿見影地提升技術。

2 瞭解專案從開發到測試到部署整個流程，這樣能熟悉專案管理的相關技術和元件。

3 結合業務，熟悉分散式元件或微服務以及雲開發等技術，有機會的話，多參與此類任務，多排查和解決此類問題。

4 在上述基礎上，看些脫離業務但和專案基礎設施有關的技術和元件，比如如何搭建叢集，如何擴容和遷移機器，如何解決高併發層面的資料庫效能問題，以及如何應對限流熔斷和服務降級等問題，如果可能，多參與些諸如壓測等效能調優等的工作。

其實如果上心，一般能在 3 個月的時間內熟悉上述 1 到 3 點，如果再多問問大牛，多參與實踐，上述第 4 點也能在半年內掌握。到了這個程度，就別再滿足當下公司給的薪資了，跳槽一次的話，薪資漲個 3 成都算少的。

下文就繼續展開說明，先說如何透過排查問題提升技能。

1 在開發過程中，一定會遇到各種問題，有業務層面的，有資料庫或 OOM 或元件層面的，最值錢的應當算是架構和叢集層面的。遇到問題後，哪怕不是自己的，一定得參與，哪怕有其它人負責解決，那麼人家在解決後，也應該透過看日誌搜尋關鍵字等動作，覆盤人家的分析和解決過程。

2 一般專案的日誌是部署在 linux 上的，有些專案可能還有 ELK 等視覺化日誌管理工具，可能有些專案還會透過 new relic 或 cat 等元件監控日誌或系統，比如日誌裡出現 Exception，或有資料庫長 sql，就會告警。

看日誌解決問題過程中，首先得掌握開啟日誌或從監控工具中獲取有效資訊等做法。再進一步，甚至可以去關注比如 logback 或 ELK 等日誌元件等配置方式，以及去關注 Cat 等監控元件等細節。當然在排查問題過程中，連線資料庫客戶端等工具也必不可少。

3 這樣一旦出現問題，解決的步驟一般是，根據時間點拿到日誌，再透過關鍵字搜尋日誌，再用 trace-id 或 thread-id 等觀察整條鏈路在不同模組裡的日誌。查到出錯資訊後，再去排查相關程式碼。

4 上述從日誌裡得到相關資訊的步驟，雖然簡單，但沒有操練前不是每個人都能熟悉掌握。此外，分析排查問題的過程一定會涉及到業務和元件等技術。

也就是說，如果程式設計師多參與解決問題，那麼一開始可能無從下手，估計連日誌在哪以及該如何開啟日誌都不知道，到了後面，可能別人找到了問題，你才剛開啟日誌。但所謂熟能生巧，多參與幾次，多覆盤幾次，後面一定能高效發現並排查解決問題。

透過看日誌分析解決問題能提升哪些方面的技能呢？業務層面的就不說了，往淺了講，能熟悉 Java 的各種異常，往中了講，可以熟悉排查 oom 或資料庫效能問題的技巧，往深了講，甚至能瞭解分散式元件相關的技能。

再說說從專案管理和部署方面提升能力的操作要點。

專案一般會用 Gradle 或 Maven 來管理，用 Git 管理程式碼，用 jenkins 做部署，部署上線前，可能需要到資料庫裡做建表或修改表結構等操作，上線時，可能還要對應修改配置檔案。

java 程式設計師如果可以，一定別開發完程式碼就了事，可以多和運維或做釋出的人多溝通，從中一方面能瞭解基於 jenkins 等元件的專案釋出流程，另一方面，還能熟悉專案打包部署和除錯等細節。再進一步，透過熟悉這一流程，還能知道專案和 nginx、redis、dubbo 和訊息中介軟體等元件的對接方式。總之，如果多參與幾次專案釋出，或者哪怕沒機會動手實踐，也可以在一旁熟悉各種命令。這種技能甚至有些 java 高階開發也未必掌握。

再說下從分散式元件層面獲取技能的方式。

一個專案哪怕再普通，多少會結合些分散式元件，比如用 nginx 做負載均衡，用 redis 做快取，用 dunno 做遠端呼叫。甚至可以這樣說，如果程式設計師不注意觀察，眼裡只有被分配到活，自然可以不用接觸相關技能，但如果肯多問人，肯多和相關人員交流，一定能接觸到分散式元件方面的技能。

這塊該怎麼看呢？

1 結合業務需求看為什麼要用元件？比如要解決資料庫層面的效能問題，所以要用 redis 或 mycat。

2 看專案裡怎麼用，比如怎麼透過配置檔案連線 redis 或 dubbo，怎麼透過註解或 API 使用元件。

3 如果可以，看下元件是如何在 linux 上搭建的，尤其需要關注叢集的搭建方式。

4 著重關注元件方面問題的解決。比如遇到 dubbo 超時問題，或 kafka 訊息重發，這類問題其實只要關注，發生的頻率不比業務問題要低。

這方面也是能熟能生巧，剛開始的時候可能連元件是什麼都未必清楚，但觀察一陣程式碼，同時解決一些問題後，估計叢集長什麼樣，使用元件可能會有哪些坑，應該都能知道。

在熟悉元件以後，就可以多觀察高併發相關的技能了。

高併發方面的問題其實也是一樣的，剛開始可能無從下手，但多參與幾次問題排查和解決後，大家其實會發現這並不神秘。

高併發相關技能包括哪些呢？

1 搭建組建環境層面，有擴容，更換服務，搭建叢集和遷移資料等技能。

2 在解決實際問題層面，有熔斷，服務降級和限流等動作，這方面甚至還可以包括分散式鎖和訊息冪等操作。

3 從功能方面，包括用 nacos 等組建搭建服務治理環境，用 dubbo+zookeeper 搭建遠端呼叫環境，用 nginx 或 ribbon 搭建負載均衡環境，以及用 nginx 或 gateway 搭建閘道器環境，或者是用 seata 搭建分散式事務環境。

可能上文提到的技術，一些 java 初級開發都未必聽全，但本人親眼見過，一個才 2 年開發的 java 程式設計師，人比較上心，基本掌握上述技術才用了 4 個月，到 7，8 個月的時候都能解決高併發問題了。

其實做這個程度，別說高階開發，估計架構師相關的技能都能掌握不少。雖然說，對 java 開發的要求一般是能順利做好開發任務，同時確保程式碼質量，而且能解決本職方面的問題，但如果 java 開發僅僅止步於自己所管的一塊，估計增長的也是些業務技能，這種技能估計換個工作就沒用了。

但是相反，大多數 java 專案總會包含些架構，叢集和元件等方面的技術，而且 java 程式設計師如果肯主動上進，那誰也不能攔著。可能剛開始會步步維艱，甚至連開啟 linux 日誌的命令也要先查，但只要肯堅持，那麼最終收益的還是自己。

本人也見過不少 java 程式設計師，在一家公司的某個組裡，大概有 4，5 個初級開發，他們的薪資普遍只在年薪 15w 左右。

其中有些人可能就僅限於自己所管的這塊，確實，業務做多了，完成任務的速度和質量能提升，但這些人平時接觸到的也就是增刪改查。但也有一些人，平時在工作之餘，甚至是利用加班，多去和其它組以及運維和中介軟體組交流，有問題總是跟在後面，哪怕一頭霧水，也會找人覆盤，盯著問。

就這樣大概過了半年，這兩批 java 開發的差別就肉眼可見。一些只完成自己任務的程式設計師，估計依然停留在增刪改查階段，充其量頂多是個熟練工，按薪資來衡量，估計依然是停留在年薪 15w 的水平，況且年紀又大了，競爭力可能還下降。

但一些積極上進的程式設計師，由於日常工作中會主動接活並多參與事情，平時也經常出錯，或者有時候分析問題不到位。但過了半年，這些人多少能掌握排查問題的技巧，多少參與過 OOM 或分散式元件等問題的排查，多少也開發了快取等高併發方面的活，這樣的話，出去面個高階開發應該不成問題，假以時日，估計升級到架構，應該也是時間和體力方面的問題。

轉 zi___老胡聊 Java

​