[[442713]]

重構(gòu)是提高質(zhì)量的重要工具。許多開發(fā)方法都依賴于重構(gòu)，尤其是對于敏捷方法，在更多計劃驅(qū)動的組織中也是如此。但事實上，是否以重構(gòu)來處理設(shè)計中的某些問題呢?是否存在重構(gòu)的障礙呢?

不重構(gòu)的原因

存在質(zhì)量問題而不進行重構(gòu)的理由可以分為以下幾類:

資源

對所需資源的關(guān)注是不進行重構(gòu)的一個經(jīng)常被提到的原因。最常提到的資源是時間，比如“DDL不允許”，“有時候就是沒有時間”或者單純的“就是沒有時間”。

風(fēng)險

同樣經(jīng)常被提到的還有更改所涉及的風(fēng)險，尤其是引入新的錯誤或其他問題，比如“這種重構(gòu)很耗時間，而且引入錯誤的風(fēng)險很大”，以及“反正還能用，管它干嘛”等等。

難度

另一個問題是進行更改的難度，比如“繼承很難正確重構(gòu)”和“這種重構(gòu)通常很困難”等等。

投資回報率

雖然重構(gòu)可能會帶來好處，但也有成本，投資回報率也必須考慮，例如“必須再次權(quán)衡成本和好處，在承擔重構(gòu)、重測試等方面的成本之前，必須明確收益。”

技術(shù)

項目的特點限制了重構(gòu)的能力。例如，必須實現(xiàn)超出限制的第三方接口，擔心任何潛在的更改對系統(tǒng)其他部分的影響，對代碼的熟悉程度，處理遺留代碼，以及缺乏其他支持(如測試套件) ，尤其是“大量遺留代碼庫使重構(gòu)變得困難”; “如果沒有測試方法，系統(tǒng)可能被破壞”; 以及“沒有時間進行重構(gòu)的預(yù)算。”等等

管理

開發(fā)者并不總是能控制他們的時間使用。老板或客戶更有發(fā)言權(quán)，比如“想要重構(gòu)，但老板不喜歡”、“只關(guān)注截止日期的老板”、“客戶不會為此付錢”等等。

工具

工具支持不足也被認為是不重構(gòu)的一個原因，然而，這些的工具并不是那些進行重構(gòu)的那些工具，某些重構(gòu)非常痛苦，實際上是缺乏工具的支持。微軟對 Windows 進行了某種形式的重構(gòu)，確定了執(zhí)行重構(gòu)的挑戰(zhàn)，例如管理組件間和分支間的依賴關(guān)系以及維護向下兼容，也許最令人驚訝的主題是完全不關(guān)心重構(gòu)工具支持的存在和質(zhì)量。

重構(gòu)的障礙與時機

重構(gòu)并非難在怎么做，而是難在何時開始做。對于一個高速發(fā)展的企業(yè)來說，停下來做重構(gòu)從來就不是一個可接受的選項，“邊開飛機邊換引擎”才是公司想要的。當代碼還不是很混亂的時候，重構(gòu)的必要性不高，相比不小心重構(gòu)出錯導(dǎo)致熄火的風(fēng)險來說，得過且過可能反而是一個明智之選。于是，各種技術(shù)債就這樣慢慢積累起來，直到業(yè)務(wù)因為各種技術(shù)債快跑不動的時候，才不得不用一些激進的重構(gòu)手段快速的解決歷史頑疾。

代碼分析未必有效

在軟件工程中，往往使用每類加權(quán)方法(WMC)和繼承樹(Depth of Inheritance Tree，DIT) 來度量面向?qū)ο蟮脑O(shè)計，這些度量常常被表示為可能的設(shè)計問題，即WMC 或 DIT 的值越高，就越有可能出現(xiàn)問題。WMC 是類的大小度量的一種形式，最簡單的形式是類中方法數(shù)量的計數(shù)。DIT 捕獲繼承層次結(jié)構(gòu)的一個特征，它是從類到層次結(jié)構(gòu)根的最長路徑長度。然而，對軟件系統(tǒng)的測量表明，有些類具有很多方法，或者在層次結(jié)構(gòu)中非常深。它就需要重構(gòu)么?

實際上，工程師更傾向于限制類的深度，而不是方法的數(shù)量，但是當超過某個深度限制時，開發(fā)者傾向于不做任何事情。

兩個主要障礙

很多時候，無法確定 ROI 才是一個障礙，比如“如果不能對需要多長時間做出合理的估計，就不會管它。”也就是說，決定不重構(gòu)并不是因為它被認為是一個壞主意，而是因為它的收益不確定。在特定情況下進行重構(gòu)時，通常很少或根本不知道實際的 ROI 是什么。

一個潛在的障礙是很難將重構(gòu)目標轉(zhuǎn)化為重構(gòu)操作。需要的是一個決策支持系統(tǒng)，使從業(yè)人員能夠量化長期和短期效益。這將有助于為決定所需資源是否合理或是否容忍潛在風(fēng)險提供信息，還允許開發(fā)人員和管理人員就是否重構(gòu)做出明智的選擇。

重構(gòu)的時機

具體地，Martin Folwer在《重構(gòu)》一書中提到，需要識別壞味道，并提出了進行重構(gòu)的4種情況，即關(guān)于重構(gòu)的CRUD：

• 增：增加新功能的時候，發(fā)現(xiàn)需要重構(gòu)來便于新功能的添加
• 刪：事不過三，消除重復(fù)
• 改：修復(fù)缺陷，改Bug的時候
• 查：代碼評審的時候得到了很多建設(shè)性的意見

也就是說，設(shè)計沒有表達出對需求的最新理解，或者需求沒有被很好地實現(xiàn)，而且已經(jīng)發(fā)現(xiàn)更好的實現(xiàn)方法，以及發(fā)現(xiàn)了一個能使某個設(shè)計變得簡單、靈活的方法。實際上，重構(gòu)的時機只是做出是否重構(gòu)的判斷時機。

另外，使用重構(gòu)工具的兩個好處是錯誤率更低，所需時間更少，因此好的工具支持應(yīng)該在一定程度上解決開發(fā)人員的問題。只有當重構(gòu)的決定已經(jīng)做出時，重構(gòu)工具的支持才會起作用。實際上，不使用自動化進行重構(gòu)的原因可能包括信任、可預(yù)測性和復(fù)雜性。

小結(jié)

無論軟件設(shè)計質(zhì)量問題是如何識別的，開發(fā)者都無法通過重構(gòu)來根本消除這些問題。減少甚至消除重構(gòu)的障礙有可能顯著提高軟件質(zhì)量。一種方法是提供目標導(dǎo)向的重構(gòu)支持，而不是操作導(dǎo)向的重構(gòu)支持。另一個辦法是更好地量化效益，從而更好地告知是否重構(gòu)的決定。