為什麼工程師總調侃讀程式碼像在通靈

如果你有個軟體工程師朋友，那你多半聽過他調侃過讀程式時就像在通靈。為什麼軟體工程師會這樣調侃自己？軟體工程師是怎麼理解程式的？早在電腦開始普及、軟體工程師開始成為一份工作時，就有人嘗試研究這個問題了。

Brooks (1983) 在他的論文《Towards a theory of the comprehension of computer programs》提出了一個程式理解的認知模型／理論框架試圖解答「人是怎麼理解程式？」。Brooks 將關於程式的知識劃分成不同領域（Domain） ，並將寫程式定義為「建立將問題領域（Problem Domain）透過多個中介領域（Intermediate Domain）映射到程式領域（Programming Domain）之間的關聯過程」，而理解程式就是重建這些領域以及這些領域之間的映射。

文中所提出了多個層次的領域模型，本文為方便說明，將其概括為問題領域、符號領域、行為領域、程式領域與硬體領域。問題領域包含了所有關於問題的知識，問題的定義、該如何解決問題以及問題的輸入、輸出格式。符號領域是把真實世界概念變成可運算的形式表徵（數值、編號、代碼）。行為領域是該如何這些符號解決問題（如程式的演算法、策略）。程式領域則是行為領域在特訂程式語言中的實作。硬體領域則是該程式在硬體上運行時，物件變成記憶體中的值與位址，操作變成硬體指令或其效果。

理解程式被推論為自頂向下、假設驅動與深度優先的過程，工程師聽到對程式的描述後馬上對程式的行為做出假設。這個假設稱為主要假設（Primary Hypothesis），是對程式行為、功能所做的抽象描述，難以直接與程式碼對應。

主要假設形成後，工程師會再次推導，做出更具體、更貼近實作細節的次要假設（Subsidiary Hypothesis），這個過程會一直持續直到假設夠貼近實作細節、能夠直接與程式碼對應。

形成足夠具體次要假設後，就是從程式裡面找證據來證明假設的對錯了。證明假設的過程仰賴指示物（Indicator）與定石（Beacons），定石是由多個指示所組合而來的，多半與某種特定的功能或結構有所關聯。透過定石可以快速的驗證假設，且更近一步的，將定石的內容與假設綁定（Binding）讓假設更具體。這個過程不斷重複，直到完整的知識領域以及映射建立完後，就對程式有著足夠的理解了。

所以為什麼說：「讀程式時就像在通靈」，因為理解程式是不斷提出假設再驗證的過程，理解程式的速度會取決於假設的精準度。意即，先射箭再畫靶，看誰透過線索推敲的比較準，進而才有這樣的調侃。