2019年1月24日 星期四

閱讀程式碼的心得

許久以前曾經看過這篇,由傳說中在 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 了。

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

沒有留言:

張貼留言

Related Posts Plugin for WordPress, Blogger...