【51CTO.com快譯】

　　在處理遺留應(yīng)用時(shí)，到底重寫更好還是重構(gòu)更好?對(duì)于二者間的具體取舍，Erik Dietrich作為技術(shù)作家給出了自己的觀點(diǎn)。

[[172992]]

　　重寫 還是 重構(gòu)?

　　“我們已經(jīng)擁有基礎(chǔ)應(yīng)用，但很難決定到底對(duì)其進(jìn)行重寫還是重構(gòu)?”相信很多朋友都面臨著這樣的困擾。

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

　　用對(duì)“術(shù)語”

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

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

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

　　在此為例，重構(gòu)發(fā)生在持續(xù)性且規(guī)模相對(duì)較小的基礎(chǔ)之上。如果大家對(duì)構(gòu)成項(xiàng)目中的某些部分進(jìn)行替換，那么軟件本身也將發(fā)生改變。這意味著大家會(huì)改變其與數(shù)據(jù)庫的交互方式、更換依賴關(guān)系乃至更新代碼框架等等。這實(shí)際上屬于對(duì)應(yīng)用程序的改造。

　　改造?還是 重寫。

　　立足于此，我們可以更進(jìn)一步審視問題。

　　企業(yè)不應(yīng)負(fù)擔(dān)太多技術(shù)債務(wù)，導(dǎo)致開發(fā)者無法有效完成應(yīng)用重寫。如果開發(fā)者由于原本的爛攤子而不得不選擇從零開始，那么企業(yè)本身必須為此承擔(dān)責(zé)任。因此，如今我們說起重寫時(shí)，提到的其實(shí)是正常且應(yīng)當(dāng)定期進(jìn)行的應(yīng)用更新調(diào)整舉措。在這種情況下，開發(fā)團(tuán)隊(duì)?wèi)?yīng)當(dāng)積極學(xué)習(xí)如何清理并推動(dòng)軟件更新。

　　但面對(duì)同樣的背景，有些團(tuán)隊(duì)會(huì)選擇從零開始，而有些則更傾向于進(jìn)行重寫——為什么會(huì)出現(xiàn)這樣的區(qū)別?

　　之所以選擇重寫，可能是因?yàn)檐浖恢边\(yùn)行在早已過時(shí)的硬件之上，或者其依賴于早已落伍的軟件。這意味著該軟件可能在根本上與現(xiàn)有架構(gòu)之間無法交互。

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

　　重構(gòu)還是重寫?商業(yè)案例

　　要準(zhǔn)確判斷這個(gè)問題，大家應(yīng)當(dāng)立足于系統(tǒng)的最終運(yùn)行狀態(tài)預(yù)期，并根據(jù)如何從當(dāng)前狀態(tài)起步逐漸推進(jìn)至最終構(gòu)建結(jié)果勾勒出實(shí)施路線圖。

　　首先，如果這項(xiàng)工作根本無法完成，那么大家應(yīng)當(dāng)考慮重寫。很明顯，把COBOL這類綠屏數(shù)據(jù)庫應(yīng)用轉(zhuǎn)化為iPhone上的“憤怒的小鳥”幾乎是不可能的，因此直接編寫預(yù)期應(yīng)用更為科學(xué)。

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

　　這樣的實(shí)踐思路能夠幫助大家提早進(jìn)行完整性檢查。當(dāng)然，在此之后還會(huì)有中斷時(shí)間、人員狀態(tài)以及許可費(fèi)用等問題給任務(wù)推進(jìn)造成影響。另外，大家還需要通過扇入及耦合等指標(biāo)論證改造的實(shí)施難度。

　　但至少在起步階段，我們已經(jīng)找到了正確的推進(jìn)思路。“重寫還是重構(gòu)”的問題解決之后，接下來余下的將只是規(guī)模調(diào)整之類能夠按部就班處理的任務(wù)。

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】