如何讀專案程式碼
阿新 • • 發佈：2018-12-22
--------------------------------------------------
--------------------------------------------------
先了解軟體業務流程，弄清楚軟體是幹什麼的，怎麼幹？
先得理清楚業務邏輯是怎樣的~
俺一般是照著寫一遍，把東西一個一個的移植到新工程中。
--------------------------------------------------
--------------------------------------------------
看設計和架構文件，儘可能把high level的文件全部看一遍
使用產品使用文件並實際操作
看系統測試，結合測試文件和程式碼
--------------------------------------------------
--------------------------------------------------
有效的途徑是找到系統中模組之間的介面，特別是輸入、輸出、和內部模組之間通訊時使用的資料結構的定義，
觀察輸入資料長什麼樣子，中間經過每一個模組之後大致變成了什麼樣子。
自己把程式跑起來，把各個模組暫時當做黑箱，在模組介面處把傳入和傳出的資料記錄下來。
只要把整個系統裡資料的流動和變化的情況看清楚，你也就摸到邊了。
--------------------------------------------------
--------------------------------------------------
1.看操作說明書
目的：這個專案是幹什麼的？
2.看框架
目的：這個專案是什麼架構？
3.跟程式碼【核心】
目的：每個方法是幹什麼的？先執行那個？在執行那個？
找一個小的模組，這把片程式碼徹底看懂。這個時候你需要的就是跟程式碼了，打斷點；如果是B/S的，你可以再加指令碼除錯debugger。
告訴你一個小竅門：當跟程式碼的時候，旁邊放一張紙，遇到主要的方法，要記下來，從頭到尾記下來，等跟完了自己可以拿這張紙進行復述。這樣這個功能大
概怎麼跑的你就記下了。跟的時候遇到的方法一定要記下來，但是跟的時候一定不要去查，等跟完了在去查。如果是由於自己知識點的原因，應馬上徹底補上來。
小結：這個是核心，一般人只是跟不記，等一下自己就不知道自己會那些，不會那些，大概怎麼跑的都不知道了。所以一定要記。比如我之前開發全部是使用者控制元件
，很抓狂，你根本不知道那個方法先載入，那個頁面需要引數，但是你把它畫出來了，一點點看下來了，感覺很有意思。
------------------------------------------------
------------------------------------------------
1.首先，專案的目的、功能、基本使用有個大概的瞭解
2.閱讀專案的文件，重點關注類似Getting started、Example之類的文件，從中學習如何下載、安裝、甚至基本使用該專案所需要的知識。
3.如果該專案有提供現成的example工程，首先嚐試按照開始文件的介紹執行example，在沒有成功執行example之前，不要嘗試修改example。
4.運行了第一個example之後，嘗試根據你的理解和需要修改example，測試高階功能等。
5. 在瞭解基本使用後，需要開始深入的瞭解該專案。例如專案的配置管理、高階功能以及最佳實踐。通常一個運作良好的專案會提供一份從淺到深的使用者指南，你並不 需要從頭到尾閱讀這份指南，根據時間和興趣，特別是你自己任務的需要，重點閱讀部分章節並做筆記（推薦evernote）。
6.如果時間允許，嘗試從原始碼構建該專案。通常開源專案都會提供一份構建指南，指導你如何搭建一個用於開發、除錯和構建的環境。嘗試構建一個版本。
7.如果時間允許並且有興趣，可以嘗試閱讀原始碼：
（1）閱讀原始碼之前，檢視該專案是否提供架構和設計文件，閱讀這些文件可以瞭解該專案的大體設計和結構，讀原始碼的時候不會無從下手。
（2）閱讀原始碼之前，一定要能構建並執行該專案，有個直觀感受。
（3）閱讀原始碼的第一步是抓主幹，嘗試理清一次正常執行的程式碼呼叫路徑，這可以通過debug來觀察執行時的變數和行為。修改原始碼加入日誌和列印可以幫助你更好的理解原始碼。
（4）適當畫圖來幫助你理解原始碼，在理清主幹後，可以將整個流程畫成一張流程圖或者標準的UML圖，幫助記憶和下一步的閱讀。
（5）挑選感興趣的“枝幹”程式碼來閱讀，比如你對網路通訊感興趣，就閱讀網路層的程式碼，深入到實現細節，如它用了什麼庫，採用了什麼設計模式，為什麼這樣做等。如果可以，debug細節程式碼。
（6）閱讀原始碼的時候，重視單元測試，嘗試去執行單元測試，基本上一個好的單元測試會將該程式碼的功能和邊界描述清楚。
（7）在熟悉原始碼後，發現有可以改進的地方，有精力、有意願可以向該專案的開發者提出改進的意見或者issue，甚至幫他修復和實現，參與該專案的發展。
8.通常在閱讀文件和原始碼之後，你能對該專案有比較深入的瞭解了，但是該專案所在領域，你可能還想搜尋相關的專案和資料，看看有沒有其他的更好的專案或者解決方案。在廣度和深度之間權衡。
以上是我個人的一些習慣，我自己也並沒有完全按照這個來，但是按照這個順序，基本上能讓你比較高效地學習和使用某個開源專案。
-----------------------------------------------------------------------
-----------------------------------------------------------------------
1. 對於常用的系統函式進行追蹤。
比如ReadFile,CreateDevice,CreateWindow,在這些函式處放幾斷點，
可以看到程式碼的呼叫過程。通過這種方式可以方便地把程式碼分為底層程式碼
和上層邏輯程式碼。
2.依據專案依賴關係進行閱讀。
專案的依賴關係同時表明了專案的複雜程度。對於大型的專案通常都會
分割成若干子專案，根據專案的依賴關係，循序漸進的方式可以讓閱讀變的簡單。
3.對於以lib形式提供的子專案。
在閱讀時，可以先把lib的整個專案做為黑盒使用。根據_declspec(dllexport)或者
以標頭檔案方式提供的呼叫介面，可以減少對於細節的閱讀時間。根據模組進行大致的劃分，
可以有效地對專案的結構有直接的感性認識。
4.識別專案中使用的設計模式。
對於大型專案來說，設計模式是必不可少的。在龐大的程式碼中識別設計模式，尋找程式碼
中使用相似手法的程式碼結構可以極大簡化需要閱讀的程式碼。
5.根據資料流程分析。
動態職責劃分。
6.修改部分程式碼，進行除錯。
修改部分常數或者饒過某些程式執行流程，或者以簡化的資料對程式進行追蹤。
----------------------------------------------------------------------
----------------------------------------------------------------------
專案介紹，wiki，原始碼包的readme等。明確專案的目標，應用場景，甚至是用到的技術方案。
根據原始碼包的架構，以及瞭解到的用到的技術方案，大概猜測一下各個模組的功能。
同樣瀏覽所有的原始碼檔案，通過檔名字猜測其功能。推薦使用某些程式碼閱讀工具，如source insight，開始通讀程式碼。
閱讀的順序就比較靈活了，可以按照模組來閱讀，可以先大致瀏覽核心部分再到外圍程式碼，或者反過來從外圍到核心包圍。
經過第四步的通讀，大概就能明確各個模組的功能以及各模組之間如何結合的了，這時在心裡已經對整個程式碼結構有個大致的印象了。
如果做不到，就重做第四步。細讀部分程式碼。
比如你感興趣的部分是如何實現的，或者核心部分的細節。同樣我認為，帶有某種目的的閱讀更有效，比如想借用某部分的實現思路，
想改進某部分，那就針對自己的目標部分進行重點攻破。經過以上幾點，相信整份程式碼已經都理解的七七八八了。
再往下做什麼相信都不會是障礙了！我也好久沒看開原始碼了，多看看開原始碼，學習一下牛人的程式碼風格真的很有好處。
以後我也得多讀一些，好好加強一下編碼能力了，與君共勉吧～
----------------------------------------------------------------------
----------------------------------------------------------------------
有文件的儘量先看文件，特別是設計思想，程式碼結構等
然後粗略的看，理清專案的整體結構和邏輯，細節部分不比深究
整體把握好之後，再選擇對自己有用的細節部分看一看
---------------------------------------------------------------------
---------------------------------------------------------------------
先文件，然後框架結構，然後公共模組，然後慢慢往上，不明白的地方，在回溯。
---------------------------------------------------------------------
---------------------------------------------------------------------
先問再看，有時候問一句頂自己看一天的
--------------------------------------------------
先了解軟體業務流程，弄清楚軟體是幹什麼的，怎麼幹？
先得理清楚業務邏輯是怎樣的~
俺一般是照著寫一遍，把東西一個一個的移植到新工程中。
--------------------------------------------------
--------------------------------------------------
看設計和架構文件，儘可能把high level的文件全部看一遍
使用產品使用文件並實際操作
看系統測試，結合測試文件和程式碼
--------------------------------------------------
--------------------------------------------------
有效的途徑是找到系統中模組之間的介面，特別是輸入、輸出、和內部模組之間通訊時使用的資料結構的定義，
觀察輸入資料長什麼樣子，中間經過每一個模組之後大致變成了什麼樣子。
自己把程式跑起來，把各個模組暫時當做黑箱，在模組介面處把傳入和傳出的資料記錄下來。
只要把整個系統裡資料的流動和變化的情況看清楚，你也就摸到邊了。
--------------------------------------------------
--------------------------------------------------
1.看操作說明書
目的：這個專案是幹什麼的？
2.看框架
目的：這個專案是什麼架構？
3.跟程式碼【核心】
目的：每個方法是幹什麼的？先執行那個？在執行那個？
找一個小的模組，這把片程式碼徹底看懂。這個時候你需要的就是跟程式碼了，打斷點；如果是B/S的，你可以再加指令碼除錯debugger。
告訴你一個小竅門：當跟程式碼的時候，旁邊放一張紙，遇到主要的方法，要記下來，從頭到尾記下來，等跟完了自己可以拿這張紙進行復述。這樣這個功能大
概怎麼跑的你就記下了。跟的時候遇到的方法一定要記下來，但是跟的時候一定不要去查，等跟完了在去查。如果是由於自己知識點的原因，應馬上徹底補上來。
小結：這個是核心，一般人只是跟不記，等一下自己就不知道自己會那些，不會那些，大概怎麼跑的都不知道了。所以一定要記。比如我之前開發全部是使用者控制元件
，很抓狂，你根本不知道那個方法先載入，那個頁面需要引數，但是你把它畫出來了，一點點看下來了，感覺很有意思。
------------------------------------------------
------------------------------------------------
1.首先，專案的目的、功能、基本使用有個大概的瞭解
2.閱讀專案的文件，重點關注類似Getting started、Example之類的文件，從中學習如何下載、安裝、甚至基本使用該專案所需要的知識。
3.如果該專案有提供現成的example工程，首先嚐試按照開始文件的介紹執行example，在沒有成功執行example之前，不要嘗試修改example。
4.運行了第一個example之後，嘗試根據你的理解和需要修改example，測試高階功能等。
5. 在瞭解基本使用後，需要開始深入的瞭解該專案。例如專案的配置管理、高階功能以及最佳實踐。通常一個運作良好的專案會提供一份從淺到深的使用者指南，你並不 需要從頭到尾閱讀這份指南，根據時間和興趣，特別是你自己任務的需要，重點閱讀部分章節並做筆記（推薦evernote）。
6.如果時間允許，嘗試從原始碼構建該專案。通常開源專案都會提供一份構建指南，指導你如何搭建一個用於開發、除錯和構建的環境。嘗試構建一個版本。
7.如果時間允許並且有興趣，可以嘗試閱讀原始碼：
（1）閱讀原始碼之前，檢視該專案是否提供架構和設計文件，閱讀這些文件可以瞭解該專案的大體設計和結構，讀原始碼的時候不會無從下手。
（2）閱讀原始碼之前，一定要能構建並執行該專案，有個直觀感受。
（3）閱讀原始碼的第一步是抓主幹，嘗試理清一次正常執行的程式碼呼叫路徑，這可以通過debug來觀察執行時的變數和行為。修改原始碼加入日誌和列印可以幫助你更好的理解原始碼。
（4）適當畫圖來幫助你理解原始碼，在理清主幹後，可以將整個流程畫成一張流程圖或者標準的UML圖，幫助記憶和下一步的閱讀。
（5）挑選感興趣的“枝幹”程式碼來閱讀，比如你對網路通訊感興趣，就閱讀網路層的程式碼，深入到實現細節，如它用了什麼庫，採用了什麼設計模式，為什麼這樣做等。如果可以，debug細節程式碼。
（6）閱讀原始碼的時候，重視單元測試，嘗試去執行單元測試，基本上一個好的單元測試會將該程式碼的功能和邊界描述清楚。
（7）在熟悉原始碼後，發現有可以改進的地方，有精力、有意願可以向該專案的開發者提出改進的意見或者issue，甚至幫他修復和實現，參與該專案的發展。
8.通常在閱讀文件和原始碼之後，你能對該專案有比較深入的瞭解了，但是該專案所在領域，你可能還想搜尋相關的專案和資料，看看有沒有其他的更好的專案或者解決方案。在廣度和深度之間權衡。
以上是我個人的一些習慣，我自己也並沒有完全按照這個來，但是按照這個順序，基本上能讓你比較高效地學習和使用某個開源專案。
-----------------------------------------------------------------------
-----------------------------------------------------------------------
1. 對於常用的系統函式進行追蹤。
比如ReadFile,CreateDevice,CreateWindow,在這些函式處放幾斷點，
可以看到程式碼的呼叫過程。通過這種方式可以方便地把程式碼分為底層程式碼
和上層邏輯程式碼。
2.依據專案依賴關係進行閱讀。
專案的依賴關係同時表明了專案的複雜程度。對於大型的專案通常都會
分割成若干子專案，根據專案的依賴關係，循序漸進的方式可以讓閱讀變的簡單。
3.對於以lib形式提供的子專案。
在閱讀時，可以先把lib的整個專案做為黑盒使用。根據_declspec(dllexport)或者
以標頭檔案方式提供的呼叫介面，可以減少對於細節的閱讀時間。根據模組進行大致的劃分，
可以有效地對專案的結構有直接的感性認識。
4.識別專案中使用的設計模式。
對於大型專案來說，設計模式是必不可少的。在龐大的程式碼中識別設計模式，尋找程式碼
中使用相似手法的程式碼結構可以極大簡化需要閱讀的程式碼。
5.根據資料流程分析。
動態職責劃分。
6.修改部分程式碼，進行除錯。
修改部分常數或者饒過某些程式執行流程，或者以簡化的資料對程式進行追蹤。
----------------------------------------------------------------------
----------------------------------------------------------------------
專案介紹，wiki，原始碼包的readme等。明確專案的目標，應用場景，甚至是用到的技術方案。
根據原始碼包的架構，以及瞭解到的用到的技術方案，大概猜測一下各個模組的功能。
同樣瀏覽所有的原始碼檔案，通過檔名字猜測其功能。推薦使用某些程式碼閱讀工具，如source insight，開始通讀程式碼。
閱讀的順序就比較靈活了，可以按照模組來閱讀，可以先大致瀏覽核心部分再到外圍程式碼，或者反過來從外圍到核心包圍。
經過第四步的通讀，大概就能明確各個模組的功能以及各模組之間如何結合的了，這時在心裡已經對整個程式碼結構有個大致的印象了。
如果做不到，就重做第四步。細讀部分程式碼。
比如你感興趣的部分是如何實現的，或者核心部分的細節。同樣我認為，帶有某種目的的閱讀更有效，比如想借用某部分的實現思路，
想改進某部分，那就針對自己的目標部分進行重點攻破。經過以上幾點，相信整份程式碼已經都理解的七七八八了。
再往下做什麼相信都不會是障礙了！我也好久沒看開原始碼了，多看看開原始碼，學習一下牛人的程式碼風格真的很有好處。
以後我也得多讀一些，好好加強一下編碼能力了，與君共勉吧～
----------------------------------------------------------------------
----------------------------------------------------------------------
有文件的儘量先看文件，特別是設計思想，程式碼結構等
然後粗略的看，理清專案的整體結構和邏輯，細節部分不比深究
整體把握好之後，再選擇對自己有用的細節部分看一看
---------------------------------------------------------------------
---------------------------------------------------------------------
先文件，然後框架結構，然後公共模組，然後慢慢往上，不明白的地方，在回溯。
---------------------------------------------------------------------
---------------------------------------------------------------------
先問再看，有時候問一句頂自己看一天的