trace code

最近看了些 code，發現不同情況下有不同 trace code 的方式，來 murmur 一下。

通常拿到一份 code 會先看它主要 component 的結構。如果有 UI 會先大概了解有哪些 component、分別叫什麼、彼此階層關係是什麼，例如哪個 container 裡放著什麼之類的。如果是網頁會先看資料夾結構是一般自己寫的還是用 framework。之後依照要做的事情不同而有不同的 trace 方式。

第一種，debug 或者找特定功能。

意識到這種 trace code 方式應該是大學在計中打工的時候，那時候想將 Wordpress 跟一個系統做簡單的整合連結，所以要找 Wordpress 裡相對應的功能。工作後 debug 也常常是用這種方式在看 code。

• 如果有 UI 操作，從 UI 操作 trigger 的地方開始一路往下看。
• 簡單的東西可能只需要找到特定 function，改一改或加一加功能就好。
• 稍微複雜一點就得看懂整條路在幹嘛。

這方式是單看程式裡某一條路徑、某一段特定邏輯，除非發現是架構上的 bug 才會再往外擴。要是對那份 code 很熟，是也不用從最開始往下找啦……

第二種，想知道程式整體結構或運作之類的。

想全面但不深入細節的了解結構跟 high level 的邏輯概念。著重架構及概念，會看大致的流程邏輯，但不會細看每個 function 怎麼實作。這是最近演化(?)出來的方式。

• 找最主要的 component 當起點，通常那 project 叫什麼主要 component 就叫什麼，找不到就從 main() 開始。
• 看 class name 猜用途猜猜樂
  • 看名字看不出來的就看 public function 來了解這 class 提供什麼功能
  • function name 還是看不出來，找其他地方如何使用或者快速掃一下實作
  • 有時候會遇到「這個 class 就是這堆功能的集合，我也看不出來這名字跟這堆功能有啥關係」的狀況就是……
• 需要知道某些流程的時候
  • 以類似第一種做法順著流程邏輯看，但只看概略，不細看實作。
  • 偶爾會看點實作，但比較像用大筆刷過去……第一種方式看實作比較像要刻字那樣精雕細琢…….我到底在寫什麼…Orz…
• 了解各 object 的關係，通常看 member。
  • 如果是 pointer 要注意是自己生的還是別人傳進來的。
• 遇到某些關鍵字，例如 XXXFactory、XXXObserver，直接套用已知概念。
  • 只注意誰跟誰有這類的關係，不細看如何實作這些關係。當然也有人家有關鍵字但我不會那概念就沒東西套的狀況……XD
• 遇見某些常見寫法，直接套用那種寫法的概念。
  • 例如 select() 常常就是一個 while loop、塞一塞 fdset、call select()、後面依照 fdset 做事。某些 event loop 做法也有相似性。

我覺得如果遇到關鍵字跟常見做法可以直接套用已知觀念，相對來說就會快很多，因為不需要特別再看實作去理解這部分在做什麼。有時候需要看實作是因為拼湊其他線索後還是不知道那段在幹嘛，只好透過實作細節重新抽象化成概念。

至於如何找 code？find all 與 grep --color -nr * 萬歲！(欸)

PS：寫這個是想知道自己怎麼 trace code 的，但怎麼寫一寫好像還是有點像要心領神會的難以言喻……Orz……