20年前和現在-為什么程式員越來越累

內卷

萬物都可內卷，20年前很缺IT人員，只有會寫ASP，JSP，PHP就能入行，如果你掌握EJB，那就是非常不得了了，作業到25歲就能當專案經理，28歲就能成為副總也是常態，就沒有看到過30歲的程式員，以我剛開始上班的那個公司說，25歲是副總，另外一個年級也大點，29歲的副總， 現在則不一樣，每年的畢業生數以百萬計，25歲大家剛研究生畢業，作業3年天賦+運氣加持，也最多是個小組領導，現在40歲的程式員也常見，我的前輩47了還在寫代碼，而我今天43了，也仍然還在寫代碼，我雖有心帶領后浪，但實際上也知道會被后浪拍死在沙灘上，

20年前，清華北大去的是中科院，研究院，或者某事業單位，現在，在各個軟體公司，都有清華北大的影子，2011年在網易的時候，就發現身邊都是清華北大學生，當時感覺很奇怪，現在倒是也能想得通，畢竟科研單位只有家里不差錢，才能安心搞研究，

20年前，能精通一本技術手冊就已經是屬于資深人員，比如Oracle官方檔案或者是JavaEE規范，或者Weblogic官方檔案

現在，程式員要看很多手冊，涉及開發，運維，資料庫，安全， 這些手冊隨著產品變化迭代也很快，學不過來，

20年前，能運用一個開源就很牛逼，現在不僅僅要知道開源，還要能自己手寫開源，或者貢獻知名開源，才能在面試中獲得巨大優勢

現在互聯網招的人多，薪水高，但總的人數有限，頂級大學的學生搶985飯碗，985搶其他學生飯碗，其他學生搶前輩飯碗，競爭非常激烈，本來解決就業還得靠中小企業，但在計算機行業，大公司利于技術力量，提供了很多同類產品，讓小公司無法生存，比如小公司提供一個辦公平臺，但巨無霸互聯網公司能提供云辦公平臺，

技術寬度

20年前： 掌握精通JavaSE就行，如果掌握JavaEE 那就很資深了， 現在，Java,JavaEE，Javascript和vue系列.Spring系列,SringCoud系列，Apache系列，Hadoop系列，MQ系列，Docker和K8s系列，程式員不得不全面學開發技能，維技能，資料庫和大資料，相當累.你還可能需要掌握Python，對Go要了解！

20年前，技術都很成熟，安裝運行不費勁，各種問題都考慮妥當了， 現在很多技術高速發展，搭建程序燒腦，檔案不齊，產品自身有坑，或者檔案隨時過時，這些新技術為了適應大資料有很多取舍，不注意隨時掉坑，比如ClickHouse雖然快，但不能支持高并發，耗費CPU過大，只有使用了才知道這些坑（雖然官網也指出，但并沒有給出具體參考資料，遠不如20年前商業產品使用輕松），

現在，很多技術都是只需搭建一次就行，比如SpringCoud consul，搭建好開發很輕松，幾乎感覺不到Cloud的存在，但搭建起來非常費勁，因此學習這些技術占用大量時間，然而開發卻幾乎沒有額外負擔，其實一個團隊大部分人都不需要學習Cloud，

20年前，程式員不怎么關心運維的事情，也不怎么關心資料存盤的事情， 現在，你是程式員，必需精通docker，k8s，或者你要精通虛擬機調優，這也是運維做的事情，比如redis集群搭建，一主多從搭建，本質上還是運維的事情，現在也成為開發者必修課，因為從變主，資料未同步時候的處理，這塊還是開發需要考慮，還有很多大資料技術，在未完全成熟情況下，開發也需要參與設計大資料存盤和查詢，

自媒體時代，知識越來越普及，觸手可及的知識，大部分都是用不上，但得學習，所謂的面試造火箭，作業擰螺絲，

演算法20年前還不是所有面試必問，現在已經是無論你是學生，還是作業幾年的，還是資深架構師，演算法都要問，現在賣的最火的書就是跟演算法有關，研究最多的就是演算法，非常像大學，為了考過英語4&6級，放棄學習專業課，大部分時間都背單詞和句子，現在很多大學生刷演算法，對Java基礎反而掌握并不是那么好，對面向物件技能也不重視，比如，一個簡單問題，如果建模，車和輪子是啥關系，簡單的說是一對多關系，但實際上，這個還忽略了一個隱藏物件”底盤“，應該是車有一個底盤，底盤有4個輪子，面向物件一個最重要技能是找出隱藏物件，如果有這些技能，無論是開發企業應用，還是互聯網系統，專案組的人都會輕松很多，精通演算法并不能讓專案開發輕松(除非你的職位就是演算法工程師）

技術深度，越來越要求程式員掌握的更深的技術

20年前，HashMap和HashTable區別，集合框架都有哪些常用類 現在，HashMap如何實作的，描述JDK8前后的實作方式區別，優缺點，

20年前，會學習JVM為什么有client和server倆種模式 現在 ，需要了解java位元組碼是什么，一段Java代碼的位元組碼是什么，虛擬機可能會這段代碼對其做什么優化，以及會在哪些階段做哪些優化？

20年前，會被問到冒泡排序怎么做， 現在，會被問到3億條資料，如果在有限記憶體里完成排序

20年前，請問如何撰寫一個Socket程式接受客戶端的發送的字串 現在，請手寫一個RPC服務器，并描述RPC服務器的關鍵難點，

20年前，Servlet生命周期，只要看一個圖就能了解Servlet生命周期，了解后對編程幫助不大 現在，了解Spring Boot 啟動后，干了些什么事情，需要看一本300頁的書才能了解，了解后對編程幫助同樣不大

經過20年的變化，沒變的是作業主要內容還是增刪改查，大部分難點已經靠框架解決了， 20年的變化，唯一難度降低是的的是面向物件分析，無論是我在作業，還是面試的時候，問到面向物件的問題，都不會得到滿意回答（PS:我覺得缺少面向物件分析能力，就好比只學好了數理化，但沒有學好語文的那種狀態）

敏捷

20年前，用倆周對車進行建模，得出:一個車關聯一個底盤，底盤關聯4個輪子，車本身還有個可選備胎，因此系統有3個物件，剩下還有一個月完成車系統的詳細設計

現在，用1小時對車進行建模，一個車包含四個輪子，系統有倆個物件，設計完畢后，剩下倆周內交付車系統，至于以后發現沒有底盤不行，那是下個迭代的事情，

20年前，對商品定價進行分析，會發現有一個定價域，涉及10幾張表，設計倆周，評審倆周， 現在，商品多一個定價欄位即可，不會給你倆周時間進行定價設計

敏捷先驅們是干外包出身，提出了（所謂的宣言）一個對自己最有利的方法論，這個方法論取悅了專案的各個參與方，但是，這個方法論由于外包原因，局限于戰術方法，不經過思考論證，先做了再說，后果是，反復修改，誰做的快，誰能得到重用，然后做砸了留下了很多坑， 別人還填不了這個坑，還得用此人，只能再給這人配備更多的人員，

我個人不太喜歡scrum，尤其不喜歡研發程序中使用scrum，倆周都要出成果，真的我沮喪，我經常幾天都做不出（或者想不透）一個功能，有時候一個功能做出來了，由于不利于單元測驗，還需要修改，這也讓我無可匯報，進度落后別人，感覺不爽，

敏捷里反復修改的有個前提是單元測驗，國內并不存在”單元測驗“， 而且單元測驗并不像敏捷宣稱那樣簡單，否則，同期就會同步出來一堆應該具備的配套工具，比如mock，TestContainers，dbunit等等，但事實這些工具都是后來逐步開發出來，來填JUnit的坑，我在JD的時候，攔住過研發部門試圖給交易部門提供的一個國外大學研發的工具-可以通過業務代碼自動生成單元測驗以確保覆寫100%，但那玩意不成熟，實際操作坑多，

我自己的開源Beetl和BeetlSQL都有一些單元測驗，但一涉及到業務系統，我對單元測驗就無能為力了，因為太快變化的業務和難以撰寫單元測驗以及難以完成的覆寫率要求，

過度的架構

過度設計和架構20年前也存在，但是當時沒有好的工具和基礎設施，以及當時業務系統多是單庫，放飛的想法飛不到那里去，出錯了易矯正， 現在的過度設計和架構，則很難調整，猶如南轅北轍成語提到一樣，越是有好工具，錯的越離譜，

以前過度設計主要是業務模型過度抽象和軟體過度分模塊，比如，以前所有業務物件都有父物件，父物件有個唯一屬性是id，再比如，每個物件都有一個extAttribute，試圖把未來未考慮到獨享屬性放到這里，這種無聊的過度設計無傷大雅，

現在過度設計在于過度考慮到大資料，微服務，中臺架構，這些架構幾乎不可能再調整，

如果系統剛開始，并沒有足夠多資料，業務也沒有成熟，可以考慮單體和單資料庫，如果一上來就開始用微服務架構，尤其是微服務推薦的一服務一個庫，那會讓系統非常復雜，比如分庫分表，事務處理等，團隊沒有足夠人手和開發周期，會讓程式員非常累，

單體系統到系統拆分，影響不大，如果漸進到微服務或者service-mesh，影響也不大，但如果一服務一資料庫，影響就很大，凡是涉及到有狀態，或者資料持久化，技術難度就上了一個數量級，架構師和程式員都累

對于中臺架構來說，中臺是解決之前太多零散，同功能的小系統，用中臺形成復用， 中臺的前提有倆個，很多零散的同功能系統，以及總結出共性的東西， 如果沒有這倆個，就不要搞中臺，中臺火熱幾年后，現在不是也開始去中臺化，中臺化制約了創新，比如電商公司開展買電影票的業務，那還需在庫存中臺，商品中臺增加若干屬性，這些中臺又不能輕易增加屬性，又是一番扯皮后，商品中臺會妥協的在已有的200多個屬性里再增加幾個電影票屬性，