歡迎關注我的公衆號:石杉的架構筆記(ID:shishan100)程序員
週一至週五早8點半!精品技術文章準時送上!面試
(1)80% Java工程師都有的迷茫redis
(2)你的技術爲啥十年八年都沒法進步?算法
(3)追求卓越,本身設立技術挑戰spring
(4)幻想一步登天?那只是你的黃粱好夢數據庫
(5)不斷提高本身,最後進入BAT緩存
(6)最後的寄語性能優化
這篇文章,跟你們聊一聊不少不少不少人問個人一個問題:中小公司的Java工程師應該如何規劃準備,才能跳槽進入BAT這類一線互聯網公司?mybatis
之因此我用了三個 「不少」 來形容這個問題,是由於實在這個問題太廣泛了,由於國內Java工程師至少好幾十萬,可是在國內互聯網大廠裏幹過的碼農可能也就十分之一,或者五分之一的比例。架構
因此,其實這個也是符合28法則的,少部分人在大廠裏幹過,發展的很好。可是大部分人仍是在中小型公司,或者外包類傳統IT公司裏工做。
這些同窗可能對本身的技術成長,職業發展感到很是的迷茫,本身有點追求,也想去一下大廠,可是又不知道怎麼規劃。
開始本文以前,一樣強調一點:像這種講職業規劃發展的文章,有可能不少同窗會覺得是廣告。可是這篇文章,筆者特地聲明:純乾貨、非廣告。
由於我我的在國內幾個最大的互聯網公司前後有着十餘年工做經歷,面試和招聘過大量各類水平的開發人員。包括初、中、高級開發,技術專家,高級技術專家,都面過。
一樣,也指導過不少同窗的職業發展規劃,看過大量的同窗不順利的職業發展,因此打算從我我的的角度來聊聊這個問題:中小公司的同窗應該如何一步一步實現逆襲進入BAT。
我相信如下情形不少同窗應該都有相似體會:一直徘徊在各類中小公司裏開發一些沒技術難度的Java系統,主要就是CRUD。
哪怕是用了用MQ、緩存、分庫分表,可是也沒什麼併發量,數據量也不算特別大,本身的技術成長極爲緩慢。
而後就是三五年,七八年,甚至十多年,職業發展和技術水平都停滯在這個狀態,沒法有更進一步的發展。
隨着如今寒冬到來,處處裁人,中年碼農的危機,加不動班,體力愈來愈差,孩子壓力愈來愈大,對本身何去何從很迷茫。
有一些同窗是一直徘徊在那種中小型互聯網公司裏碰到上述狀況,有一些同窗是在一些外包類的IT公司裏碰到上述狀況。
先來搞清楚一個問題,你的技術到底爲何十年八年都沒法進步?
拆解一下,你的能力集中在哪幾塊:
技術廣度
對MQ、緩存、NoSQL、大數據、高併發、高可用、微服務,等一系列的相關技術都有必定的瞭解,熟悉常見功能 在本身的項目裏落地使用過,有必定的技術使用經驗
這能夠解釋爲技術廣度。
技術深度
讀過Kafka的底層源碼? 對消息中間件的架構設計思想有深入的理解? 對分佈式事務框架/中間件的架構設計有過研究? 在每秒百萬併發場景下作過底層系統的深刻優化和故障處理? 若是你有相似這種過人之處,那麼你才能說你有某些技術深度。
項目經驗
你有沒有總體負責過幾億註冊用戶,幾千萬日活用戶的大規模、高併發、分佈式、高可用、高複雜度的系統架構設計? 或者你負責的一直都是那種公司內部使用的,幾十我的用的OA系統,CRM系統? 這些就是你的項目經驗
*團隊管理
你在互聯網公司裏帶過20的團隊? 或者你在一個傳統IT公司裏帶過3我的的小組? 這都是你的團隊管理經驗。
拆解事後,再來看看,若是你在一些小型互聯網公司,或者是作一些傳統軟件開發,爲何技術沒法進步?
其實道理很簡單,可能你的公司推出了一款APP,可是很差意思,用戶量總共就100萬,日活用戶就10萬人。
那你以爲你的系統有技術挑戰嗎?沒有。
既然沒有技術挑戰,你把系統搞那麼複雜幹嗎?或者你的架構師搞那麼複雜幹嗎?不須要。
你們簡單作一作,主要crud寫一下功能,最多如今spring cloud流行了,上一下拆成微服務的就夠了。
而後這套系統就穩定支撐你公司的業務了,那你接觸不到很大的技術挑戰,因此技術進入停滯狀態,不是很正常麼?
或者你作一些傳統的軟件開發,好比說建築類軟件,辦公自動化軟件,相似這種的。總共就幾十我的用一個系統,或者幾百人用,那你就更是如此了。
可能都不須要spring cloud,直接單塊系統,單機部署,就是在裏面填充業務代碼就行了。
因此根本緣由,就是不少同窗平時的工做環境,他沒有什麼技術挑戰,因此只要把系統技術作的簡單一些,低成本就能夠支撐公司業務了,那既然這樣,固然技術就進展很緩慢了。
而後可能你工做了八年十年,技術廣度還能夠,對流行的技術本身都看過一些書,簡單用過,玩過demo。
你的項目經驗積累了很多,可是都是一些各個傳統領域的系統業務理解較爲深入,沒有極高技術挑戰的項目經驗。
有的人工做時間長,可能就是帶過一些人,有過一些帶團隊的經驗,能管人。
大概就是如此了,每次換工做,仍是隻能換相似的公司,幹相似的技術,依然沒有進步,依然是相似的項目經驗。
因此大夥兒先梳理清楚,迷茫的根源究竟在哪裏。
一般來講,我我的站在公司角度是很反對架構的過分設計的,由於平白浪費不少時間,並且不少架構過分複雜沒有必要。
可是若是是站在我的的職業發展角度而言,那麼你的leader必需要有對技術追求卓越的思惟。或者你是leader的話,就得有對你的團隊技術追求卓越的品質。
什麼叫追求卓越呢?
舉個例子,如今你開發了一款辦公自動化系統,服務了某個公司,幾百人在用,那麼技術通常,就是一個單塊系統,直接Spring MVC + Spring + MyBatis就搞定了。你們都作着沒意思。
好,如今leader爲了你們的幸福和將來,咬咬牙說:
Leader
兄弟們,如今系統知足公司的發展了,可是咱們不如來大膽的追求一下卓越。
兄弟們
領導你是啥意思啊??
Leader
這樣,我們首先爲了提升系統的開發效率,避免30個兄弟開發一個單塊系統效率過低,咱們來實踐一把最流行的微服務架構吧。
我們一塊兒來把系統重構成微服務的架構,把spring cloud整套東西都用進去。
兄弟們
(認真聽着)
Leader
我們先得作技術調研,小A你來研究研究Spring Cloud核心技術組件,小B你來研究研究配置中心,小C你來研究研究服務鏈路追蹤,等等。
你們分頭行動,都開始學起來新技術。可是呢,我們平時已經很忙了,要是佔用工做時間搞這個,老闆會罵人,你們看,每一個人天天額外加班抽2小時一塊兒來搞一下,怎麼樣?
兄弟們
領導,爲了你們的幸福,那確定得趕忙上新技術啊,你們都學點新東西。
最後你們辛苦了2個月,一塊兒把系統重構成了整套的微服務架構,每一個人都學到了東西,領導也學到了微服務總體架構設計的能力。
Leader
兄弟們,還想不想繼續爲將來的幸福努力一下?
兄弟們
一切都聽領導安排。
Leader
如今這破系統就幾百人用,忒沒意思了,我們來大膽想象,假如說之後這個系統要作成SaaS雲產品,會有幾百個公司來用,有幾萬人,甚至幾十萬人同時使用一套後臺系統。大夥想一想,那時會怎麼樣?
兄弟們
貧窮限制了個人想象力。。。。
Leader
那小A你去根據如今系統的訪問量估算一下,若是有幾十萬人用,系統天天的併發量會有多少,數據庫能不能支撐住,須要用哪些高併發的技術來支撐?
小B,你去調研一下,若是有幾十萬人用,咱們會存儲多少數據量,性能會有多差,怎麼支撐海量數據存儲?而後看看用什麼技術來支撐一下?
兄弟們
好,領導一句話,上刀山、下火海。
幾個月後,你們研發了一套系統,完成了測試,系統集成了緩存集羣、MQ集羣、分庫分表技術,還有不少其餘的一些東西。
這個時候領導就想辦法了,能不能跟老闆建議一下,我們就把產品作成SaaS雲的模式呢?而後是否是能夠就把這套系統給部署到生產環境裏去?
到此爲止,就經過一個例子,給你們闡述了一下,本身在公司裏,如何經過想辦法不斷的追求系統的卓越,提升研發效率,支撐也許可能會存在的更高的併發量,更多的數據量,儘量把系統作的更好一些。
多想一想爲了解決本身設想的一些技術挑戰,如何儘量把一些業界經常使用的技術都學習一下,好比緩存、消息、分佈式、微服務、大數據,等等。
而後都儘量進行相關的實踐,積累相關的項目經驗。
實際每一個人在落地的這個過程的時候,方式確定是不同的:有的人也許人微言輕,只能對本身負責的模塊設想一些技術挑戰,而後只能本身在本地拉一個公司代碼分支,嘗試對這些分支加入一些技術,本身練習思考。
還有的人,多是個小leader,沒法左右公司產品發展方向,可是能夠儘量跟上級溝通,闡述本身對系統架構追求卓越的一些構想。
而後,爭取到一些時間,儘量把系統多融入一些技術,給作的好一些。
每一個人都有每一個人的方式,可是歸根到底一句話:若是你自己工做沒有技術挑戰,那麼儘量多給本身設立一些挑戰,多學一些技術,多作一些嘗試和實踐。
這老是能夠儘量幫助你在必定程度上提升技術,擴展技術知識的。
在這個階段,我見過最多的人犯的最大的一個錯誤就是:以爲本身這樣倒騰一些技術是沒用的,沒有實際的真正的經驗。
而後他們着急忙慌,心浮氣躁,自怨自艾,總想着必須得先進一個好的公司,才能鍛鍊技術。
實際上,這是一種很浮躁的想法,你要進好的公司鍛鍊,你必須先打磨一下本身的技術,而後纔能有資本去一家更好的公司。
不少人多學了一些技術,有了一些經驗,很容易開始有點膨脹,總是想着一步登天,一會兒就進入BAT。
關於這個,實際上是有相似的一些成功經歷,好比有的人是大專學歷,經過本身的努力學習,加上一些機緣巧合,直接一會兒就從中小公司跳入了BAT。
可是就現實狀況來看,不是每一個人都必定能夠一步登天,複製這個經歷的。
在你學習了一些技術,同時本身多作了一些嘗試,積累了必定的經驗以後,此時應該作的是:作最壞的打算,抱最好的但願。
你徹底能夠去試試BAT的面試,TMD的面試,儘量去爭取機會,可是若是沒面上也無所謂。
你能夠下降指望,人只要跟本身比就行了。
好比說你如今在某小型的傳統外包軟件公司,那麼接下來若是你能面進一家小型創業互聯網公司,有個幾百萬用戶量,日活用戶有幾十萬,比以前的公司技術挑戰多一些,用的技術也更多一些,那麼你就能夠去了。
只要你每一步跳槽,都比以前好,都讓本身有進步,那麼總體的大方向就是沒錯的。
也許你先進一個創業型互聯網公司,而後下一家就能夠進入一個市值幾十億美金的上市互聯網公司,再下一步就能夠進入BAT。
在這個階段我見過不少人犯的最大的錯誤就是:總是以爲本身剛學了一點東西,就必須立馬進大公司。
這些同窗每每心態着急的不行,而忽略了本身的學歷、背景、經驗致使了起點較低。能立馬進BAT固然很好,可是有時候機緣巧合緣分沒到,進不去也正常。
在這個階段最須要作的,就是跟本身比,別跟別人比,只要每一次跳槽都比上一次好,公司更大,薪資更高,職位更高,技術挑戰更大,就能夠了。
一旦你開始作到跳槽進入一家比以前更好的公司,有更高的技術挑戰,那麼公司自己的技術挑戰就會促使你快速成長,仍是舉個例子吧。
好比說你原本就在作傳統軟件的開發,用的都是單塊系統涉及的一些技術,就是簡單的spring mvc、spring、mybatis等技術作CRUD的業務開發。
可是呢,你經過追求卓越,本身業餘不停的學習技術,而後對本身負責的一些模塊多設立了一些技術挑戰,本身構思了不少更高挑戰的場景下,能夠給本身的模塊加入哪些更高階的技術。
接着你帶着本身學習的一些技術,還有積累的一些實踐經驗和思考,進入了一家創業型互聯網公司。
這家公司的好處就在於,互聯網公司技術氛圍更好,好比zookeeper、redis、rocketmq、sharding-jdbc,等各類技術,在公司生產環境的系統裏,都有落地和使用。
那麼你此時是否是就不用停留於一些技術挑戰的構思,能夠開始真正作一些有點技術挑戰的工做了。
可是,此時你仍是須要繼續不停的學習技術,學習更多的架構上須要的技術,深刻的學習技術,同時積累實踐經驗。
而後帶着這份工做經歷,同時加上你不斷增強的技術學習,你進入了一家好比30億美金估值的獨角獸公司。
這家公司有2000萬用戶,日活用戶達到百萬級,高峯併發量能夠過萬,天天數據庫裏日增數據量達到了數十萬。
此時你開始真正接觸一些所謂的:高併發、高可用、高性能、海量數據的實際處理。
基於你開發的業務系統,你開始更多的實踐,同時你還對各類涉及到的技術有了更加深刻的研究,好比對一些核心中間件系統進行了源碼級別的閱讀和研究。
最後你終於等到一個機會,BAT裏某家公司讓你去面試,經歷了四五輪面試以後,對方給了你一個offer,是年薪40萬的高級Java工程師的職位。
而後你進去以後,能夠在最頂尖的互聯網公司裏學習開發流程、規範、架構,接觸到最大規模的用戶量,天天都有解決不完的技術挑戰,在這個過程當中,你又能夠繼續成長。
最後可能你再次跳槽,就能夠進入TMD中某一家,拿下技術專家的offer,在大公司裏拿下技術專家的職位,帶一個團隊,達到人生第一個巔峯。
接着你再跳槽,可能一些創業公司就開始挖你去作一些技術管理層。
你們別覺得這個僅僅是筆者捏造的一個故事,在筆者指導過的同窗中,確實有同窗按照這個路線,實現了人生的逆襲!
最後,送你們一句話:九層之臺,始於壘土;千里之行,始於足下。
這裏面最難的就是開始的那一步,也就是大量的人都停留在一些徹底沒太多技術含量的技術工做的狀況下,這個時候是最難熬的。
其實只要能把第一步走好,本身拼命的積累技術,努力跟其餘工程師競爭,技術遠超跟本身同狀況的其餘工程師,那麼你就有機會率先脫離這種困境,開始慢慢第二步,第三步。
到了後面,就是讓公司的技術挑戰push你不斷努力和進步,最後進入BAT這類一線互聯網公司。
若有收穫,請幫忙轉發,您的鼓勵是做者最大的動力,謝謝!
一大波微服務、分佈式、高併發、高可用的原創系列文章正在路上
歡迎掃描下方二維碼,持續關注:
石杉的架構筆記(id:shishan100)
十餘年BAT架構經驗傾囊相授
推薦閱讀:
二、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問?
三、【性能優化之道】每秒上萬併發下的Spring Cloud參數優化實戰
六、大規模集羣下Hadoop NameNode如何承載每秒上千次的高併發訪問
七、【性能優化的祕密】Hadoop如何將TB級大文件的上傳性能優化上百倍
九、【坑爹呀!】最終一致性分佈式事務如何保障實際生產中99.99%高可用?
十一、【眼前一亮!】看Hadoop底層算法如何優雅的將大規模集羣性能提高10倍以上?
1六、億級流量系統架構之如何設計全鏈路99.99%高可用架構
1八、大白話聊聊Java併發面試問題之volatile究竟是什麼?
1九、大白話聊聊Java併發面試問題之Java 8如何優化CAS性能?
20、大白話聊聊Java併發面試問題之談談你對AQS的理解?
2一、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥?
2二、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化
2三、互聯網公司的面試官是如何360°無死角考察候選人的?(上篇)
2四、互聯網公司面試官是如何360°無死角考察候選人的?(下篇)
2五、Java進階面試系列之一:哥們,大家的系統架構中爲何要引入消息中間件?
2六、【Java進階面試系列之二】:哥們,那你說說系統架構引入消息中間件有什麼缺點?
2七、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷
2八、【Java進階面試系列之三】哥們,消息中間件在大家項目裏是如何落地的?
2九、【Java進階面試系列之四】扎心!線上服務宕機時,如何保證數據100%不丟失?
30、一次JVM FullGC的背後,竟隱藏着驚心動魄的線上生產事故!
3一、【高併發優化實踐】10倍請求壓力來襲,你的系統會被擊垮嗎?
3二、【Java進階面試系列之五】消息中間件集羣崩潰,如何保證百萬生產數據不丟失?
3三、億級流量系統架構之如何在上萬併發場景下設計可擴展架構(上)?
3四、億級流量系統架構之如何在上萬併發場景下設計可擴展架構(中)?
3五、億級流量系統架構之如何在上萬併發場景下設計可擴展架構(下)?
3七、億級流量系統架構之如何保證百億流量下的數據一致性(上)
3八、億級流量系統架構之如何保證百億流量下的數據一致性(中)?
3九、億級流量系統架構之如何保證百億流量下的數據一致性(下)?
40、互聯網面試必殺:如何保證消息中間件全鏈路數據100%不丟失(1)
4一、互聯網面試必殺:如何保證消息中間件全鏈路數據100%不丟失(2)
4三、高併發場景下,如何保證生產者投遞到消息中間件的消息不丟失?
4五、從團隊自研的百萬併發中間件系統的內核設計看Java併發性能優化
4六、【非廣告,純乾貨】英語差的程序員如何才能無障礙閱讀官方文檔?
4七、若是20萬用戶同時訪問一個熱點緩存,如何優化你的緩存架構?
做者:石杉的架構筆記 連接:juejin.im/post/5c263a… 來源:掘金 著做權歸做者全部,轉載請聯繫做者得到受權!