先說一下大多數新手的情況：就是對着視訊敲 Java 項目，其中遇到的 BUG 還能解決，但就是每次敲完一個項目，就感覺很空虛，項目裡面的知識點感覺懂了但又好像沒懂，應該怎樣才能掌握一個項目所用的知識點呢？
先分享一位好朋友丁威的經驗吧，他是《RocketMQ技術内幕》一書的作者。他在嘗試學習 RocketMQ 之前未曾接觸過消息中間件，但硬是通過自己提煉的學習方法，最終成為 RocketMQ 社群的優秀布道師。這讓他有了一個非常亮眼的标簽，極大提高了職場競争力。
他的總結有以下四點：
了解這個項目的使用場景、以及架構設計中将承擔的責任。
尋找官方文檔，從整體上把握這個項目的設計理念。
搭建自己的開發調試環境，運作官方提供 Demo 示例，為後續深入研究打下基礎。
先主幹流程再分支流程，注意切割，逐個擊破。
我認為是非常有道理的。記得我一開始參加工作的時候，拿到上司安排的項目後，非常懵逼，完全不知道該如何下手，不知道自己該幹嘛。去問上司，上司說沒時間，要我自己先研究研究，研究什麼呢？
一開始當然毫無頭緒，後面就慢慢琢磨出來了一點小心得。
先從項目的需求文檔下手，先了解這個項目是幹嘛的，了解個大概，就不慌了。然後把這個項目的源碼在本地跑起來，“跑起來”，說着簡單，真正做的時候還是挺難的，我記得我當時跑第一個項目差不多用了一周多的時間，因為我的開發環境和項目要求的有一些不一樣，就導緻出了很多問題。
我印象很深刻的問題有兩個，第一個就是亂碼了，類似下圖這種。
第二個就是編譯出錯，原因很簡單，JDK 的版本不一樣。
這兩個問題雖然簡單，但特别常見，真的，新手基本上都會遇到。一開始遇到的時候是很慌的，因為源碼肯定不會有問題，有問題的肯定是自己的開發環境。
折騰了一周多的時間，項目終于跑起來了。
我讓自己體驗了一把測試的角色，就是把能操作的按鈕全點一遍，體驗一下項目哪些已經開發完成了，哪些還沒有。沒用多久，我就測出來了兩三個新 bug，基本上都是一些非正常操作引起的，雖然我沒能解決，但報告給上司後，上司還是很驚訝的，他看我的小眼神，多少有點看吳下阿蒙的感覺，“小夥子，有長進啊！”
然後，我并沒有着急去開發上司安排給我的任務，而是去看同僚已經完成的代碼，當然是帶着問題去看的，為什麼他會這麼寫？這麼寫的好處是什麼？如果換做是我，我會怎麼實作？這其中的差别是我自己考慮不周嗎？
當然了，我不會看太細緻，因為有些内容超出了我的技術範圍，我看不懂的，隻能是“走馬觀花”，大緻看明白是什麼意思就“得過且過”了。
這裡提醒大家一點的是，千萬不要陷入技術細節，尤其是一開始做項目的時候，因為自己不了解業務，再加上技術水準可能達不到，研究技術細節很容易就陣亡了。
另外一點就是，基本功一定要紮實，不要連整體的代碼脈絡都看不懂，那樣就很吃力了。我這裡有一份 GitHub 上星标 115k+ 的 Java 教程，裡面涵蓋了 Java 所有的知識點，包括 Java 文法、Java 集合架構、Java IO、Java 并發程式設計和 Java 虛拟機，内容不多，隻講重點。
GitHub 星标 115k+的 Java 教程，超級硬核！
盡量花一點時間鞏固一下基礎，不要讓自己太被動。遇到自己生疏的知識點，就主動去查一下。
看源碼的時候，自己加一些日志啊，加一些斷點啊，去跑一跑。有時候，不加斷點，隻是去看源碼很可能會忽略掉一些關鍵的技術細節，因為 Java 是多态的，有些地方看源碼隻能看到類和類之間的層次關系，卻看不到子類是怎麼重寫父類方法的，或者實作類是怎麼實作接口的，通過調試就可以看的很明白。
還有一些分支語句啊，如果隻是看源碼可能不明白進入這個分支的條件是什麼。還有一些比較關鍵的技術細節啊，隻看源碼可能懵懵懂懂的，跟着斷點一步步地深入可能就全明白了。
舉個例子，拿 StringBuilder 的 append() 方法來說吧。StringBuilder 的内部是通過字元數組（Java 8）實作的， 如果新添加的字元串長度超出了數組的長度，是要進行擴容的。加了斷點後，遇到需要擴容的情況就能看到 JDK 的内部是怎麼來進行擴容的啦，如下圖所示。
一般來說，項目都是比較龐大的，代碼會比較多，這時候最好隻關注一個子產品，就是自己通過需求文檔，或者閱讀源碼了解最多的子產品，盡量把這個子產品的整體邏輯給吃透了，如果上司恰好安排你做的這個子產品的業務代碼，那你的上手難度就大大降低了！
再總結一下：
拿到項目後，不要着急動手，先看文檔，尤其是需求文檔。
把項目的源碼在本地跑起來。
做一些測試，看能不能測出一些邊界的 bug。
關注一個子產品，去研究一下源碼，但不要過于深究技術細節。
我再給大家推薦兩個優秀的 Java 開源項目吧，如果你還沒有參加工作，可以拿這兩個項目作為練手項目。
SpringBoot 完整電商系統 Mall：包括前台商城系統及背景管理系統，基于 SpringBoot+MyBatis 實作。
vhr：微人事是一個前後端分離的人力資源管理系統，項目采用 SpringBoot+Vue 開發。
我之前做的一個電商項目還用了 mall 作為基層的架構！mall 的學習教程非常全面，作者直接做了一個線上的網站，基本上用的技術都講述得特别明白！
vhr 目前在 GitHub 上已經有 20.8k 的 star，屬于很強的那種了。
後端技術棧
Spring Boot
Spring Security
MyBatis
MySQL
Redis
RabbitMQ
Spring Cache
WebSocket
…
前端技術棧
Vue
ElementUI
axios
vue-router
Vuex
vue-cli4
基本上主流的前後端技術都用到了。作者為初學者特意錄了項目的部署視訊教程，很貼心~
文檔寫得特别全，我簡單列舉下。
權限資料庫設計
服務端環境搭建
動态處理角色和資源的關系
密碼加密并加鹽
服務端異常的統一處理
axios 請求封裝,請求異常統一處理
将請求方法挂到Vue上
登入狀态的儲存
登入成功後動态加載元件
角色資源關系管理
使用者角色關系管理
基本上每個知識點都有對應的文檔，文檔齊全的話，對吃透項目是極好的幫助。
嗯，最後強調一點，大家在做練手項目的時候，一定記得寫注釋。我在很多地方看到這樣一個觀點，“請停止寫注釋，因為隻有爛的代碼才需要注釋。”這個觀點非常巧妙，它讓我想起了孟子的一句話，“楊氏為我，是無君也；墨氏兼愛，是無父也。無父無君，是禽獸也。”
Java 源碼的作者絕對是這個世界上最優秀的程式員，連他們都寫注釋，那些聲稱“請停止寫注釋”的号召者是不是要啪啪啪地打臉，直到打腫為止。
拿 String 來說吧，要了解這個類，直接看類的注釋就足夠了，寫得非常詳細。
一個優秀的 Java 項目也應該是這樣的，注釋必須到位，不然别人怎麼吃透，吃不透的。隻能說一句，Java 源碼的作者，yyds（陰陽大師，hhh）。