軟體考古學

考古學研究的對象是實物，主要是物質的遺存（也就是遺物與遺跡），而這些遺存是古代人類活動所遺留下來的。一件古文物的出土，考古學家就會用盡各種方式，試圖還原此文物的一切資訊（年代、文化、製工……）。

幾年前，軟體界也出現了軟體考古學（Software Archeology）一詞。不過，軟體考古學家不需要在黃土堆中一插一剷，不需要遍讀古籍一卷一冊，因為軟體考古學研究的對象是「源碼」。

有哪些狀況需要進行軟體考古？看看幾個經典的例子：

● 1990年代末期，大量COBOL系統需要被修改，以解決Y2K問題。

● 既有的系統雖然好用，但是不符合Web時代的需求，需要把它改成Web版本。

● 近幾年，許多老舊的Visual Basic程式需要更新到Java或.NET平臺上。

● Web技術演進快速，許多系統縫縫補補，結合了微軟DNA、J2EE、.NET、PHP等架構，使得系統難以維護，甚至互相抵觸，必須盡快重新整理。

物件導向大師Grady Booch是軟體考古學的重要人物之一，他所做的軟體考古專案，比較偏向於「整理既有的系統，以將文件補充齊全」。Booch將軟體考古分成5個步驟：（1）研讀源碼；（2）逆向工程；（3）探索；（4）檢視既有文件；（5）訪談領導人。

Booch的作法對許多人來說可能不實用，因為許多應用軟體是多年前開發的，當初可能沒有文件，或者相關文件已經遺失；就算有文件也可能不完備或不正確。更不用提當初開發系統的公司或人員可能已經失聯或不存在，根本無法訪談。

IT人員常常會被老闆指派處理老舊系統，而且還是他們之前從未接觸過的系統，這是每個IT人員的夢魘。遇到這種狀況，IT人員通常會建議「不如重新開發一套系統」，但是往往被老闆打回票，一般來說，重新開發需要更高昂的成本、曠日廢時，而且舊系統內仍有許多穩固、重要、可取的地方，是新系統無法取代的。因此，和既有的陌生程式碼奮戰，也就成了許多IT人的宿命。這個時候，就需要運用到軟體考古學。

軟體考古學是「從既有軟體中學習」的一種學問。讓軟體團隊了解某軟體的程式碼，除此之外，也可以幫助解構既有的軟體，以找出設計與開發的模式。軟體考古的目的通常是新增功能、修正錯誤、重構源碼、轉移平臺或擷取精華。

軟體考古是一種反覆（Iterative）與互動（Interactive）的過程，大致分成四個步驟：

一、剖析：使用各種工具軟體進行源碼剖析。

二、豐富化（Enrichment）：建立工作資料模型（Working Data Model），並描述和其他應用的介面，讓舊程式碼能連結到顧客的新環境。

三、移植：將舊系統移植到新平臺與新資料庫。

四、測試：確保系統無誤。

由於軟體考古需要成熟的技能和經驗，所以從事軟體考古的IT人平均年齡比一般開發者高出許多。例如，為了解決2000年的Y2K問題，原本已經不受重視的COBOL程式員，忽然變得炙手可熱（但是過了Y2K，COBOL程式員又再度坐冷板凳），這些熟悉COBOL且有豐富經驗的人，年紀恐怕都超過40歲了。

隨著軟體技術不斷地推陳出新，開發工程師也隨之改朝換代，許多系統內也持續混入各種不同的架構和技術（好聽的說法是Mash-Up）。現在一套系統同時混用JavaScript、Java、PHP、C#、C++是很常見的。所以，一項軟體考古任務，便可能牽涉到相當多的技術，需要各種技術人才的參與研究。

透過工具軟體的協助，可以讓考古更容易。例如，輸入程式碼，產生各種UML圖或產生函式呼叫鏈；利用程式碼自動轉換工具（例如ArtinSoft），將舊的程式碼轉成新的程式碼。有的IDE（Integrated Development Environment，整合開發環境）甚至能整合各種軟體考古工具，例如CodeGear就宣稱JBuilder 2007支援軟體考古的功能。

某個角度來看，軟體考古類似程式碼重構（Code Refactoring），只不過程式碼的重構對象著重在局部、片面的程式碼，而軟體考古卻是從整體到細部程式碼的全盤處理。

軟體考古學也和逆向工程（Reverse Engineering）相似。但逆向工程比較偏向「在沒有源碼的狀況下，進行反向推敲」；軟體考古則是一開始就有源碼，而且可能有文件。一般來說，軟體考古的難度比逆向工程低。

軟體考古是軟體工程的一門新興學問，目前的論述不多，似乎連流派都尚未形成。如果你需要進行軟體考古，不妨參考逆向工程的做法，也許可以讓你有所啟發。

作者簡介：
蔡學鏞－技術顧問
清華大學資訊工程碩士，曾任華碩集團軟體工程師、元智大學資訊系講師、美商歐萊禮出版社技術編輯、臺灣微軟特約專欄作家。