建站
咨詢
售后
建站咨詢
新聞中心
在處理遺留應(yīng)用時(shí)，到底重寫更好還是重構(gòu)更好?對(duì)于二者間的具體取舍，Erik Dietrich作為技術(shù)作家給出了自己的觀點(diǎn)。
重寫 還是 重構(gòu)?
“我們已經(jīng)擁有基礎(chǔ)應(yīng)用，但很難決定到底對(duì)其進(jìn)行重寫還是重構(gòu)?”相信很多朋友都面臨著這樣的困擾。
事實(shí)上，幾乎每一位CIO、開(kāi)發(fā)主管乃至董事會(huì)成員都需要處理這類問(wèn)題。Erik Dietrich就此收集并整理了大量數(shù)據(jù)，希望幫助大家在重寫、淘汰、重構(gòu)乃至重新設(shè)計(jì)等選項(xiàng)當(dāng)中找到最適合自己的解決辦法。
用對(duì)“術(shù)語(yǔ)”
首先，我們把這個(gè)問(wèn)題進(jìn)行簡(jiǎn)化。一款應(yīng)用程序已經(jīng)陳舊、笨重甚至開(kāi)始出現(xiàn)故障，這時(shí)大家該怎么辦?是將其丟棄、注銷還是重新開(kāi)始?又或者，大家打算以更為簡(jiǎn)潔、現(xiàn)代且可行的方式對(duì)其進(jìn)行再次建模?無(wú)論如何，這里首先糾正一點(diǎn)——***一種辦法并不屬于“重構(gòu)”。
概括地講，“重構(gòu)”代碼的基本定義是在不改變代碼外部活動(dòng)特征的前提下進(jìn)行結(jié)構(gòu)重塑。舉例來(lái)說(shuō)，選取一種大型方法并從中提取部分代碼添加至另一方法。但如果大家想用“重構(gòu)”來(lái)代表“重寫”，請(qǐng)注意，二者指的并不是同一種處理辦法。
假設(shè)大家擁有一套陳舊的Web表單應(yīng)用，其中包含粗糙的代碼且邏輯本身將GUI與數(shù)據(jù)庫(kù)綁定在一起。更糟糕的是，大家可能使用了某些早已信用的支付處理庫(kù)，意味著其無(wú)法被更新至.NET 2.0以上版本。在這種情況下，“重寫還是重構(gòu)”問(wèn)題的實(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ù)庫(kù)的交互方式、更換依賴關(guān)系乃至更新代碼框架等等。這實(shí)際上屬于對(duì)應(yīng)用程序的改造。
改造?還是 重寫。
立足于此，我們可以更進(jìn)一步審視問(wèn)題。
企業(yè)不應(yīng)負(fù)擔(dān)太多技術(shù)債務(wù)，導(dǎo)致開(kāi)發(fā)者無(wú)法有效完成應(yīng)用重寫。如果開(kāi)發(fā)者由于原本的爛攤子而不得不選擇從零開(kāi)始，那么企業(yè)本身必須為此承擔(dān)責(zé)任。因此，如今我們說(shuō)起重寫時(shí)，提到的其實(shí)是正常且應(yīng)當(dāng)定期進(jìn)行的應(yīng)用更新調(diào)整舉措。在這種情況下，開(kāi)發(fā)團(tuán)隊(duì)?wèi)?yīng)當(dāng)積極學(xué)習(xí)如何清理并推動(dòng)軟件更新。
但面對(duì)同樣的背景，有些團(tuán)隊(duì)會(huì)選擇從零開(kāi)始，而有些則更傾向于進(jìn)行重寫——為什么會(huì)出現(xiàn)這樣的區(qū)別?
之所以選擇重寫，可能是因?yàn)檐浖恢边\(yùn)行在早已過(guò)時(shí)的硬件之上，或者其依賴于早已落伍的軟件。這意味著該軟件可能在根本上與現(xiàn)有架構(gòu)之間無(wú)法交互。
無(wú)論實(shí)際情況如何，我們都可以將答案簡(jiǎn)單歸結(jié)為：如果改造成本比從零開(kāi)始更高，則選擇重寫。因此，價(jià)值判斷就成了最為核心的決定因素。
重構(gòu)還是重寫?商業(yè)案例
要準(zhǔn)確判斷這個(gè)問(wèn)題，大家應(yīng)當(dāng)立足于系統(tǒng)的最終運(yùn)行狀態(tài)預(yù)期，并根據(jù)如何從當(dāng)前狀態(tài)起步逐漸推進(jìn)至最終構(gòu)建結(jié)果勾勒出實(shí)施路線圖。
首先，如果這項(xiàng)工作根本無(wú)法完成，那么大家應(yīng)當(dāng)考慮重寫。很明顯，把COBOL這類綠屏數(shù)據(jù)庫(kù)應(yīng)用轉(zhuǎn)化為iPhone上的“憤怒的小鳥(niǎo)”幾乎是不可能的，因此直接編寫預(yù)期應(yīng)用更為科學(xué)。
如果能夠歸納出較為明確的改造途徑，那么請(qǐng)整理出改造相關(guān)步驟與需要重寫的組件。另外，盡可能立足于項(xiàng)目規(guī)模引入敏捷化概念——具體來(lái)講，不要糾結(jié)于各項(xiàng)任務(wù)需要多少個(gè)工時(shí)才能完成，而應(yīng)比較具體規(guī)模。如果“構(gòu)建一套數(shù)據(jù)訪問(wèn)層”需要3個(gè)時(shí)間單位，那么“解耦全部GUI依賴性”同樣需要3個(gè)時(shí)間單位還是更長(zhǎng)一些?總之，不要考慮具體時(shí)間，而應(yīng)著眼于相對(duì)復(fù)雜程度。
這樣的實(shí)踐思路能夠幫助大家提早進(jìn)行完整性檢查。當(dāng)然，在此之后還會(huì)有中斷時(shí)間、人員狀態(tài)以及許可費(fèi)用等問(wèn)題給任務(wù)推進(jìn)造成影響。另外，大家還需要通過(guò)扇入及耦合等指標(biāo)論證改造的實(shí)施難度。
但至少在起步階段，我們已經(jīng)找到了正確的推進(jìn)思路?！爸貙戇€是重構(gòu)”的問(wèn)題解決之后，接下來(lái)余下的將只是規(guī)模調(diào)整之類能夠按部就班處理的任務(wù)。
網(wǎng)站欄目：經(jīng)典難題解析：重寫還是重構(gòu)？
本文地址：http://www.dlmjj.cn/article/dhoosij.html
