熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Java編程 >> Java核心技術 >> 正文

用JBuilder 2005實現重構之認識重構

2013-11-23 18:52:09  來源: Java核心技術 

  為什麼要重構
  從Martin Fowler所著的《重構改善既有代碼的設計》一書連續兩年成為最暢銷的計算機圖書之一就可以知道重構給程序員所帶來的欣喜程度了
  
  那麼什麼是重構呢?重構就是在不改變軟件現有功能的基礎上通過調整程序代碼改善軟件的質量性能使其程序的設計模式和架構更趨合理提高軟件的擴展性和維護性
  
  也許有人會問為什麼不在項目開始時多花些時間把設計做好而要以後花時間來重構呢?要知道一個完美得可以預見未來任何變化的設計或一個靈活得可以容納任何擴展的設計是不存在的系統設計人員對即將著手的項目往往只能從大方向予以把控而無法知道每個細枝末節其次永遠不變的就是變化提出需求的用戶往往要在軟件成型後始才開始品頭論足系統設計人員畢竟不是先知先覺的神仙功能的變化導致設計的調整再所難免所以測試為先持續重構作為良好開發習慣被越來越多的人所采納測試和重構像黃河的護堤成為保證軟件質量的法寶
  
  通過重構可以達到以下的目標
  
  持續偏糾和改進軟件設計
  重構和設計是相輔相成的它和設計彼此互補有了重構你仍然必須做預先的設計但是不必是最優的設計只需要一個合理的解決方案就夠了如果沒有重構程序設計會逐漸腐敗變質愈來愈像斷線的風筝脫缰的野馬無法控制重構其實就是整理代碼讓所有帶著發散傾向的代碼回歸本位
  
  使代碼更易為人所理解
  Martin Flower在《重構》中有一句經典的話任何一個傻瓜都能寫出計算機可以理解的程序只有寫出人類容易理解的程序才是優秀的程序員對此筆者感觸很深有些程序員總是能夠快速編寫出可運行的代碼但代碼中晦澀的命名使人暈眩得需要緊握坐椅扶手試想一個新兵到來接手這樣的代碼他會不會想當逃兵呢?
  
  軟件的生命周期往往需要多批程序員來維護我們往往忽略了這些後來人為了使代碼容易被他人理解需要在實現軟件功能時做許多額外的事件如清晰的排版布局簡明扼要的注釋其中命名也是一個重要的方面一個很好的辦法就是采用暗喻命名即以對象實現的功能的依據用形象化或擬人化的手法進行命名一個很好的態度就是將每個代碼元素像新生兒一樣命名也許筆者有點命名偏執狂的傾向如能榮此雅號將深以此為幸
  
  對於那些讓人充滿迷茫感甚至誤導性的命名需要果決地大刀闊斧地整容永遠不要手下留情!
  
  幫助發現隱藏的代碼缺陷
  孔子說過溫故而知新重構代碼時逼迫你加深理解原先所寫的代碼筆者常有寫下程序後卻發生對自己的程序邏輯不甚理解的情景曾為此驚悚過後來發現這種症狀居然是許多程序員常患的感冒當你也發生這樣的情形時通過重構代碼可以加深對原設計的理解發現其中的問題和隱患構建出更好的代碼
  
  從長遠來看有助於提高編程效率
  當你發現解決一個問題變得異常復雜時往往不是問題本身造成的而是你用錯了方法拙劣的設計往往導致臃腫的編碼
  
  改善設計提高可讀性減少缺陷都是為了穩住陣腳良好的設計是成功的一半停下來通過重構改進設計或許會在當前減緩速度但它帶來的後發優勢卻是不可低估的
  
  何時著手重構
  新官上任三把火開始一個全新的項目時程序員往往也會燃起三把火緊鑼密鼓腳不停蹄加班加點一支聲勢浩大的千軍萬夾裹著程序員激情和扣擊鍵盤的鳴金奮力前行勢如破竹攻城掠地直指黃龍府
  
  開發經理是這支浩浩湯湯代碼隊伍的統帥他負責這支隊伍的命運當齊恆公站在山頂上看到管仲訓練的隊伍整齊劃一地前進時他感歎說我有這樣一支軍隊哪裡還怕沒有勝利呢?但很遺憾你手中的這支隊伍原本只是散兵游勇在前進中招兵買馬不斷壯大所以隊伍變形在所難免當開發經理發覺隊伍變形時也許就是克制住攻克前方山頭的誘惑停下腳步整頓隊伍的時候了
  
  Kent Beck提出了代碼壞味道的說法和我們所提出的隊伍變形是同樣的意思隊伍變形的信號是什麼呢?以下列述的代碼症狀就是隊伍變形的強烈信號
  
  代碼中存在重復的代碼
  中國有 家整車生產企業數量幾乎等於美歐所有汽車廠家數之和但是全國的年產量卻不及一個外國大汽車公司的產量重復建設只會導致效率的低效和資源的浪費
  
  程序代碼更是不能搞重復建設如果同一個類中有相同的代碼塊請把它提煉成類的一個獨立方法如果不同類中具有相同的代碼請把它提煉成一個新類永遠不要重復代碼
  
  過大的類和過長的方法
  過大的類往往是類抽象不合理的結果類抽象不合理將降低了代碼的復用率方法是類王國中的諸侯國諸侯國太大勢必動搖中央集權過長的方法由於包含的邏輯過於復雜錯誤機率將直線上升而可讀性則直線下降類的健壯性很容易被打破當看到一個過長的方法時需要想辦法將其劃分為多個小方法以便於分而治之
  
  牽一毛而需要動全身的修改
  當你發現修改一個小功能或增加一個小功能時就引發一次代碼地震也許是你的設計抽象度不夠理想功能代碼太過分散所引起的
  
  類之間需要過多的通訊
  A類需要調用B類的過多方法訪問B的內部數據在關系上這兩個類顯得有點狎昵可能這兩個類本應該在一起而不應該分家
  
  過度耦合的信息鏈
  計算機是這樣一門科學它相信可以通過添加一個中間層解決任何問題所以往往中間層會被過多地追加到程序中如果你在代碼中看到需要獲取一個信息需要一個類的方法調用另一個類的方法層層掛接就象輸油管一樣節節相連這往往是因為銜接層太多造成的需要查看就否有可移除的中間層或是否可以提供更直接的調用方法
  
  各立山頭干革命
  如果你發現有兩個類或兩個方法雖然命名不同但卻擁有相似或相同的功能你會發現往往是因為開發團隊成員協調不夠造成的筆者曾經寫了一個頗好用的字符串處理類但因為沒有及時通告團隊其他人員後來發現項目中居然有三個字符串處理類革命資源是珍貴的我們不應各立山頭干革命
  
  不完美的設計
  在筆者剛完成的一個比對報警項目中曾安排阿朱開發報警模塊即通過Socket向指定的短信平台語音平台及客戶端報警器插件發送報警報文信息阿朱出色地完成了這項任務後來用戶又提出了實時比對的需求即要求第三方系統以報文形式向比對報警系統發送請求比對報警系統接收並響應這個請求這又需要用到Socket報文通訊由於原來的設計沒有將報文通訊模塊獨立出來所以無法復用阿朱開發的代碼後來我及時調整了這個設計新增了一個報文收發模塊使系統所有的對外通訊都復用這個模塊系統的整體設計也顯得更加合理
  
  每個系統都或多或少存在不完美的設計剛開始可能注意不到到後來才會慢慢凸顯出來此時唯有勇於更改才是最好的出路
  
  缺少必要的注釋
  雖然許多軟件工程的書籍常提醒程序員需要防止過多注釋但這個擔心好象並沒有什麼必要往往程序員更感興趣的是功能實現而非代碼注釋因為前者更能帶來成就感所以代碼注釋往往不是過多而是過少過於簡單人的記憶曲線下降的坡度是陡得嚇人的當過了一段時間後再回頭補注釋時很容易發生提筆忘字愈言且止的情形
  
  曾在網上看到過微軟的代碼注釋其詳盡程度讓人歎為觀止也從中體悟到了微軟成功的一個經驗
From:http://tw.wingwit.com/Article/program/Java/hx/201311/25897.html
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.