【51CTO.com快譯】

　　在處理遺留應用時，到底重寫更好還是重構更好?對于二者間的具體取舍，Erik Dietrich作為技術作家給出了自己的觀點。

[[172992]]

　　重寫 還是 重構?

　　“我們已經擁有基礎應用，但很難決定到底對其進行重寫還是重構?”相信很多朋友都面臨著這樣的困擾。

　　事實上，幾乎每一位CIO、開發主管乃至董事會成員都需要處理這類問題。Erik Dietrich就此收集并整理了大量數據，希望幫助大家在重寫、淘汰、重構乃至重新設計等選項當中找到最適合自己的解決辦法。

　　用對“術語”

　　首先，我們把這個問題進行簡化。一款應用程序已經陳舊、笨重甚至開始出現故障，這時大家該怎么辦?是將其丟棄、注銷還是重新開始?又或者，大家打算以更為簡潔、現代且可行的方式對其進行再次建模?無論如何，這里首先糾正一點——***一種辦法并不屬于“重構”。

　　概括地講，“重構”代碼的基本定義是在不改變代碼外部活動特征的前提下進行結構重塑。舉例來說，選取一種大型方法并從中提取部分代碼添加至另一方法。但如果大家想用“重構”來代表“重寫”，請注意，二者指的并不是同一種處理辦法。

　　假設大家擁有一套陳舊的Web表單應用，其中包含粗糙的代碼且邏輯本身將GUI與數據庫綁定在一起。更糟糕的是，大家可能使用了某些早已信用的支付處理庫，意味著其無法被更新至.NET 2.0以上版本。在這種情況下，“重寫還是重構”問題的實質并非“我是否應當對應用中的某些代碼進行調整或者重寫”，而是“我是否應當對其進行替換或者重寫”。

　　在此為例，重構發生在持續性且規模相對較小的基礎之上。如果大家對構成項目中的某些部分進行替換，那么軟件本身也將發生改變。這意味著大家會改變其與數據庫的交互方式、更換依賴關系乃至更新代碼框架等等。這實際上屬于對應用程序的改造。

　　改造?還是 重寫。

　　立足于此，我們可以更進一步審視問題。

　　企業不應負擔太多技術債務，導致開發者無法有效完成應用重寫。如果開發者由于原本的爛攤子而不得不選擇從零開始，那么企業本身必須為此承擔責任。因此，如今我們說起重寫時，提到的其實是正常且應當定期進行的應用更新調整舉措。在這種情況下，開發團隊應當積極學習如何清理并推動軟件更新。

　　但面對同樣的背景，有些團隊會選擇從零開始，而有些則更傾向于進行重寫——為什么會出現這樣的區別?

　　之所以選擇重寫，可能是因為軟件一直運行在早已過時的硬件之上，或者其依賴于早已落伍的軟件。這意味著該軟件可能在根本上與現有架構之間無法交互。

　　無論實際情況如何，我們都可以將答案簡單歸結為：如果改造成本比從零開始更高，則選擇重寫。因此，價值判斷就成了最為核心的決定因素。

　　重構還是重寫?商業案例

　　要準確判斷這個問題，大家應當立足于系統的最終運行狀態預期，并根據如何從當前狀態起步逐漸推進至最終構建結果勾勒出實施路線圖。

　　首先，如果這項工作根本無法完成，那么大家應當考慮重寫。很明顯，把COBOL這類綠屏數據庫應用轉化為iPhone上的“憤怒的小鳥”幾乎是不可能的，因此直接編寫預期應用更為科學。

　　如果能夠歸納出較為明確的改造途徑，那么請整理出改造相關步驟與需要重寫的組件。另外，盡可能立足于項目規模引入敏捷化概念——具體來講，不要糾結于各項任務需要多少個工時才能完成，而應比較具體規模。如果“構建一套數據訪問層”需要3個時間單位，那么“解耦全部GUI依賴性”同樣需要3個時間單位還是更長一些?總之，不要考慮具體時間，而應著眼于相對復雜程度。

　　這樣的實踐思路能夠幫助大家提早進行完整性檢查。當然，在此之后還會有中斷時間、人員狀態以及許可費用等問題給任務推進造成影響。另外，大家還需要通過扇入及耦合等指標論證改造的實施難度。

　　但至少在起步階段，我們已經找到了正確的推進思路。“重寫還是重構”的問題解決之后，接下來余下的將只是規模調整之類能夠按部就班處理的任務。

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】