代碼重構方法在敏捷開發中的應用

鮮茜

（四川大學計算機學院，成都 610065)

代碼重構方法在敏捷開發中的應用

鮮茜

（四川大學計算機學院，成都 610065)

軟件產品由于互聯網蓬勃發展而以井噴之勢持續遞增。許多企業選擇敏捷開發模式來節約時間成本。同時，需要對軟件進行不斷地完善和改進，這導致軟件越來越復雜，維護成本增加。因此，代碼重構顯得十分重要，通過參考大量文獻和依托項目實例，總結優化代碼的一些改進方法，并以結果展示代碼重構后能提高其性能，使軟件更易于理解和維護。

重構；敏捷開發；改進方法

0 引言

科技社會日新月異，互聯網行業突飛猛進，許多互聯網公司如雨后春筍般崛起。在面臨行業競爭，需要提升產品的功能多樣性、易用性、安全性、用戶體驗等復雜需求下，企業往往采用敏捷開發，這種開發技術的優點不言而喻，但缺點在于小組成員間工作較為獨立，各自在代碼風格、邏輯結構方面有較大差異。軟件產品隨著時間的推移，必須不斷地修改原有的代碼、增加新的功能。為了實現變更，不可避免地要違反最初的設計構架。一段時間以后，軟件的架構就會千瘡百孔。代碼以指數級數量增加，發現的代碼錯誤越來越多，系統變得很難維護，間接說明代碼存在許多問題。例如：可讀性差、冗余、代碼依賴性強、自動測試代碼更新不及時、維護困難。

這個現象帶來了科技的革新：代碼演化技術、代碼自動化生成、測試驅動、形式化驗證、代碼重構與優化等方面的研究。其中，代碼重構技術十分重要，它是優化功能代碼的核心技術，不改變系統的外部功能，只對內部的結構進行重新的整理，能夠在較大程度優化代碼，使系統對需求變化具有自適應能力。

通過實際項目中代碼重構經驗，分析對比重構前后代碼性能、代碼復雜度等參數。總結其中有效的優化方法，保證功能工作的情況下，使軟件得到改進。

1 相關工作

Martin Fowler清楚揭示了重構過程，解釋重構的原理，并指出何時何地你應該開始挖掘你的代碼以求改善[1]。陳林等人針對現有泛化關系重構方法在處理泛型程序時不考慮參數化類型的約束，會破壞程序類型正確性的問題，提出了一組泛型Java程序的類型約束規則，可以在與程序代碼規模成線性關系的時間內實施重構,并有效地保證程序的類型正確性[2]。Kataoka等人提出一種定量評價方法來衡量程序重構的可維護性增強效果。專注于耦合度量來評估重構效應[3]。Van等人提供了一組具有“壞氣味”的代碼，之后給出了測試的集合重構去除這些問題代碼。最終，通過一個簡單程序的修改，測試重構解釋的集合證明如何克服這些問題[4]。Du等人分析在哪些特定條件下如何重構操作耦合/凝聚力特征，以及如何識別重構的這些特征是否得到改善，最終在一個開放源碼軟件系統驗證相關改進和適用性[5]。

2 重構方法概述

根據目標管理SMART原則，制定重構計劃。需要考慮重構所需時間，具體地為每個小目標設定一個合理的最后期限，并設置明確的度量來評估目標是否達成。采取結對編程有效策略，重構之前構建有效的測試來保證代碼質量。將重構分為功能代碼和測試代碼兩部分來進行。如圖1所示，審視代碼整體結構和風格，分析出依賴關系并統一風格，在重構之前進行回歸測試。接下來對功能代碼風格和業務邏輯進行重構，并每修改一次，進行回歸測試，一直到所有結束。

圖1 重構流程圖

2.1 重構重點

①打破依賴明確的關系

②構建堅實的測試

③優化代碼，重新審視遺留缺陷

2.2 重構步驟

在實際工程項目中，代碼庫一直在持續集成服務器運行著，所以需要先從源代碼干線拉出一條分支進行重構。這樣可以使重構周期限于非常小的范圍，通常為1或2個類；改進類設計時不會涉及業務邏輯，修改一個類之后，需要用自動化測試工具進行功能測試，直到測試通過；周而復始繼續修改類，直到所有類都更改，保證功能不受影響后，提交回代碼庫主干線。

3 實現及方法總結

3.1 功能代碼優化

（1）有狀態的服務對象

●癥狀

一些服務對象是有狀態的，因為它們會從請求對象那里提取數據。代碼為每個服務對象將請求對象轉換成一個字段，并為每個請求創建新對象。當系統負載很高時會對JVM（Java虛擬機）造成強工作負載來分配內存和垃圾回收。讓所有的服務對象線程變得不安全。

●解決方法

打破依賴，有一個明確的數據和邏輯的分離，讓所有服務對象無狀態，狀態駐留在請求對象本身。所有的服務方法的請求對象作為輸入參數，這樣使得每個服務對象可以一次創建并為多個請求所重用。

圖2 類重構流程圖

（2）類關聯

●癥狀

類與類之間有繼承關系、泛化關系、依賴關系、關聯關系、聚合關系、組合關系六種關系，這些關系分類較細，有時往往會對此認識不清晰。沒有明確的泛化關系，而依賴關系是由調用者從靜態工廠方法和獲取使用之前初始化。而且代碼中存在工廠模式的錯誤使用導致代碼冗余、代碼層次多余、結構紊亂等問題。很難闡述代碼變化的影響，而且容易創建一個循環引用關系。

●解決方法

通過為依賴接口創建字段，使依賴關系顯式化。封裝調用者的類和實現函數的功能代碼，實現高內聚低耦合。

（3）對象創建

●癥狀

對象實例是根據每個請求創建，即使在同一類的不同方法中，也會重復創建相同的依賴對象實例。隨意的創建對象會增加了JVM的不必要的工作負載，并可能導致性能問題，從而整個產品性能較差，用戶體驗不佳。

●解決方法

除了請求對象之外，所有對象實例都由Spring（Java的一種框架）在應用程序啟動時創建一次，并重復用于不同的請求，只有在必要時才創建一個新對象，對象生命周期應該由框架管理。依賴對象是類的字段，使用Spring框架創建對象實例，使對象單例，然后使用Spring框架注入依賴對象實例。

（4）功能函數

●癥狀

函數是程序中最基本的功能結構，是一個可以從程序其它地方調用執行的語句塊。函數通常只完成一個功能，當函數代碼行數數量龐大，缺少戰略異常處理和日志記錄。會使得代碼難以閱讀，而且難以理解，查錯和維護變得困難。函數嵌套層次比較深時，內部調用外部代碼時常常會引發錯誤調用。

●解決方法

良好的軟件系統設計需要將函數設計為實現單一功能，并且有一個自頂向下的抽象層。縮短代碼函數以便于閱讀、理解和維護代碼。盡可能調用已有成熟的開源編程實現的函數。

（5）異常

●癥狀

異常處理功能提供了處理程序運行時出現的任何意外或異常情況的方法。異常處理使用 try、catch和finally關鍵字來處理可能未成功的操作和失敗，以及在事后清理資源。通過異常處理，可以對用戶在程序中的非法輸入進行控制和提示，以防程序崩潰。在項目代碼中使用超級異常包裝各種錯誤代碼，范圍跨度太大，不能較好地適用于不同的異常情況，同時導致錯誤處理和日志記錄幾乎發生在每種方法中，十分冗余和低效。

●解決方法

為不同的情況定義不同的異常類型，通過try{} catch（）子句中的類型處理異常。并且僅使用運行時異常。如果錯誤處理的唯一操作是日志記錄，則在每個模塊的入口點只執行一次。設計時，定義異常需考慮層次、細分情況和系統產品界面友好。

程序中的關鍵代碼如下：

3.2 測試代碼優化

自動化測試是代碼重構的先決條件和重要步驟。沒有構建完備的自動化測試環境，即使代碼優化完成后，也無法驗證是否每一個修改動作是否是正確的。因此，構建和優化自動測試代碼也十分必要。

（1）單元測試設計與風格

●癥狀

通常而言，一個單元測試是用于判斷某個特定條件下某個特定函數的行為。然而，在項目代碼中單元測試代碼數量巨大，一個案例測試了多個功能，單個案例中包括多個“assert”語句，顯得十分冗長。在單元測試代碼中沒有“Given-When-Then”代碼風格結構，易讀性差。

●解決方法

每個單元測試按照“Given-When-Then”代碼風格寫，使邏輯結構清晰，提高易讀性。每個案例只專注測試一個函數，減少測試代碼行數。

程序中的關鍵代碼如下：

●癥狀

mock測試是在測試過程中，對于某些不容易構造或者不容易獲取的對象，用一個虛擬的對象來創建以便測試的測試方法。偽依賴的實現在單元測試中被用作mock，有時測試目標本身被部mock。更糟的是使用Java反射機制，并且當設置mock對象時，方法名稱被硬編碼為字符串。一半的測試代碼是關于設置mock，而不是關于測試開發代碼本身。

●解決方法

所有的mock由mock框架動態創建的，沒有實際的mock類代碼。測試目標是真正的實現代碼，注入所有mock依賴項。使用代理對象、模擬對象和輔助對象來隔離網絡，數據庫，文件和用戶接口。設置mock時使用智能默認設置，可以減少mock代碼。不要用硬編碼設置方法名，mock最多用來測靜態方法。

（3）覆蓋率

●癥狀

測試覆蓋是對測試完全程度的評測。測試覆蓋是由測試需求和測試用例的覆蓋或已執行代碼的覆蓋表示。測試代碼中路徑覆蓋似乎很好，但事實上一些邊界和特殊條件并沒有測試。一些測試用例沒有驗證到任何功能，它們只是用來制造一個不錯的覆蓋率。

●解決方法

刪除無用的測試保證測試單元測試用例有用且有效。不要為了覆蓋率在單元測試中制造空的測試函數。即使覆蓋數量已經達到目標，繼續優化邊界和異常測試。

4 重構結果分析

表1展示了項目其中三個模塊代碼重構前后一些參數的對比，可以清晰的看到，代碼行數、方法復雜度和類復雜度有在一定程度上減少，有效地減少了軟件容量。而單元測試覆蓋率和事務成功率的增加間接說明軟件質量得到保證、性能提高。

表1 相關參數比較

5 結語

一方面，軟件質量得到巨大的改進，具體體現在冗余代碼歸類、抽象提取和刪除，結構重新設計、減少時間復雜度，使代碼易讀，便于維護。另一方面，通過項目實踐增強對重構代碼的理解，掌握了如何結合實際情況構建重構的方法。維護工作減少，參與重構工作的人員的業務能力提高，對代碼邏輯有了清晰的認識。

未來研究設計重構驅動開發的方法及工具，選擇最優架構方案，避免多次修改代碼，破壞整體架構以及付出巨大的人力開銷。探索更多地使用于不同規模、用途的軟件系統的代碼重構方案，以便提高工業界生產效率，保證產品質量。

[1]Martin Fowler．Refactoring:Improving the Design of Existing Code[M]．America：Addison-Wesley Professional，1999.

[2]陳林，徐寶文，周曉宇等．一種基于類型約束的泛型Java程序重構方法[J].電子學報,2007:35（s2）:185-191.

[3]Kataoka Y,Imai T,Andou H,et al.A Quantitative Evaluation of Maintainability Enhancement by Refactoring[C].Software Maintenance,2002.Proceedings.International Conference on.IEEE,2002:576-585.

[4]Van Deursen A,Moonen L,van den Bergh A,et al.Refactoring Test Code[C].Proceedings of the 2nd International Conference on Extreme Programming and Flexible Processes in Software Engineering，2001：92-95.

[5]Du Bois B,Demeyer S,Verelst J.Refactoring-Improving Coupling and Cohesion of Existing Code[C].Reverse Engineering,2004.Proceedings.11th Working Conference on.IEEE,2004：144-151.

作者簡介：

Application of Code Refactoring in Agile Development

XIAN Xi
（College of Computer Science,Sichuan University,Chengdu 610065）

Software products blow up the trend that continues to increase due to the vigorous development of the Internet.Many companies choose agile development models to save time costs.At the same time,the need for continuous improvement and improvement of software,which lead software become more and more complex as well as the maintenance costs increased.Therefore,the code refactoring is very important.Summarizes the improved methods of optimizing the code by referring to a large number of documents and relying on the project experience,and shows the improvement of performance with result makes the software easier to understand and maintain.

Refactoring;Agile Development;Improvement Methods

1007-1423（2017）09-0123-05

10.3969/j.issn.1007-1423.2017.09.028

，女，四川成都人，碩士，研究方向為軟件質量保證與測試

2017-03-11

2017-03-20