閱讀程式碼的心得

許久以前曾經看過這篇，由傳說中在 appier 大殺四方的 PCMan 大神寫的閱讀程式碼教學：

最近剛好因為小弟的工作上，也會需要在有一點點規模的程式庫裡面穿梭，雖然都在打混還是累積了一點點心得，在這裡分享一下，當然小弟還是遠不如傳說中的 PCMan 啦，大家從我這裡連過去上面的文章，看完就可以關掉回家了（誒
如果你還是想加減看一下，小弟比較熟的是 C/C++ 系的靜態語言，寫網頁什麼的小弟就不擅長了；然後個人的經驗是有極限的，例如 Linux Kernel 那種規模的 code 我就從來沒有弄懂過QQQQ。

1. 開 code 之前，先把專案編譯，跑起來：

編不起來的 code 就是垃圾，要怎麼知道你改的程式有沒有問題？要怎麼看到你的修改有發生實際效果？編不起來這一切都沒用，所以從網路上載了個 project 下來，第一步一定是先看說明文件把專案編起來或跑起來。
通常網路專案要不是 autotool 就是用 Cmake，個人是覺得 autotool 的機率還是高一點點，但通常都是下個 autoconf 再接 configure 就能生出 Makefile 了。

2. 看 code 是最後一步，先從高層次理解程式在做什麼：

這是工作一陣子之後的心得，原始碼最底層是一個很細緻層次的東西，例如模擬一個 x,y 的座標值，然後往上一層一層建構線、面、一群面的組合、一群組合的參考/一群組合的陣列參考等等，上層會用高層次在操作，把下面的實作都隱藏起來。

理解高層次的程式在幹嘛，遠比從低視角去理解實作重要（雖然 low angle 拍出來的照片比較香(炸)），沒理解想法跟目的之前，直接看程式碼是沒有意義的，看到函式做一個 loop，可是為什麼要 loop，在 loop 什麼？沒理解想法，連看著處理中的資料無法分辨對錯的時候，就只是看一堆無意義的資料飛過去而已。

比如說最近跟著強者我同學 JJL 大大在看 verilator 這個 project，這個 project 會把 verilog 吃進來，模擬的 C++ 送出去，verilator 發大財，直接進到 src 資料夾會看到滿滿的 V3xxxx 的檔案，但只要緊抓上面的概念，其實大部分都是 AST 的檔案，verilog 會先被 parse 成 AST，由程式對 AST 進行一些處理變形，再把成果寫出去；所以說至少會有 AST node 跟走訪 AST 的程式，從這點抓下去八九不離十了。
理解高層次的程式比較困難，一般函式至少會有註解，可以註記這個函式的功能，但高層次想法是一個比較難表述的東西，通常也不會訴諸文字，只會記在開發者的腦袋裡面，如果能有一個人帶領的話通常效率會快很多。

3. 調校好工具：

工具上的投資非常值得，好的工具能省下極大的時間，要不要用 IDE 個人沒什麼信仰，一般我都是用 vim，這部分請參考幾篇拙作：用 Vundle 安裝 vim 插件，還有用 ctags 幫助跳轉，Ctags 的程式碼跳轉是一定要的，效率直接天上飛。
終端機也是一個值得好好投資的工具，我一般工作都會開 5 個終端機的分頁，前三個用來編輯 code，第四個用來編譯（因為 C 專案通常程式碼跟編譯的 top 不會是同一個目錄），第五個用來執行程式（對因為通常程式碼、編譯跟執行檔不會是同一個目錄），用 Alt+12345 可以很快速的在分頁間切換，到 Alt+6 我覺得就太遠了。
至於多螢幕，我覺得有幫助但有限，最大的用處是在撰寫投影片跟筆記的時候，可以把 powerpoint 跟 word 拉到另一個螢幕去，跟 code 來回對照會快很多，但單純閱讀程式碼的時候是用不上的。
另外一些 shell 相關的部分，請參考拙作<那些在工作上看到的各種東西>的工具部分：

4. 邊看邊做點筆記：

說真的大型專案有些都會到很噁心的地步，還會有一些積非成是的地方，命名不佳的地方，可能當初寫好、修改，改到後來就沒人敢改了。
最近遇到還有印象的是這樣：我們會依序分解，一條線 x、x 的其中一個端點 S、S 的兩個端點 X1, X2，分別傳進去給函式 A, B, C 做處理，但函式 A 裡面 S 在 x 的 index 跟函式 C 裡面 X1 的 index，變數竟然都用 index，然後在函式 A, B 裡面，都用 i 變數來 pass 給下層的函式，變成裡面的 index。
搞到後來到底 index, i 在哪裡代表什麼都一團糟，這裡就很適合簡單畫個表格記錄一下；要隨手 refactor 一下也是可以，但在大型又缺乏維護的專案下，refactor 有可能會花很多時間，這部分就要自己取捨了。

5. 順手做點修改？

參照上一點，做點變數修改、加些註解，幫助自己理解程式碼是 OK 的；但要記得，一定要沉住氣，不要去改一些枝微末節的東西。
例如有些專案會是悲劇性的空白 tab 混用的狀態，這就不要改了，第一個這個會引發比無限之戰更慘烈的信仰之戰，第二是這種大範圍的修改很浪費時間；第三這種修改很難進入主線，設定一下 tab 的寬度讓程式碼排版回到容易看的狀態就好。
如果有一些區塊很難讀懂，可以用 vim 的 = 在區塊內做重新排版（雖然我覺得這個功能爛掉的機會滿大的）
再來是 syntax sugar，例如自從 C++11 的 range-based loop 出來之後，看到舊式的 iterator based loop 都會覺得癢癢的，是不是該順手改過去？個人認為是不需要。
syntax sugar 的本意就是：更易讀或表達更簡單的文法，本質上無關乎背後的實作，所以你動了手一方面對程式其實沒半點影響，通常 iterator-based 的 loop 也不會影響閱讀跟理解，還不如把精力省下來看懂程式想做什麼。

要知道大型或是正式的 project ，review 機制完善之後所有的修改都會需要審核，沒事沒頭沒尾的送一個修了一堆東西的 Pull Request 被接受的機率都很低，另外 syntax sugar 等級的 refactor 其實根本不影響程式效能，真正架構上、想法上的 refactor 才會，記住程式開發最浪費時間的東西就是程式人的腦袋，不要浪費時間在低層次的修改上面，專注在高層次的程式流程上。
大型的專案通常都橫跨十幾年，會有老舊語法跟 legacy code 是很正常的事情，我現在做的專案裡面還有 K&R C 的 parameter style 勒，就像下面這種：

int foo(bar, qux)
int bar,
stNode qux { … }

反正編譯器還支援的狀況下留著也沒差，我敢打賭這種 code 還會在公司的程式裡留 10 年以上；記得 syntax sugar 只能加在熱咖啡裡，咖啡冷了就不要浪費精力加糖，想辦法換杯新咖啡比較重要。

6. 從 main 下手：

不知道從哪裡開始，我個人的經驗是從 main 下去最快。
main 通常（通常就是有例外啦）會保留最多高層次的程式邏輯跟想法，如果在 main 裡面看到低層次的操作那也是滿抖的。
以 verilator 為例，main 位於 verilator.cpp，整個結構其實很單純：剖析傳進來的參數，讀檔，process，將結果 dump 出來。process 裡面就是對 verilog AST 進行處理的各個 visitor 呼叫，trace 一下就能清楚整個程式的大體流程了。
當然這個規則無法一體適用就是了，具體還是要看各 project 的架構，我也看過最上層是一套虛擬機的專案，實作功能都拆分為給這個虛擬機執行的函式，這時候進入點就變成各函式而不是 main 了。

以上大概就是幾個工作到現在累積的看原始碼心得，小弟班門弄斧，希望各位看倌大大有什麼意見都能多多回饋給小弟。