軟件重構需要借助工具完成，重構工具能夠修改代碼同時修改所有引用該代碼的地方。在極限編程的方法學中，重構需要單元測試來支持。
java重構：指程序員對已有程序在盡量不改變接口的前提下，進行重新編寫代碼的工作，壹般有以下幾方面：
1、去除已知bug。
2、提高程序運行效率。
3、增加新的功能。
重構舉例：（簡化代碼、提升效率）
重構前：
if(list != null && list.size() > 0){
for(int i = 0; i < list.size(); i++){
//skip...
}
}
重構後
if(list != null){
for(int i = 0, len = list.size(); i < len; i++){
//skip...
}
}
何時著手重構（Refactoring）
新官上任三把火，開始壹個全新?、腳不停蹄、加班加點，壹支聲勢浩大的千軍萬"碼"夾裹著程序員激情和扣擊鍵盤的鳴金奮力前行，勢如破竹，攻城掠地，直指"黃龍府"。
開發經理是這支浩浩湯湯代碼隊伍的統帥，他負責這支隊伍的命運，當齊桓公站在山頂上看到管仲訓練的隊伍整齊劃壹地前進時，他感嘆說"我有這樣壹支軍隊哪裏還怕沒有勝利呢？"。但很遺憾，妳手中的這支隊伍原本只是散兵遊勇，在前進中招兵買馬，不斷壯大，所以隊伍變形在所難免。當開發經理發覺隊伍變形時，也許就是克制住攻克前方山頭的誘惑，停下腳步整頓隊伍的時候了。
Kent Beck提出了"代碼壞味道"的說法，和我們所提出的"隊伍變形"是同樣的意思，隊伍變形的信號是什麽呢？以下列述的代碼癥狀就是"隊伍變形"的強烈信號：
·代碼中存在重復的代碼
中國有118 家整車生產企業，數量幾乎等於美、日、歐所有汽車廠家數之和，但是全國的年產量卻不及壹個外國大汽車公司的產量。重復建設只會導致效率的低效和資源的浪費。
程序代碼更是不能搞重復建設，如果同壹個類中有相同的代碼塊，請把它提煉成類的壹個獨立方法，如果不同類中具有相同的代碼，請把它提煉成壹個新類，永遠不要重復代碼。
·過大的類和過長的方法
過大的類往往是類抽象不合理的結果，類抽象不合理將降低了代碼的復用率。方法是類王國中的諸侯國，諸侯國太大勢必動搖中央集權。過長的方法由於包含的邏輯過於復雜，錯誤機率將直線上升，而可讀性則直線下降，類的健壯性很容易被打破。當看到壹個過長的方法時，需要想辦法將其劃分為多個小方法，以便於分而治之。
·牽壹毛而需要動全身的修改
當妳發現修改壹個小功能，或增加壹個小功能時，就引發壹次代碼地震，也許是妳的設計抽象度不夠理想，功能代碼太過分散所引起的。
·類之間需要過多的通訊
A類需要調用B類的過多方法訪問B的內部數據，在關系上這兩個類顯得有點狎昵，可能這兩個類本應該在壹起，而不應該分家。
·過度耦合的信息鏈
"計算機是這樣壹門科學，它相信可以通過添加壹個中間層解決任何問題"，所以往往中間層會被過多地追加到程序中。如果妳在代碼中看到需要獲取壹個信息，需要壹個類的方法調用另壹個類的方法，層層掛接，就象輸油管壹樣節節相連。這往往是因為銜接層太多造成的，需要查看就否有可移除的中間層，或是否可以提供更直接的調用方法。
·各立山頭幹革命
如果妳發現有兩個類或兩個方法雖然命名不同但卻擁有相似或相同的功能，妳會發現往往是因為開發團隊協調不夠造成的。筆者曾經寫了壹個頗好用的字符串處理類，但因為沒有及時通告團隊其他人員，後來發現項目中居然有三個字符串處理類。革命資源是珍貴的，我們不應各立山頭幹革命。
·不完美的設計
在筆者剛完成的壹個比對報警項目中，曾安排阿朱開發報警模塊，即通過Socket向指定的短信平臺、語音平臺及客戶端報警器插件發送報警報文信息，阿朱出色地完成了這項任務。後來用戶又提出了實時比對的需求，即要求第三方系統以報文形式向比對報警系統發送請求，比對報警系統接收並響應這個請求。這又需要用到Socket報文通訊，由於原來的設計沒有將報文通訊模塊獨立出來，所以無法復用阿朱開發的代碼。後來我及時調整了這個設計，新增了壹個報文收發模塊，使系統所有的對外通訊都復用這個模塊，系統的整體設計也顯得更加合理。
每個系統都或多或少存在不完美的設計，剛開始可能註意不到，到後來才會慢慢凸顯出來，此時唯有勇於更改才是最好的出路。
·缺少必要的註釋
雖然許多軟件工程的書籍常提醒程序員需要防止過多註釋，但這個擔心好象並沒有什麽必要。往往程序員更感興趣的是功能實現而非代碼註釋，因為前者更能帶來成就感，所以代碼註釋往往不是過多而是過少，過於簡單。人的記憶曲線下降的坡度是陡得嚇人的，當過了壹段時間後再回頭補註釋時，很容易發生"提筆忘字，愈言且止"的情形。
曾在網上看到過微軟的代碼註釋，其詳盡程度讓人嘆為觀止，也從中體悟到了微軟成功的壹個經驗。