閱讀他人的程式碼 (4)望文生義，進而推敲組件的作用

 

閱讀他人的程式碼 (4)望文生義，進而推敲組件的作用

文/iThome (記者) 2008-03-26

<!-- NO MAIN PHOTO --> 先建立系統的架構性認識，然後透過名稱及命名慣例，就可以推測出各組件的作用。例如：當Winamp嘗試著初始化一個Plug-In時，它會呼叫這個結構 中的init函式，以便讓每個Plug-In程式有機會初始化自己。當Winamp打算結束自己或結束某個Plug-In的執行時，便會呼叫quit函 式。

在閱讀程式碼的細節之前，我們應先試著捕捉系統的運作情境。在採取由上至下的方式時，系統性的架構是最頂端的層次，而系統的運作情境，則是在它之下的另一個層次。

好的說明文件難求，拼湊故事的能力很重要
有些系統提供良善的說明文件，也許還利用UML充分描述系統的運作情境。那麼對於閱讀者來說，從系統的分析及設計文件著手，便是快速了解系統運作情境的一個途徑。

但是，並不是每個軟體專案都伴隨著良好的系統文件，而許多極具價值的開放原始碼專案，也時常不具備此類的文件。對此，閱讀者必須嘗試自行捕捉，並適度地記錄捕捉到的運作情境。

我喜歡將系統的運作情境，比擬成系統會上演的故事情節。在閱讀細節性質的程式碼前，先知道系統究竟會發生那些故事，是必備的基本功課。你可以利用 熟悉或者自己發明的表示工具，描述你所找到的情境。甚至可以只利用簡單的列表，直接將它們列出。只要能夠達到記錄的目的，對程式碼閱讀來說，都能夠提供幫 助。或者，你也可以利用UML中的類別圖、合作圖、循序圖之類的表示方法，做出更詳細的描述。

當你能夠列出系統可能會有的情境，表示你對系統所具備的功能，以及在各種情況下的反應，都具備概括性的認識。以此為基礎，便可在任何需要的時候，鑽進細節處深入了解。

探索架構的第一步──找到程式的入口
在之前，我們在一個開發專案中，曾經需要將系統所得到的MP3音訊檔，放至iPod這個極受歡迎的播放設備中。

雖然iPod本身也可以做為可移動式的儲存設備，但並不是單純地將MP3檔案放到iPod中，就可以讓iPod的播放器認得這個檔案，甚至能夠加以播放。

這是因為iPod利用一個特殊的檔案結構（iTunes DB），記錄播放器中可供播放的樂曲、播放清單以及樂曲資訊（例如專輯名稱、樂曲長度、演唱者等）。為了了解並且試著重複使用既有的程式碼，我們找到了一個Winamp的iPod外掛程式（Plug-In）。

Winamp是個人電腦上極受歡迎的播放軟體，而我們找到的外掛程式，能讓Winamp直接顯示連接至電腦的iPod中的歌曲資訊，並且允許Winamp直接播放。

我們追蹤與閱讀這個外掛程式的思路及步驟如下，首先，我們要先了解外掛程式的系統架構。很明顯的，大概瀏覽過原始碼後，我們注意到它依循著 WinAmp為Plug-In程式所制定的規範，也就是說，它是實作成Windows上的DLL，並且透過一個叫做 winampGetMediaLibraryPlugin的DLL函式，提供一個名為winampMediaLibraryPlugin的結構。

當我們不清楚系統的架構究竟為何時，我們會試著探索，而第一步，便是找到程式的入口。如何找到呢？這會依程式的性質不同而有所差別。

對一個本身就是可獨立執行的程式來說，我們會找啟動程式的主要函式，例如對C/C++來說就是main()，而對Java來說，便是static void main()。在找到入口後，再逐一追蹤，摸索出系統的架構。
但有時，我們所欲閱讀的程式碼是類別庫或函式庫，它只是用來提供多個類別或函式供用戶端程式（Client Program）使用，本身並不具單一入口，此類的程式碼具有多重的入口──每個允許用戶端程式呼叫的函式或類別，都是它可能的入口。

例如，對WinAmp的iPod Plug-In來說，它是一個DLL形式的函式庫，所以當我們想了解它的架構時，必須要先找出它對外提供的函式，而對Windows DLL來說，對外提供的函式，皆會以dllexport這個關鍵字來修飾。所以，不論是利用grep或gtags之類的工具，我們可以很快從原始碼中，找 到它只有一個DLL函式（這對我們而言，真是一個好消息），而這個函式便是上述的winampGetMediaLibraryPlugin。

系統多會採用相同的架構處理Plug-In程式
如果經驗不夠的話，也許無法直接猜出這個函式的作用。

不過，如果你是個有經驗的程式人，多半能從函式所回傳的結構，猜出這個函式實際的用途。而事實上，當你已經知道它是一個Plug-In程式時，就應該要明白，它可能採用的，就是許多系統都採用的相同架構處理Plug-In程式。

當一個系統採用所謂Plug-In形式的架構時，它通常不會知道它的Plug-In究竟會怎麼實作、實作什麼功能。它只會規範Plug-In程式需要滿足某個特定介面。當系統初始化時，所有的Plug-In都可以依循相同的方式，向系統註冊，合法宣示自己的存在。

雖然系統並不確切知道Plug-In會有什麼行為展現，但是因為它制定了一個標準的介面，所以系統仍然可以預期每個Plug-In能夠處理的動作類型。這些動作具體上怎麼執行，對系統來說並不重要。這也正是物件導向程式設計中的「多型」觀念。

隨著實務經驗，歸納常見的架構模式
我想表達的重點，是當你「涉世越深」之後，所接觸的架構越多，就越能觸類旁通。只需要瞧上幾眼，就能明白系統所用的架構，自然就能夠直接聯想到其中可能存在的角色，以及角色間的關係。

像上述的Plug-In程式手法，時常可以在許多允許「外掛」程式碼的系統中看到。所以，有經驗的閱讀者，多半能夠立即反應，知道像Winamp這樣的系統，應該是讓每個Plug-In程式，都寫成DLL函式庫。

而每個Plug-In的DLL函式庫中，都必須提供 winampGetMediaLibraryPlugin()這個 函式（如果你熟悉Windows的程式設計，你會知道這是利用LoadLibrary()和GetProcAddress()來達成的一種多型手法）。如 果你熟悉設計模式，你更會知道這是Simple Factory Method這個設計模式的運用。

winampGetMediaLibraryPlugin()所回傳的winampMediaLibraryPlugin結構，正好就描述了每個Winamp Plug-In的實作內容。

善用名稱可加速了解
利用gtags這個工具，我們立即發現，這個Plug-In它所定義的init、quit、PluginMessageProc這三個名稱，都是函式名稱。這暗示在多型的作用下，它們都是在某些時間點，會由Winamp核心本體呼叫的函式。

名稱及命名慣例是很重要的。看到「init」，我們會知道它的作用多半是進行初始化的動作，而「quit」大概就是結束時處理函式，而 PluginMessageProc多半就是各種訊息的處理常式（Proc通常是procedure的簡寫，所以PluginMessageProc意指 Plugin Message Procedure）了。

「望文生義」很重要，我們看到函式的名稱，就可以猜想到它所代表的作用，例如：當Winamp嘗試著初始化一個Plug-In時，它會呼叫這個結 構中的init函式，以便讓每個Plug-In程式有機會初始化自己；當Winamp打算結束自己或結束某個Plug-In的執行時，便會呼叫quit函 式。當Winamp要和Plug-In程式溝通時，它會發送各種不同的訊息至Plug-In，而Plug-In程式必須對此做出回應。

我們甚至不需要檢視這幾個函式的內容，就可以做出推測，而這樣的假設，事實上也是正確的。