學習的兩個目的：
應付面試
應付作業（解決問題）
首先要明白學習的目的，不同階段，不同技術的學習目的是不一樣的，
有些技術，僅僅是應用級別的，有些技術是原理級別的（主要還是應試），所以不同技術、不同時間學習方式需要改變，
學習方法：
mysql、redis等日常使用技術：
直接就要熟練掌握，因為日常作業經常使用，忘記說不過，
分布式微服務技術：
組件用來解決什么問題；思想是什么；會帶來什么新的問題，新的問題怎么解決？
分布式技術就是用來解決各種分布式問題的組件，體系龐大，涉點面廣，主要對應于具體的業務問題，所以學習時了解原理，會應用就行了，原始碼什么的，面試前挑選兩個核心、經典組件了解下核心原理（主要記結論）
專案
不得不說，外包的專案是真的很水，水到自己看著都發慌，
那如果你專案很水，怎么準備面試呢？
首先專案水，不代表你水，這就需要你具備一定的架構思想，
- 第一，在面試中，并不是只能展示自己的那些誰都會寫的CURD，你參與在整個大的專案當中的科技與狠活，只要你了解過的都可以聊，專案中所有東西都和你有關的，所以多花點時間多了解下別人做的事情，對你是有好處的，
- 第二，就算專案再水，也一定涉及到專案選型，這就是你可以吹的地方，至于你到底參與了多少，反正面試官也不知道，只要你準備好，解釋的通就好了，比如你對比了一下產品，看了下他們各自支持哪些功能，評估了一下落地成本和運維的復雜度，并且了解了一下他們的學習成本和團隊的上手速度，調研了一下這個產品的開源支持力度，最終再結合實際業務情況，選擇了某某產品，而且呢我還去了解了一下他的核心原理是啥啥啥，如果面試官說你這個方案不完美，那你就直接說：”我當然知道這個方案不完美了，我也知道其中問題有哪幾點，但是綜合評估下來呢，這個方案更適合我們當時的情況，“
- 第三，就算你的專案很古老，你的參與度很低，那也不是一無是處的，線上問題總會遇到過，就算你自己沒遇到過，同事總遇到過，同事也沒遇到過那就編一個線上問題往簡歷上寫，比如幫助同事排查并解決了慢SQL問題、多次解決過CPU飆高的問題、記憶體泄漏問題、對于頻繁的FullGC有解決經驗等等，那關于這些問題到底是怎么回事，去網上搜相關文章，模擬一下問題的發生，并嘗試這解決一下，然后重點來了，按照這個腳本準備，”問題是怎么發生的，是怎么發現的，當時的現象是什么，具體有哪些指標，你怎么排查的，排查之后的解決方案是什么，解決之后的指標是怎么樣的，“
- 第四，實在水到沒有亮點，那就推翻原設計，架構重構思想，自己創造亮點，把本來不合理的設計替換成更合理的方案，借鑒別的專案還是自己憑經驗技術來都行，合理就行，
總之就是想盡一切辦法告訴面試官，我和別人不一樣，不要我就是你們的損失，就算我的專案很水，但是我一點不水，
原始碼：
原始碼這種東西主要是用于應試的，像spring原始碼這種東西，平時沒誰去管它，又用不上，所以理解核心原理和流程就行了，沒必要去死摳原始碼，因為摳了也記不住，找作業前再去學習閱讀就可以了，或者你像寫相關博客帖子的時候再去學習，
資料結構、設計模式、演算法等東西：
理解思想是什么，有什么特點，用來解決什么問題就行了，
主要還是用于應試（筆試刷題，面試也就是思想），這種東西雖然重要，但是和數學相關度很大，還不是面向百度編程，所以主要就是理解思想，面試刷題，作業面向百度，
JVM：
原理偏多，理解優先，面試前復習+刷題，
并發、多執行緒：
難度最大，作業中也可能會用，
學習以原理為主（真正理解），反復復習，應用還需在正式開發中提升，
其他語言：
建議選擇GO語言作為第二語言，按照行業趨勢，Java必然被GO語言逐漸蠶食，市場份額越來越小，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/538871.html
標籤：架構設計
上一篇：一言不合就重構
下一篇：(Java)設計模式：創建型