用代碼度量進行重構

在我上中學的時候，有一位英語教師說：“寫作就是重寫別人已經 重寫過的東西�！� 直到大學，我才真正理解了他這句話的意思。而且，當我自覺地采用這個實踐的時候，就開始喜歡上了寫作。我開始為我寫的東西自豪。我開始真正在意我的表達方式和要傳達的內容。

當我開始開發人員生涯時，我喜歡閱讀有經驗的專家編寫的技術書籍，而且想知道為什么他們花這么多時間編寫代碼。那時，編寫代碼看起來是件容易的工作 —— 有些人（總是比我級別高的人）會給我一個問題，而我會用任何可行的方法解決它。

直到我開始與其他開發人員合作大型項目，才開始理解我的技能的真正意義所在。我也就在這個時候起，開始有意識地關心我編寫的代碼，甚至關心起其他人 編寫的代碼�，F在我知道了，如果不注意代碼質量，那么遲早它們會給我造成一團亂麻。

我恍然大悟 的一刻出現在 1999 年底，那時我正在閱讀 Martin Fowler 那本影響重大的書 Refactoring: Improving the Design of Existing Code（重構：改進現有代碼的設計，這本書對一系列重構模式進行分類，并由此建立了重構的公共詞匯。在此之前，我一直都在重構我的代碼（或者其他人的代碼），但是卻不知道自己做的就是重構�，F在，我開始為我編寫和重構的代碼感到更加自豪，因為我做的工作正是在促進代碼的編寫方式并讓它們日后更易維護。

什么是重構？

按照我的觀點，重構就是改進已經改進的 代碼的行為。實際上，重構是個永不停止的代碼編寫過程，它的目的是通過結構的改進而提高代碼體的可維護性，但卻不 改變代碼的整體行為。重要的是要記住重構與重寫 代碼明顯不同。

重寫代碼會修改代碼的行為甚至合約，而重構保持對外接口不變。對于重構方法的客戶機來說，看不到區別。事情像以前一樣工作，但是工作得更好，主要是因為增強的可測試性或者明顯的性能提升。

主動和被動重構

那么問題就變成了“我怎么才能知道什么時候該進行重構呢？” 一段代碼的可維護性是個主觀的問題。但是，我們中的多數人都會發現，維護自己編寫的代碼要比維護其他人編寫的代碼容易得多。但在這點上也有爭議 —— 在整個職業生涯中維護自己的代碼是最大挑戰。沒有幾個真正的 “代碼牛仔” 足夠幸運地能夠不斷地變換工作，而不必修改其他人的代碼。對于我們中的多數人來說，必須維護其他人的代碼恰恰是程序員生活的一部分。決定代碼是否需要重構的方法，通常是主觀的。

但是，也有可能客觀地判斷代碼是否應當重構，不論是自己的代碼還是別人的代碼。在 這個系列前面的文章中，我介紹了如何用代碼度量客觀地測試代碼質量。實際上，可以用代碼度量很容易地找出可能難以維護的代碼。一旦客觀地判斷出代碼中有問題，那么就可以用方便的重構模式改進它。

總是運行測試用例！ 重構別人編寫的代碼的秘訣是不要把它弄得更糟。在我重構生涯的早期，學到的一件事就是在修改一些東西之前 擁有一個測試用例很重要。我是通過艱苦的一夜，在我自己整理得很好的重構方法中苦苦尋覓，只為找到一個我不小心破壞的別人編寫的工作正常的代碼之后學到這個教訓的，不小心破壞的原因就在于重構之前沒有對應的測試用例。請注意我的警告，在自己進行重構之前，總是要運行測試用例！

提取方法模式

Martin Fowler 的書出版之后的幾年中，增加了許多新的重構模式分類；但是，迄今為止最容易學習的模式，也可能是最有效的模式，仍然是提取方法（Extract Method） 模式。在這個模式中，方法的一個邏輯部分被移除，并被賦予自己的方法定義�，F在被移走的方法體被新方法的調用代替，如圖 1 的 UML 圖所示：

提取方法模式提供了兩個關鍵好處：

• 原來的方法現在更短了，因此也更容易理解。
• 移走并放在自己方法中的邏輯體現在更容易測試。

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: 度量