內卷

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

20年前,，清華北大去的是中科院，研究院,，或者某事業(yè)單位?，F(xiàn)在，在各個軟件公司,，都有清華北大的影子,，2011年在網(wǎng)易的時候，就發(fā)現(xiàn)身邊都是清華北大學生,，當時感覺很奇怪,，現(xiàn)在倒是也能站長博客想得通，畢竟科研單位只有家里不差錢,，才能安心搞研究,。

20年前，能精通一本技術手冊就已經(jīng)是屬于資深人員,，比如Oracle官方文檔或者是JavaEE規(guī)范,，或者Weblogic官方文檔

現(xiàn)在，程序員要看很多手冊,，涉及開發(fā),，運維，數(shù)據(jù)庫,，安全,。 這些手冊隨著產(chǎn)品變化迭代也很快，學不過來,。

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

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

技術寬度

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

20年前,，技術都很成熟,，安裝運行不費勁，各種問題都考慮妥當了,。 現(xiàn)在很多技術高速發(fā)展,，搭建過程燒腦，文檔不齊,，產(chǎn)品自身有坑,，或者文檔隨時過時。這些新技術為了適應大數(shù)據(jù)有很多取舍,，不注意隨時掉坑,，比如ClickHouse雖然快，但不能支持高并發(fā),，耗費CPU過大,，只有使用了才知道這些坑（雖然官網(wǎng)也指出，但并沒有給出具體參考數(shù)據(jù),，遠不如20年前商業(yè)產(chǎn)品使用輕松）,，

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

20年前，程序員不怎么關心運維的事情,，也不怎么關心數(shù)據(jù)存儲的事情,。 現(xiàn)在，你是程序員,，必需精通docker,，k8s，或者你要精通虛擬機調優(yōu),。這也是運維做的事情,。比如redis集群搭建，一主多從搭建,，本質上還是運維的事情,，現(xiàn)在也成為開發(fā)者必修課，因為從變主,，數(shù)據(jù)未同步時候的處理,，這塊還是開發(fā)需要考慮。還有很多大數(shù)據(jù)技術,，在未完全成熟情況下,，開發(fā)也需要參與設計大數(shù)據(jù)存儲和查詢。

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

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

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

20年前，HashMap和HashTable區(qū)別,，集合框架都有哪些常用類 現(xiàn)在,，HashMap如何實現(xiàn)的，描述JDK8前后的實現(xiàn)方式區(qū)別,，優(yōu)缺點,。

20年前，會學習JVM為什么有client和server倆種模式 現(xiàn)在 ,，需要了解java字節(jié)碼是什么,，一段Java代碼的字節(jié)碼是什么，虛擬機可能會這段代碼對其做什么優(yōu)化,，以及會在哪些階段做哪些優(yōu)化,？

20年前，會被問到冒泡排序怎么做,。 現(xiàn)在,，會被問到3億條數(shù)據(jù)，如果在有限內存里完成排序

20年前，請問如何編寫一個Socket程序接受客戶端的發(fā)送的字符串 現(xiàn)在,，請手寫一個RPC服務器,。并描述RPC服務器的關鍵難點。

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

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

敏捷

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

現(xiàn)在,，用1小時對車進行建模,，一個車包含四個輪子，系統(tǒng)有倆個對象,，設計完畢后,，剩下倆周內交付車系統(tǒng)。至于以后發(fā)現(xiàn)沒有底盤不行,，那是下個迭代的事情,。

20年前，對商品定價進行分析,，會發(fā)現(xiàn)有一個定價域,，涉及10幾張表，設計倆周，評審倆周,。 現(xiàn)在,，商品多一個定價字段即可，不會給你倆周時間進行定價設計

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

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

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

我自己的開源Beetl和BeetlSQL都有一些單元測試,，但一涉及到業(yè)務系統(tǒng)，我對單元測試就無能為力了,，因為太快變化的業(yè)務和難以編寫單元測試以及難以完成的覆蓋率要求,。

過度的架構

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

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

現(xiàn)在過度設計在于過度考慮到大數(shù)據(jù),，微服務,，中臺架構，這些架構幾乎不可能再調整,，

如果系統(tǒng)剛開始,，并沒有足夠多數(shù)據(jù)，業(yè)務也沒有成熟,，可以考慮單體和單數(shù)據(jù)庫,，如果一上來就開始用微服務架構，尤其是微服務推薦的一服務一個庫,，那會讓系統(tǒng)非常復雜,，比如分庫分表,，事務處理等。團隊沒有足夠人手和開發(fā)周期,，會讓程序員非常累,。

單體系統(tǒng)到系統(tǒng)拆分，影響不大,，如果漸進到微服務或者service-mesh,，影響也不大，但如果一服務一數(shù)據(jù)庫,，影響就很大,。凡是涉及到有狀態(tài)，或者數(shù)據(jù)持久化,，技術難度就上了一個數(shù)量級,，架構師和程序員都累

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

總結一下，搞開發(fā)20年了,，以前的加班真的是在加班,，現(xiàn)在反而沒有加班了,真開心