看到ITFriend中有些小夥伴剛進入公司，面對大量的項目代碼，往往手足無措，有點慌，我說下我的經歷。
聲明：我從事的是C++開發工作，閱讀的代碼都是基於客戶端/服務器的，以下談的是C++項目代碼的閱讀方法多些
希望懂java的小夥伴分享下java公司項目代碼的閱讀方法，小弟感激不盡。
編譯代碼把項目跑起來 代碼到手以後，先嚐試着編譯一下，無非就是庫的配置，庫路徑的配置，缺少某個文件，或者頭文件包含路徑不正確，一般公司給你的代碼都可以編譯成功，windows平臺下一般使用vs工具來編譯，集成調試工具，而Linux下編譯.使用gcc（g++）編譯器 make工具或者automake工具，具體用法在搜索引擎上能找到。編譯成功以後把項目跑起來，我喜歡看看客戶端長啥樣，哈哈，恭喜你，邁出了第一步
看項目文檔，和項目開發人員（維護人員）進行溝通 公司的項目代碼會有相關的設計文檔，比如XX項目概要設計文檔、XX項目詳細設計文檔、XX項目模塊設計以及之間依賴關係的文檔等等，通過這些文檔，軟件開發人員起碼對項目有個整體的認識，比如項目本身是解決什麼領域問題的？有哪些功能模塊以及他們的大體功能是什麼？使用了什麼開源庫？通過文檔還可以瞭解到代碼中的一些數據結構的詳細註釋，網絡傳輸是如何設計的，使用了哪些協議？數據庫中的字段是如何設計的，以及數據庫中各個表之間的關係。在看代碼的過程中，遇到模糊不清或者自己拿不住的代碼，要及時和同事溝通，他們對代碼的熟悉程度比我們強，虛心有禮貌的問人家。否則自己在那憋着瞎猜代碼的含義，費時費力還得不償失，開口求人幫忙就那麼難？嘻嘻，你幫我下，我幫你下，咱倆慢慢就熟悉了嘛
搞清楚程序的流程和大體框架，具體功能模塊具體分析 從main函數開始，把客戶端和服務器怎麼工作的流程大致的看一下，客戶端如何連接服務器段的？服務器客戶端是如何進行數據交互的？在關鍵的地方下斷點，看看客戶端發送來的內容是什麼，服務器在接收到客戶端發送來的消息後是如何處理的。
個人建議，先把程序的流程和整體框架搞懂一點，明白一些函數大概是實現什麼功能就可以，現在不要去過多的關注和沉迷在功能模塊的實現細節中，當需要定位到具體的某個功能實現模塊的時候，再切換到函數實現中一點點分析代碼就ok。如果對某個地方不太清楚，可以自己修改下源代碼，運行一下看看運行的結果怎樣。我剛開始的時候不敢改源代碼，怕改錯了項目就不好使了，領導會罵我，先拷貝一份編譯好的源代碼，然後隨意改，反正我還有一份備份的源代碼，我不怕。
個人興趣驅動或者debug驅動方式來看代碼 說實話，單純的看代碼真心沒勁枯燥，而且效率不高。我們可以自我驅動看代碼，比如思考某個功能是如何實現的呢？然後猜測可能是如何實現的，然後再項目代碼中一點點去跟蹤源代碼，慢慢的剝繭抽絲，相信你會有恍然大悟的感覺。還有一種就是公司會用改bug的方式來驅動你熟悉代碼，我剛進公司的時候就是這樣，解決一個bug後，不僅僅對於項目整體流程熟悉了，也對其中的幾個模塊熟悉了，一舉兩得。
UML幫助我們整理思路 使用UML幫助我們整理思維，使用類圖來分析類與類之間的關係，使用UML裏的活動圖，配合IDE工具分析核心業務流程，理解軟件是如何工作的。使用UML來整理程序流程這招，還是在我進入公司以後，帶我的老師教我的，個人感覺非常受益，程序開發人員在初期的時候可能對於畫UML圖有點不適應，慢慢就習慣了。對於整理思路挺有幫助的，希望大家養成個好習慣，嘻嘻。
具體的模塊分析 對需要的具體的代碼進行詳細分析。搞清變量的意義和關聯關係，搞清實現的邏輯和算法。好的代碼，此處是會有註釋的。可以自己F11走到項目代碼中，然後單步調試，看看每個變量是如何變化的，會加深對這個函數中的邏輯和算法的理解。
心理狀態的調整 項目源代碼的代碼量多沒啥，但是我們自己心裏不要着急，慢慢來，自己努力的功夫到了，多花點時間在看代碼思考代碼上，公司的代碼會被你一點點啃透的。如果遇到看不懂代碼的情況，就分析下自己爲什麼看不懂？是項目使用了自己不熟悉的設計模式？還是一些業務領域基礎知識自己沒有掌握（比如我自己做視頻服務器開發，就需要看很多資料去了解視頻格式，視頻壓縮，視頻編碼以及視頻傳輸的一些協議）？或者是自己對項目框架的理解不對導致的，要自己主動的分析
ps：有一本《代碼閱讀方法和實踐》（code reading），會教你怎樣去閱讀源代碼。
