第八章 維護與再生工程
程式設計大師曾說：「哪怕程式只有三行長，總有一天你也不得不對它維護。」
很多軟體產品不是一次性的買賣。比如在電信、金融等領域，有些軟體系統要用十幾
年，對軟體進行維護是必不可少的。8.1節將介紹「軟體維護的常識」，對維護活動進行分類，
並解釋為什麼維護比較困難。
軟體公司的經理們沒有哪乙個喜歡被維護的費用嚇一跳，但軟體維護的代價通常是高昂
的。7.2節將說明影響維護代價的一些主要技術因素與非技術因素。
如果希望提高已有軟體的質量並且提高商業競爭力，卻又無法靠維護來實現，只好對已
有軟體進行全部或者部分的改造，這種活動叫再生工程（reengineering）。7.3節將解釋什麼
是再生工程，並論述再生工程的三種型別：重構（restructure）、逆向工程（reverse engineering）
和前向工程（forward engineering）。
8.1
軟體維護的常識
對軟體而言，「維護」是個不太直觀的術語，因為軟體產品在重複使用時不會被磨損，
並不需要進行像對車輛或電器那樣的維護。軟體維護是人們對既豐富多彩又會令人心酸的活
動的統稱。其中豐富多彩的活動是指那些反映客觀世界變化、能使軟體系統更加完善的修改
和擴充工作。令人心酸的活動是指那些永無修止、並且改了舊錯卻引起新錯讓人欲哭無淚的
工作。
一些學者將軟體維護劃分為主要的三類：糾錯性維護（corrective maintenance）、適應性
維護（adaptive maintenance）和完善性維護（perfective maintenance）：
（1）糾錯性維護。由於前期的測試不可能揭露軟體系統中所有替在的錯誤，使用者在使
用軟體時仍將會遇到錯誤，診斷和改正這些錯誤的過程稱為糾錯性維護。
（2）適應性維護。由於新的硬體裝置不斷推出，作業系統和編譯系統也不斷地公升級，
為了使軟體能適應新的環境而引起的程式修改和擴充活動稱為適應性維護。
（3）完善性維護。在軟體的正常使用過程中，使用者還會不斷提出新的需求。為了滿足
使用者新的需求而增加軟體功能的活動稱為完善性維護。
lientz
和swanson調查發現（2023年），完善性維護約佔65%，適應性維護約佔18%，
糾錯性維護約佔17%[sommerville 1992]。上述調查已是20年前的事了，我們不必太關心具體
的比例，心裡有數即可。
以下一些因素將導致維護工作變得困難：
（1）軟體人員經常流動，當需要對某些程式進行維護時，可能已找不到原來的開發人
員。只好讓新手去「攻讀」那些程式。
（2）人們一般難以讀懂他人的程式。在勉強接受這類任務時，心裡不免嘀咕：「我又不
是他肚子裡的蟲子，怎麼知道他如何程式設計。」
（3）當沒有文件或者文件很差時，你簡直不知道如何下手。
（4）很多程式在設計時沒有考慮到將來要改動，程式之間相互交織，觸一而牽百。即
使有很好的文件，你也不敢輕舉妄動，否則你有可能陷進錯誤堆裡。
（5）如果軟體發行了多個版本，要追蹤軟體的演化非常困難。
（6）維護將會產生不良的***，不論是修改**、資料或文件，都有可能產生新的
錯誤。
（7）維護工作毫無吸引力。高水平的程式設計師自然不願主動去做，而公司也捨不得讓高
水平的程式設計師去做。帶著低沉情緒的低水平的程式設計師只會把維護工作搞得一塌糊塗。
8.2
維護的代價及其主要因素
軟體維護是既破財又費神的工作。看得見的代價是那些為了維護而投入的人力與財力。
而看不見的維護代價則更加高昂，我們稱之為「機會成本」，即為了得到某種東西所必須放
棄的東西[mankiw 1999]。把很多程式設計師和其它資源用於維護工作，必然會耽誤新產品的開發
甚至會喪失機遇，這種代價是無法估量的。
影響維護代價的非技術因素主要有：
（1）應用域的複雜性。如果應用域問題已被很好地理解，需求分析工作比較完善，那
麼維護代價就較低。反之維護代價就較高。
（2）開發人員的穩定性。如果某些程式的開發者還在，讓他們對自己的程式進行維護，
那麼代價就較低。如果原來的開發者已經不在，只好讓新手來維護陌生的程式，那麼代價就
較高。
（3）軟體的生命期。越是早期的程式越難維護，你很難想像十年前的程式是多麼的落
後（設計思想與開發工具都落後）。一般地，軟體的生命期越長，維護代價就越高。生命期
越短，維護代價就越低。
（4）商業操作模式變化對軟體的影響。比如財務軟體，對財務制度的變化很敏感。財
務制度一變動，財務軟體就必須修改。一般地，商業操作模式變化越頻繁，相應軟體的維護
代價就越高。
影響維護代價的技術因素主要有：
（1）軟體對執行環境的依賴性。由於硬體以及作業系統更新很快，使得對執行環境依
賴性很強的應用軟體也要不停地更新，維護代價就高。
（2）程式語言。雖然低階語言比高階語言具有更好的執行速度，但是低階語言比高階
語言難以理解。用高階語言編寫的程式比用低階語言編寫的程式的維護代價要低得多（並且
生產率高得多）。一般地，商業應用軟體大多採用高階語言。比如，開發一套windows環境
下的資訊管理系統，使用者大多採用visual basic、delphi或power builder來程式設計，用visual c++
的就少些，沒有人會採用組合語言。
（3）程式設計風格。良好的程式設計風格意味著良好的可理解性，可以降低維護的代價。
（4）測試與改錯工作。如果測試與改錯工作做得好，後期的維護代價就能降低。反之
維護代價就公升高。
（5）文件的質量。清晰、正確和完備的文件能降低維護的代價。低質量的文件將增加
維護的代價（錯誤百出的文件還不如沒有文件）。
8.3
再生工程
再生工程主要出於如下願望：（1）在商業上要提高產品的競爭力；（2）在技術上要提高
產品的質量。但這種願望無法靠軟體的維護來實現，因為：（1）軟體的可維護性可能極差，
實在不值得去做；（2）即使軟體的可維護性比較好，但也只是治表不治本。再生工程乾脆對
已有軟體進行全部或部分的改造，賦予軟體新的活力。
在對待乙個不良之徒時，可以進行思想教育並給予他關心和幫助，這種方式類似於
「軟體維護」；也可以把他關進監獄，送去**，這種方式相當於軟體的「再生工程」；如果
此人壞透頂了，就斃掉算了。
再生工程與維護的共同之處是沒有拋棄原有的軟體。如果把維護比作「修修補補」，那
麼再生工程就算是「痛改前非」。再生工程並不見得一定比維護的代價要高，但再生工程在
將來獲取的利益卻要比通過維護得到的多。
再生工程主要有三種型別：重構、逆向工程和前向工程。
8.3.1
重構 重構一般是指通過修改**或資料以使軟體符合新的要求。重構通常並不推翻原有軟體
的體系結構，主要是改造一些模組和資料結構。重構的一些好處如下：
（1）使軟體的質量更高，或使軟體順應新的潮流（標準）。
（2）使軟體的後續（公升級）版本的生產率更高。
（3）降低後期的維護代價。
要注意的是，在**重構和資料重構之後，一定要重構相應的文件。
8.3.2
逆向工程
逆向工程**於硬體世界。硬體廠商總想弄到競爭對手產品的設計和製造「奧秘」。但
是又得不到現成的檔案，只好拆卸對手的產品並進行分析，企圖從中獲取有價值的東西。我
的很多同學從事積體電路設計工作，他們經常解剖國外的積體電路，甚至不作分析就原封不
動地複製該電路的版圖，然後投入生產，並美其名曰「反向設計」（reverse design）。
軟體的逆向工程在道理上與硬體的相似。但在很多時候，軟體的逆向工程並不是針對競
爭對手的，而是針對自己公司多年前的產品。期望從老產品中提取系統設計、需求說明等有
價值的資訊。
8.3.3
前向工程
前向工程也稱預防性維護，由miller倡導。他把這個術語解釋成「為了明天的需要，把
今天的方法應用到昨天的系統上」。[pressman 1999]
乍看起來，主動去改造乙個目前執行得正常的軟體系統簡直就是「惹事生非」。但是軟
件技術發展如此迅速，與其等待乙個有價值的產品逐漸老死，還不如主動去更新，以獲取更
大的收益。其道理就同打預防性針一樣。所以，預防性維護是「吃小虧佔大便宜」的事。
8.4
小 結
大學科研機構裡的軟體維護工作恐怕是做得最差的了。幾乎每一批新的研究生都會把畢
業生留下的軟體臭罵一通，然後全部推到重做。到他畢業該走時，就輪到別人罵他的工作了。
如此輪迴，最終沒有什麼成果留下。
如果希望軟體系統能活下，必須要對它進行維護。如果希望軟體系統有效益，則必須設
法降低維護的代價。
軟體工程 第八章 軟體維護
軟體維護 軟體修改報告 1 滿足維護需求表中提出的要求所需要的工作量 2 維護要求的性質 3 這項要求的優先次序 4 與修改有關的事後資料 軟體維護工作 1 修改軟體設計 2 複查 3 必要的 修改 4 單元測試 5 整合測試 6 驗收測試 7 複審 複查提出問題 在當前處境下設計 編碼 測試的哪些...
工程導論第八章
第八章主要講述了工程師的表達與溝通能力和撰寫 的要求與方法。工程師要有良好的書面表達能力與交流溝通能力，還要學會如何撰寫 和各種實驗及實驗報告。口語表達及書面表達能力是工程師必須具備的最基本的職業能力，人們需要在學習和工作階段反覆練習不斷提公升，要想提公升口語表達能力，需要多參加學術研討交流會議，要...
第八章 指標 第八章 指標
1 什麼是位址 include using namespace std int main 11 在堆中建立對像 我們既然可以在堆中儲存變數，那麼也就可以儲存對像，我們可以將對像儲存堆中，然後通過指標來訪問它 include using namespace std class human 14 在建構...