閱讀程式碼的心理層面

linkedin 上面，朋友會 endorse 我各式技能，像是 Linux、embedded system、 python、open source ... etc。 老實說，這些都不是我真實的技能。 如果要我說明技能為何，我會說「讀程式碼」。 我曾在 resume 裡，將「閱讀程式碼」列為我的重要技能，但被對方笑說這 算什麼技能。 然而，讀別人的程式碼是一種技藝，不是想看就能看的懂。 要看的快，理解的快，可不是那麼容易。

如果要比諭，「閱讀程式碼」這項技能就像「吸星大法」或是「鬥換星移」 這兩門功夫。 看到任何系統，只要有程式碼，就能很快的拆解、修改，納為己用。 因此有「吸星大法」之效。 因為「閱讀」的能力好，在久經各式系統之後，能很快的猜出系統的運作方式， 可以在不全盤瞭解時，就進行修改。 改出問題也能快速的找出問題，並修掉。 因此有「鬥換星移」之效。

##見林不見樹

心法之一，必需能自由的在不同層次的抽象層移動，而不會被細節影嚮。 經驗不足的 developer，通常會程式一行一行的讀，以為這樣才能真的瞭解 程式的運作。 但，有經驗的 developer 會區塊區塊的讀。 他們會大略的掃視一下程式碼，約略猜一下那些區塊是什麼功能， 並簡單的測試一下自己的假設。 這種方式能讓 developer 快速的瞭解系統的大架構，方便之後有需要時， 再深入閱那些區塊的細節。

當 developer 注意細節時，會將心智限縮在小範圍，以致於摸不透大架構。 透過大架構的瞭解，能快速的瞭解各檔案、目錄、模組間的作用。 在有需要時，就能快速的定位出需要精讀的部分。

原開發者也是人，因此他們會用一定的邏輯去組織他們的程式碼。 大區塊的閱讀的目的就是要先摸清原開發者的邏輯為何，以更瞭解 系統的運作。

##符號的提示

有很多人會問，是否有文件? 或註解? 我寧可直接看程式碼，比文件正確。 讀程式碼時，function name 或變數名稱也能發揮很有效的指引。 很多人不注意符號 (symbol) 在寫些什麼，反而一頭鑽入一行行的程式碼。 就像前面說的，原作者也是人，他自己也得讀自己的程式碼，因此會 取一些有意義的符號名稱。 與其讀文件或註解，我會選擇先去解理符號本身想要表達什麼。

##Header Files

以 C/C++ 為例，會有 header file，宣告 function 、 data type、 struct 、 class 等。 要了解一個模組，我會先讀 header file，先看該模組提供什麼樣的介面。 透過 function name、class name 、 class/struct members，能幫你在心裡描繪出 一個大概的輪廓。

##Data structure 經常比指令清楚

和讀指令比較起來，讀 data structure 往往更能掌握系統/模組的結構。 data structure 往往決定了指令輪廓。 如果一頭栽入指令裡，而不先看 data structure，往往會一頭霧水。 先觀察 data structure，往往你大概就能猜出程式碼的外觀。

##註解

註解有時也佷有幫助，但註解也常會誤導你。 因此，我不會把註解放在優先。 反而註解會是最後被注意到的東西。

##筆記

閱讀程式碼時，筆記是必需要。 筆記就像地圖，能幫你確認目前的位置，你是怎麼到達目前的位置，和其它 程式之間的關聯。 筆記能幫你快速切換到系統的不同位置，特別是你需要回到之前看過的位置， 重新做一些確認時。

筆記最好只是紀錄輪廓，大略的樣貌。 細節留給程式碼本身就好了。

##把持自己的慾望

大多數人，會有鑽進細節裡的慾望。 我認為閱讀程式碼需要一種修行，剋制自己的慾望。 閱讀過程必需時時清楚目前的階段目標是什麼，並檢視目前的行為、動作是否 能有效率的帶你往目標前進。 因此，你必需問自己，現在是否該先看看 data structure 長什麼樣? 是否該看 .cpp 的內容，或者先看 header file 就好? 是否該繼續順著 function call 更深入的瞭解? 或者先停在這裡?