程式庫開發練功房
　　　　　　－以趨勢科技病毒掃瞄引擎為例

文／陳怡芬　趨勢科技科技總監

什麼是程式庫？比較適合的說法是"模組"。以組裝一台電腦、甚至是一台汽車為例，你可以選擇從最小的零件開始做起，然後花上畢生的時間完成它（視每人資質而定），smart點的作法，你可以買一大堆模組（如光碟機、主機板），只需幾天就搞定一台電腦。在程式開發的領域，每個產品都有功能重覆的部份，因而將其獨立成一個程式庫 ( 也就是一個程式模組 ) ，可以減少每個產品開發部門都要重新實作相同的程式碼，可節省大量的時間、人力，品質也可獲得較好的控管。

從開發的過程和方法來看，程式庫開發和產品開發是一樣的。但其仍有不同處。舉個簡單的例子，產品就像房子，大部份顧客買的房子都是蓋好的或設計好的。有些顧客有特殊要求，甚至參與房子的設計。而程式庫就像是蓋房子所需要用到的工具、材料、和模組。重點是你不知道這些工具、材料、和模組如何被蓋房子的人使用、又會拿來蓋什麼樣的房子。一般說來，程式庫需要更嚴苛的品質，開發過程需要更仔細小心，才能進一步地被利用而開發出好的產品，因此，對程式庫設計人員的本質學養也有比較高的要求。

我以趨勢科技的技術核心－病毒掃瞄引擎程式庫（VSAPI）為例子，來談談程式庫設計開發所應該具有的特性。

早期趨勢的病毒掃瞄引擎並沒有一個明顯的架構。它們散在產品程式碼之間，和產品緊緊地糾結在一起。後來開發 Netware 平台上掃毒產品的時候，認識了將掃瞄引擎獨立於產品之外的必要性。於是投注了十八個月的工夫開發了 VSAPI 病毒掃瞄引擎程式庫。趨勢內部陸陸續續又開發了數個程式庫，但不管從架構、複雜度、或重要性等各方面來看 ，VSAPI 仍然是最優越的程式庫。

一、功能性

鋸子就要能鋸東西。所以功能性當然排第一，不能達到原有設計的功能稱不上一個完整的產品。但大多數的程式庫也只能達到這點。論及功能性，VSAPI 比較像瑞士刀，相信沒有其它程式庫包含了像 VSAPI 那麼多超出主要設計需求的功能。為什麼會加入那麼多的功能？這和它的第三個目標有關，本文稍後會提及。

一、前瞻性

設計者當然希望他的鋸子能幫助任何人蓋任何型式的房子，甚至是未來的房子。當初在設計 VSAPI 時的第一目標是將掃瞄引擎獨立於產品碼之外。第二目標，是將大多數掃毒產品需要的功能（不限於掃毒與解毒）也包含在內。當時趨勢只有三個平台產品（DOS，WIN16，NLM）要達到這點是要有一些前瞻性的。第三個目標，是要將其設計成甚至是與病毒無關的產品也能用。這個目標有點天馬行空，也不在本文範圍。希望在篇幅許可之下可以略談一二。六年後回顧 VSAPI 可說達成了兩個半。最重要的是其架構一直能符合需要而未曾修改。大部分程式庫設計員最常犯的錯誤就是只想到眼前這個產品、或這個版本的需求。而經由設計經驗的累積和仔細推敲將可改善這類問題。但若是抱著「今朝有酒今朝醉，明日有愁明日愁」的態度，那注定這程式庫的後續發展不但會累死人，投入的研發成本也會貴的驚人。我常對 VSAPI 小組說，如果你覺得有些需求（或問題），是將來一定會碰到的，那不如先把解答（至少伏筆）準備好，等到事情真的發生時，好好享受別人對你的稱讚（和崇拜）吧！

三、簡易性

相信沒有人願意使用一把需要二十個步驟才能使用的鋸子。即使功能再強，但使用上不夠簡單，在推動時絕對會遭受莫名的挑剔。甚至產品小組會自己寫一個功能類似或重複的模組來抗拒。VSAPI 因為具有太多不可取代性，所以並沒有發生這樣的情形。但也仍然花了將近一年的時間才讓最後一個死硬派在版本大更新時直接採用 VSAPI ，而不是透過一層介面轉換。VSAPI 擁有近三百個程式介面可供使用，但任何一個程式員都可以在一個小時之內，參照程式庫開發小組所附的範例，只用四個程式介面，就可寫一個病毒掃瞄程式來檢查自己的電腦。整合了功能性與簡易性，VSAPI 可說是 Easy for lazy, fancy for crazy。我相信所有的程式庫都應該以這句話為標竿。

四、可攜性

VSAPI 現在支援近二十個平台，可說是只要能用 C 語言開發的環境，VSAPI 就能支援。設計之初，VSAPI 就將不具可攜性的程式碼分離出來，當需要支援新平台時，只要處理那些不具可攜性的部分就可以。以我來說，移植 VSAPI 至任一 UNIX 只需一至二個小時。當初做 AS400 花了我五天，但其中是用四天的時間去熟悉 AS400 和協調其他人員安裝必要軟體。

五、擴充性

設計程式庫最怕的就是隨著產品演進，對程式庫的功能需求愈來愈高，逼著程式庫也要跟著修改。若最初設計時，程式庫的前瞻性難以掌握，又沒有把可能的擴充需求加入考慮，不用多久，就會陷入相容性與擴充需求兩難兼顧的地步。VSAPI 採用了許多使用者可以自行註冊模組來擴充的設計，例如解壓縮模組、解密模組，甚至檔案處理模組。就算不能完全解決問題，也能把急迫性降至最低。半年前 VSAPI 小組被問及需要多久的時間才能支持第二套病毒掃瞄引擎。我的回答是拿到新引擎後一星期內就可以進行整合測試，而且可以不更改產品的使用介面。做法是將新引擎做少許必要修改，然後註冊為 VSAPI 的檔案處理模組。雖然公司最後決定不做新的病毒引擎，但我很高興六、七年前的一個設計能讓公司在做可行性評估時，不必過於考慮相容性、技術困難度，和所需人力時間。

六、層次分明

VSAPI 在這方面做得相當好。我們有許多的介面和模組，其中有外用的，也有內服的。我們做新版次設計時，都會對每一項更動或新增，針對層次性再做討論。也常為了保持層次分明而更改做法。對中型以上的程式庫來說，層次分明非常重要。層次分明對新版次程式庫的推出有縮短所需人力時間的好處，因為比較不會牽一髮而動全身，也比較容易掌握更改的範圍。不只擴充性和它有關，另一個好處是使用彈性也提高。使用彈性不高，將大大限制產品的功能。也會降低產品小組使用程式庫的意願。
程式庫功能過於強大，也會帶來一些意想不到的問題。濫用與誤用是最常見的，但你無法限制產品小組如何使用你的程式庫。更別說是獲得授權使用的其它公司軟體人員。VSAPI 小組時常被一些應用方式弄得啼笑皆非，我們的回應一概遵循原來的設計功能加以道德勸說。但私底下我們是很得意的。因為那代表 VSPI 使用彈性相當高，也證明我們在保持層次分明所下的功夫是絕對正確的與值得的。

七、獨立性

程式庫若依賴太多其它程式庫，不但會降低使用的簡易性，更容易造成顧客服務工作的複雜和困難度。這是因為必須確認那些額外的程式庫存在，且版次相容。有些常用程式庫的功能在不同平台上的表現也有些許差異。我們的做法是將那些功能，有選擇的包含在 VSAPI 內。這樣做不但提高獨立性，可攜性也獲得相當提升。VSAPI 所需功能都不算複雜，這樣做不會帶來太多困擾。若所需功能或依賴的程式庫相當複雜，為提高獨立性，可能要從新檢視設計或更改做法。因功能性的需求，有時很難兼顧獨立性，但應盡力為之。

八、強固性

次級的材料只能蓋出次級的房子。程式庫的一個缺失，表現出來的是每一個產品的缺失。所以把程式庫做到金剛不壞的強固是有必要的。前面提到，你無法限制產品小組如何使用你的程式庫，更無法預測產品或其他程式庫傳來資料的是否正確。所以每一個程式介面都應該嚴格檢查傳入的資料，而且應該愈早檢查愈好。所有參數都通過檢查後，才執行介面功能。另外，程式庫的品質也有著相當高的要求。每一個程式介面都要經過完全的單元測試。這些測試除了最基本的功能測試外，還有錯誤參數檢知能力測試、毀損資料或檔案的檢知和應對、臨界環境測試（確定程式庫在惡劣環境，如系統可用記憶體不足之下的行為）、設計小組對程式 Source Code 做交換檢視等等。都是希望避免因為程式庫的瑕疵進而造成產品的不穩定，甚或是系統因而當機。不像一般產品測試，程式庫測試需要許多測試工具，如測試程式。因此在與品保人員的權責劃分上來說，程式庫設計員要比產品設計員擔負更多的品保工作與責任。

利用程式庫設計產品沒什麼大不了，設計好的程式庫給別人用才厲害。這是我常勉勵 VSAPI 小組工程師的話。和高階程式語言、整合性軟體開發工具一樣，程式庫用多了會漸漸喪失對軟體和系統基本原理的掌握。我就曾碰到一個新進工程師不知道什麼是 Memory Leak。對軟體工程師來說，程式庫設計員是一個非常重要的歷練，也是每一個軟體工程師都應該爭取的。經過了這一歷練，你會發現自己就像從軟體 TopGun 學院出來一樣，充滿技術與自信，軟體的開發游刃有餘，產品在許多方面都將高人一等。