作者：小傅哥
部落格：https://bugstack.cn
Github：https://github.com/fuzhengwei/CodeGuide/wiki
沉澱、分享、成長，讓自己和他人都能有所收穫！?
一、前言
你只面向工作學習嗎？
如果說程式設計只是單純的承接產品需求開發系統功能，那麼基本可以把程式開發簡單理解成按照需求PRD，定義屬性、建立方法、呼叫展示，這三個步驟。
尤其是在一些大公司中，會有易用的、完善的、標準的架構體系和運維服務，例如：RPC、MQ、Redis叢集、分散式任務、配置中心、分庫分表元件、閘道器等搭配出來的系統架構。也因此讓程式設計師做到只關心業務功能開發！
讓程式設計師只關心業務開發，有成熟的系統架構、有標準的開發流程、有通用的功能設計，對於團隊效能提升來說是非常好的事。但一部分程式設計師正因為有這樣的好事，讓日復一日的歲月做著同樣的事，最後成為工具人。
如果是框架和中介軟體的存在，是了讓程式設計師只關心業務開發。那為什麼你面試的時候會被問到核心元件的設計和原理呢？ 在這個年代，別放棄學習是你幾乎唯一的生存途徑。
二、多執行緒和鎖沒用過？
面試必問的多執行緒、鎖，甚至可能問的還挺深入，比如：AQS、CAS、CLH、MCS、鎖升級、物件頭等等。但在實際的業務開發中，你用到了嗎？可能這也是大部分同學說，面試造火箭的地方！
網際網路應用中有些業務場景開發，確實很少能用到多執行緒，也幾乎不需要你去加鎖。即使你能用到多執行緒的地方也可以用其他更好的方式處理，就像你需要多個執行緒把資料落庫，那麼就可以使用非同步MQ的方式，把壓力分散到各個應用例項上去。而這一開發方式的演變，是因為現在的應用開發和部署都是基於分散式的思想，所以也就很少會有非得用執行緒來壓榨單例項CPU。
在基於RPC+MQ+資料庫路由+閘道器，以及各類配合的元件下，構建出的分散式應用，在某些時候是改變了我們的開發模式的。可能原來我們需要大量使用多執行緒在單個例項下的開發思路，在使用分散式架構後，就需要轉變這一思想，所以隨時而來的使用多執行緒和鎖的場景也會減少。
圖 14-1 分散式簡化的應用部署
但，也不是就沒有多執行緒和鎖的業務場景，就比如我們的核心元件中，資料庫連線池、分散式任務中，都會涉及到多執行緒和鎖的使用。也有一些類似商品秒殺的場景，同樣需要使用到鎖。
那麼，使用多執行緒為了更大限度的利用資源提升效率，加鎖是為了在同一個資源有競爭的情況保證業務流程的正確性。就像：資料庫連線池為了合理分配資料庫資源、商品秒殺是為了庫存的競爭。
可是，在沒有需要競爭和分配資源的情況下，一般並不會在分散式場景下使用到多執行緒。假如我們做一個使用者資源單次計數的操作，那麼原來的應用是單例項還是可以加鎖累加計數的。但現在是分散式應用部署，也就是你可能這一時刻是A例項提供你的需求，當你再次重新整理頁面後可能訪問到的就是B例項。這時候在想做一些例項上的累加，就沒那麼方便了。
這也就是在分散式應用框架的應用中，讓你能用到多執行緒和鎖的地方並不多的原因。但如果你有需要去了解一些中介軟體或者核心元件的設計時，就需要了解相關的核心知識。
很多紙上談兵的技術，也就是你造輪子、造火箭、成為架構師的根基！ 如果你還想奔著這條路能走的更遠，就需要繼續學習。
三、你的成長階段目標？
就程式設計開發這條道路而言，每一個成長階段的目標都會有它隨著帶來的難以攻克的難。
- 上學階段，對突如其來的奇怪知識，想把它在自己電腦執行起來，就很難。
- 工作1~3年，以前掌握的都是毛皮，接下來需要有深度的學習，而深入後都將與數學硬碰硬。
- 工作3~5年，看以前理論性的知識也沒那麼難，但怎麼實際要解決一些複雜專案，還是專心腦幹。
- 工作5~7年，薪資與職位都會成為這個階段非常難以突破的瓶頸，積累不足、沉澱不夠，現狀不滿！
- 工作7~10年，以前覺得什麼都難學，現在可能讓你有空閒時間都難。並不一定年齡到了，本事就到了。
隨著年齡的增長，每一階段都有難以跨越的難。而那些看上去突破了瓶頸，達到了你想要的高度的人。其實每一個階段，他們都跑在前面。
但就單純的技術成長而言，其實理論知識並不難，只要你學就還能會，只是付出的時間成本不同罷了。但過了理論知識這一關後，接下來要面對的是創造能力，也就是為什麼你感覺自己會了那麼多技術內容，但是實際開發時卻總感覺寫不出好程式碼的階段。
會了核心技術但又寫不出好程式碼，就很像是：會漢字但寫不出詩詞歌賦、懂色彩但繪不出山河大川、能蹦跳但舞不出搖曳生姿。
所以，多實戰一些專案程式碼，多看一些設計模式，會讓你更好的理解程式碼該怎麼用，也就能提升突破當前的階段屏障。?推薦小傅哥的《重學Java設計模式》，公眾號：bugstack蟲洞棧，回覆：設計模式，下載。
四、怎麼成長為架構師？
講到架構師，其實真的挺難因為報名一個課程學習完就能成為架構師。架構師的成長更多的取決你們的研發組是否需要一個架構師，也同時需要你在這個崗位起到應有的作用。
如果你還不是架構師，但想成為架構師。那麼還取決於你的老闆是否願意把你培養成架構師，以及你自己的多方面能力是否具備。另外，並不一定高階開發就低於架構師。高階開發有時候比架構師做的事更專一、更核心。
那麼除了圖 14-3 對於架構師的能力概況，有哪些具體的事項呢？
- 定得了規範、設計了架構。
- 有一定的技術深入和廣度，改的了bug、處理得了事故。
- 帶了了小組推進專案落地，也能協同其他組配合。
- 瞭解運營和業務規劃，提前介入產品開發階段。
- 懂得了業務和運營，瞭解資料指標和各項ROI。
- 架構更多的是經驗和經歷的結合，而不是一個單項內容的單一渠道。
- 不是沒有架構師就沒有架構，有時候是一個公司或者小組承接的專案並沒有那麼大，使用成型架構模式即可。
- 但如果有非常複雜的場景設計，都是十幾個系統的分組安排開發，提供服務，支援幾萬秒殺，幾十萬日活，在擴充套件到上百萬DAU，就需要有架構師來把控。
- 再比如：從下單、到交易、到支付、到結算、到活動、到玩法、怎麼支援。這個體量的複雜度才需要有架構權衡。
- 沒有絕對的對和絕對的錯，只是什麼時候更適合罷了。多學一些，別給自己設定邊界，才更好突圍！
做好架構，遠看是部門效率，近看是解決爛程式碼！很多時候的急，可能讓整個工程爛掉。爛的越來越多，最終也會影響業務發展。那麼這些爛程式碼都怎麼來的呢？
- bug很多時候是接手了的爛程式碼或者別人的思路沒有繼續繼承。
- 業務需求簡單開始就寫的沒有擴充套件性，後面也不斷的堆積。
- 沒有很好的結構和命名、也從不格式化。
- 預期不到將來業務走向，設計不出合理的擴充套件性系統。
- 炫技大於整體規劃和設計，一個新技能的引入，但缺少相應的匹配。
- 沒有設計，功能都是流程式，需要啥就寫ifelse。
- 總想一把梭，沒關係的，心裡有抱怨，部門有急功近利，不給你長時間的鋪墊，沒有有人帶，寫不出好東西。
- 組內缺少相應的流程規範和評審，設計評審、程式碼評審，也沒與標杆專案可以參考。
- 懂幾個jdk原始碼從不是寫好程式碼的根本只是基本功。就像老木匠用斧子，新木匠用電鋸，但做出來的東西，有的就好，有的就不好。
- 沒有永遠好的程式碼，如果像程式碼更好，就需要一直維護，一直改造。
- 沒有業務對應的體量，不談QPS、TPS、TP99、TP999，服務健康度，很多空談都是耍流氓。
爛，來自於很多方面，而且這並不是你報名個課程就能學到的。業務、產品、研發，三方共同努力才能更好的減少爛的出現，而這些也是每一個研發都應該努力的方向，也幾乎是你要成為架構師的必經之路。
五、總結
- 寫了這麼多主要是想幫助那些和我一樣在這條路上持續拼搏的同好，可能大家都會在這些階段迷茫過：上學時技術怎麼學、求職時簡歷怎麼寫、工作時個人怎麼成長等等。所以很多時候更多的仍然是自己的剋制和自己的選擇！
- 2020年這已經是12月，有疫情的開始、也有口罩帶的一年、有人股票發財、也有人還不起房貸、有人急躁沒目標、也有人學了不少知識。總歸如何，時間很快！
- 你用劍、我用刀、都有目標、都很風燒！ 繼續加油！