看到ITFriend中有些小夥伴剛進入公司，面對大量的項目代碼，往往手足無措，有點慌，我說下我的經歷。

聲明：我從事的是C++開發工作。閱讀的代碼都是基於client/server的，下面談的是C++項目代碼的閱讀方法多些

希望懂java的小夥伴分享下java公司項目代碼的閱讀方法。小弟感激不盡。

編譯代碼把項目跑起來 代碼到手以後。先嘗試著編譯一下，無非就是庫的配置。庫路徑的配置，缺少某個文件，或者頭文件包括路徑不對，一般公司給你的代碼都能夠編譯成功，windows平臺下一般使用vs工具來編譯。集成調試工具。而Linux下編譯.使用gcc（g++）編譯器 make工具或者automake工具，詳細使用方法在搜索引擎上能找到。編譯成功以後把項目跑起來。我喜歡看看client長啥樣，哈哈，恭喜你，邁出了第一步

看項目文檔，和項目開發者（維護人員）進行溝通 公司的項目代碼會有相關的設計文檔，比方XX項目概要設計文檔、XX項目具體設計文檔、XX項目模塊設計以及之間依賴關系的文檔等等，通過這些文檔，軟件開發者起碼對項目有個總體的認識，比方項目本身是解決什麽領域問題的？有哪些功能模塊以及他們的大體功能是什麽？使用了什麽開源庫？通過文檔還能夠了解到代碼中的一些數據結構的具體凝視，網絡傳輸是怎樣設計的，使用了哪些協議？數據庫中的字段是怎樣設計的。以及數據庫中各個表之間的關系。在看代碼的過程中，遇到模糊不清或者自己拿不住的代碼，要及時和同事溝通，他們對代碼的熟悉程度比我們強。虛心有禮貌的問人家。否則自己在那憋著瞎猜代碼的含義，費時費力還得不償失，開口求人幫忙就那麽難？嘻嘻，你幫我下，我幫你下。咱倆慢慢就熟悉了嘛

搞清楚程序的流程和大體框架。詳細功能模塊詳細分析 從main函數開始，把client和server怎麽工作的流程大致的看一下，client怎樣連接server段的？serverclient是怎樣進行數據交互的？在關鍵的地方下斷點。看看client發送來的內容是什麽。server在接收到client發送來的消息後是怎樣處理的。

個人建議。先把程序的流程和總體框架搞懂一點。明確一些函數大概是實現什麽功能就能夠，如今不要去過多的關註和沈迷在功能模塊的實現細節中，當須要定位到詳細的某個功能實現模塊的時候，再切換到函數實現中一點點分析代碼就ok。假設對某個地方不太清楚，能夠自己改動下源碼，執行一下看看執行的結果如何。

我剛開始的時候不敢改源碼，怕改錯了項目就不好使了。領導會罵我，先拷貝一份編譯好的源碼，然後任意改。反正我另一份備份的源碼，我不怕。

個人興趣驅動或者debug驅動方式來看代碼 說實話，單純的看代碼真心沒勁枯燥，並且效率不高。

我們能夠自我驅動看代碼，比方思考某個功能是怎樣實現的呢？然後推測可能是怎樣實現的。然後再項目代碼中一點點去跟蹤源碼，慢慢的剝繭抽絲，相信你會有恍然大悟的感覺。

另一種就是公司會用改bug的方式來驅動你熟悉代碼，我剛進公司的時候就是這樣，解決一個bug後。不只對於項目總體流程熟悉了，也對當中的幾個模塊熟悉了。一舉兩得。

UML幫助我們整理思路 使用UML幫助我們整理思維，使用類圖來分析類與類之間的關系，使用UML裏的活動圖。配合IDE工具分析核心業務流程，理解軟件是怎樣工作的。使用UML來整理程序流程這招。還是在我進入公司以後。帶我的老師教我的，個人感覺很受益。程序開發者在初期的時候可能對於畫UML圖有點不適應。慢慢就習慣了。對於整理思路挺有幫助的。希望大家養成個好習慣，嘻嘻。
詳細的模塊分析 對須要的詳細的代碼進行詳細分析。搞清變量的意義和關聯關系，搞清實現的邏輯和算法。好的代碼。此處是會有凝視的。

能夠自己F11走到項目代碼中。然後單步調試。看看每一個變量是怎樣變化的。會加深對這個函數中的邏輯和算法的理解。

心理狀態的調整 項目源碼的代碼量多沒啥。可是我們自己心裏不要著急，慢慢來。自己努力的功夫到了，多花點時間在看代碼思考代碼上，公司的代碼會被你一點點啃透的。

假設遇到看不懂代碼的情況，就分析下自己為什麽看不懂？是項目使用了自己不熟悉的設計模式？還是一些業務領域基礎知識自己沒有掌握（比方我自己做視頻server開發，就須要看非常多資料去了解視頻格式，視頻壓縮，視頻編碼以及視頻傳輸的一些協議）？或者是自己對項目框架的理解不正確導致的，要自動的分析

ps：有一本《代碼閱讀方法和實踐》（code reading），會教你如何去閱讀源碼。

怎樣閱讀公司的項目代碼