⑴ 如何使用IntelliJ IDEA來重構代碼
Ctrl+Alt+L 格式化代碼
Ctrl+Shift+J 兩行合成一行，刪去不必要的空格匹配代碼格式
其他快捷鍵：
【常規】
Ctrl+Shift + Enter，語句完成
「！」，否定完成，輸入表達式時按 「！」鍵
Ctrl+E，最近的文件
Ctrl+Shift+E，最近更改的文件
Shift+Click，可以關閉文件
Ctrl+[ OR ]，可以跑到大括弧的開頭與結尾
Ctrl+F12，可以顯示當前文件的結構
Ctrl+F7，可以查詢當前元素在當前文件中的引用，然後按 F3 可以選擇
Ctrl+N，可以快速打開類
Ctrl+Shift+N，可以快速打開文件
Alt+Q，可以看到當前方法的聲明
Ctrl+P，可以顯示參數信息
Ctrl+Shift+Insert，可以選擇剪貼板內容並插入
Alt+Insert，可以生成構造器/Getter/Setter等
Ctrl+Alt+V，可以引入變數。例如：new String(); 自動導入變數定義
Ctrl+Alt+T，可以把代碼包在一個塊內，例如：try/catch
Ctrl+Enter，導入包，自動修正
Ctrl+Alt+L，格式化代碼
Ctrl+Alt+I，將選中的代碼進行自動縮進編排，這個功能在編輯 JSP 文件時也可以工作
Ctrl+Alt+O，優化導入的類和包
Ctrl+R，替換文本
Ctrl+F，查找文本
Ctrl+Shift+Space，自動補全代碼
Ctrl+空格，代碼提示（與系統輸入法快捷鍵沖突）
Ctrl+Shift+Alt+N，查找類中的方法或變數
Alt+Shift+C，最近的更改
Alt+Shift+Up/Down，上/下移一行
Shift+F6，重構 – 重命名
Ctrl+X，刪除行
Ctrl+D，復制行
Ctrl+/或Ctrl+Shift+/，注釋（//或者/**/）
Ctrl+J，自動代碼（例如：serr）
Ctrl+Alt+J，用動態模板環繞
Ctrl+H，顯示類結構圖（類的繼承層次）
Ctrl+Q，顯示注釋文檔
Alt+F1，查找代碼所在位置
Alt+1，快速打開或隱藏工程面板
Ctrl+Alt+left/right，返回至上次瀏覽的位置
Alt+left/right，切換代碼視圖
Alt+Up/Down，在方法間快速移動定位
Ctrl+Shift+Up/Down，向上/下移動語句
F2 或 Shift+F2，高亮錯誤或警告快速定位
Tab，代碼標簽輸入完成後，按 Tab，生成代碼
Ctrl+Shift+F7，高亮顯示所有該文本，按 Esc 高亮消失
Alt+F3，逐個往下查找相同文本，並高亮顯示
Ctrl+Up/Down，游標中轉到第一行或最後一行下
Ctrl+B/Ctrl+Click，快速打開游標處的類或方法（跳轉到定義處）
Ctrl+Alt+B，跳轉到方法實現處
Ctrl+Shift+Backspace，跳轉到上次編輯的地方
Ctrl+O，重寫方法
Ctrl+Alt+Space，類名自動完成
Ctrl+Alt+Up/Down，快速跳轉搜索結果
Ctrl+Shift+J，整合兩行
Alt+F8，計算變數值
Ctrl+Shift+V，可以將最近使用的剪貼板內容選擇插入到文本
Ctrl+Alt+Shift+V，簡單粘貼
Shift+Esc，不僅可以把焦點移到編輯器上，而且還可以隱藏當前（或最後活動的）工具窗口
F12，把焦點從編輯器移到最近使用的工具窗口
Shift+F1，要打開編輯器游標字元處使用的類或者方法 java 文檔的瀏覽器
Ctrl+W，可以選擇單詞繼而語句繼而行繼而函數
Ctrl+Shift+W，取消選擇游標所在詞
Alt+F7，查找整個工程中使用地某一個類、方法或者變數的位置
Ctrl+I，實現方法
Ctrl+Shift+U，大小寫轉化
Ctrl+Y，刪除當前行
Shift+Enter，向下插入新行
psvm/sout，main/System.out.println(); Ctrl+J，查看更多
Ctrl+Shift+F，全局查找
Ctrl+F，查找/Shift+F3，向上查找/F3，向下查找
Ctrl+Shift+S，高級搜索
Ctrl+U，轉到父類
Ctrl+Alt+S，打開設置對話框
Alt+Shift+Inert，開啟/關閉列選擇模式
Ctrl+Alt+Shift+S，打開當前項目/模塊屬性
Ctrl+G，定位行
Alt+Home，跳轉到導航欄
Ctrl+Enter，上插一行
Ctrl+Backspace，按單詞刪除
Ctrl+」+/-」，當前方法展開、折疊
Ctrl+Shift+」+/-」，全部展開、折疊
Alt+1，項目
Alt+2，收藏
Alt+6，TODO
Alt+7，結構
Ctrl+Shift+C，復制路徑
Ctrl+Alt+Shift+C，復制引用，必須選擇類名
Ctrl+Alt+Y，同步
Ctrl+~，快速切換方案（界面外觀、代碼風格、快捷鍵映射等菜單）
Ctrl+Tab，轉到下一個拆分器
Ctrl+Shift+Tab，轉到上一個拆分器
【重構】
Ctrl+Alt+Shift+T，彈出重構菜單
Alt+Delete，安全刪除
Ctrl+Alt+N，內聯
【查找】
Ctrl+F，查找
Ctrl+R，替換
Ctrl+Shift+F，在路徑中查找
Ctrl+Shift+R，在路徑中替換
Ctrl+Shift+S，搜索結構
Ctrl+Shift+M，替換結構
【VCS】
Alt+~，VCS 操作菜單
Ctrl+K，提交更改
Ctrl+T，更新項目
Ctrl+Alt+Shift+D，顯示變化
補充說明：
IDEA
全稱IntelliJ
IDEA，是java語言開發的集成環境，IntelliJ在業界被公認為最好的java開發工具之一，尤其在智能代碼助手、代碼自動提示、重構、
J2EE支持、Ant、JUnit、CVS整合、代碼審查、
創新的GUI設計等方面的功能可以說是超常的。IDEA是JetBrains公司的產品，這家公司總部位於捷克共和國的首都布拉格，開發人員以嚴謹著稱的
東歐程序員為主。
⑵ 為什麼國內程序員都很少進行代碼重構
說到代碼的重構對於國外的程序員提到的比較多，特別是大型的開源工程，基本上一個模塊或者函數的實現會反復的修改，一個文件能被修改成千上萬次，曾經訂閱了linux內核組的郵件，每天的收到的修改文件成千上萬，有時候一個文件都能被修改上百次，對於文件修改最瘋狂的是google的chrome源碼，重構的次數，讓你覺得每天都在重寫但是功能上感覺越來越流暢。為什麼我們周圍的程序員絕大部分時間做的不是這樣的事情。
為啥從直覺上覺得老外的寫的代買質量比我們的要高，我們國內的程序員絕大部分的時間是在趕進度，准確的來講忙著增加功能和修改bug，其實也從側面反映出為什麼國內出不了android以及Linux等影響深遠的 科技 創新，從全球開源代碼的佔比就可以看出，差距還是很巨大的。
為什麼覺得老外寫的代碼比我們的強？
1.國內軟體發展主要階段還在解決有沒有，還遠談不上強大
中國的軟體經過近幾十年長足的發展，已經取得了巨大的成就，特別在互聯網行業已經有幾個巨頭躋身世界前列了，最近炒的很熱的臉書的用戶數據泄密事件，作為當事人扎克伯格，也在論述中提到中國有幾個很厲害的互聯網公司，這說明中國在互聯網領域還是取得了相當大的成就，但是在一些核心的領域，或者門檻很高的領域差別還是非常巨大。
任何事情在發展的初級階段首要考慮的是不是有沒有，所以如同創業初期的公司會選擇短時間內搞出來個產品，哪怕是不成熟的產品，然後快速的投入市場，根據市場用戶的反應同步追蹤問題，等到產品差不多穩定，並且產品在市場上有了一席之地之後，後續的事情就要考慮優化功能，對裡面的代碼或者產品的性能進行全方面的提升，目前國內大部分的互聯網一般比較年輕，還在解決有沒有的問題，相信隨著時間的推移以及國內軟體的發展，也會有大量的高質量的開源框架代碼出來，但這一切都需要很長的時間。
所以國內的程序員大部分時間都是在趕進度和根據需求完成功能代碼。
2.軟體產業的底子還很薄弱， 歷史 積淀還不夠
舉個很典型的例子，現在很多國內的程序員到了30多歲就開始考慮後續的轉型了，因為後面的輕輕人會帶來很大的沖擊，所以大部分的30多歲的程序員都在考慮自己後路，都要考慮轉型的問題。老的有經驗的程序員反而轉型去做管理或者合夥創業了，哪有幾個還在安心搞技術，年齡大了還在搞技術的還被人鄙視，覺得自己沒有出息。
但是在國外寫代碼是一種很常見的職業，和別的工種沒有多大的差異，40，50歲了寫代碼也是比比皆是，做軟體是一種技術工種，經驗的佔比是很高的，所以老程序員寫出來的代碼更加有深度，穩定性更高，一切的根源還是產業的發展不夠成熟，需要時間和 歷史 的積淀，從這方面講國內的軟體整體產業還是比較薄弱，從業人員的整體素質和工作氛圍還有待慢慢的成熟，周圍都是有經驗的程序員在帶領著如何去重構代碼，如何提升代碼的質量，而國內大部分的程序要還是被產品經理鞭策著增加需求和修改代碼。
3.公司的文化差異
目前很多的中國技術公司更多的追求的是短期利益的最大化，在基礎軟體的投入遠遠不夠，畢竟基礎的投入很難短期見成效，在一個具體的場景，有一個產品主體的功能已經實現了，也能在用戶那邊投入使用了，一般的公司很難拿出時間來，讓你做代碼的重構，畢竟這種事情很難直接產生經濟效益。這與公司本身的文化差異有很大的關系，重視的技術或者懂得技術的公司對於這方面相對比較重視，反之就差很多。
小時候課本上就說著我們落後100年，所以高樓大廈不是一天建成的，所以在追趕的道路很漫長，所以承認存在差距，然後努力加倍的去追趕。
Time is money. 以目前國內互聯網的情況，需求應接不暇，程序員基本上都是被需求與業務趕著走，時間非常緊張，在這種情況下，程序員很多時候唯一的選擇就是趕緊實現需求的功能。所以，一個項目下來，代碼基本上都變得非常非常的「垃圾」。
也有很多程序員想過在項目結尾的時候進行代碼的重構，基本上每個程序員也都知道重構代碼的好處，但是並不代表著真正能做起來。還是那個原因，國內互聯網的速度太快，需求應接不暇，做為程序員，基本上沒有時間來做這件事情。
而另外一個原因是跟團隊負責人有關。若團隊負責人能夠意識到重構的好處，那麼他可以為此單獨劃分一段開發時間出來，讓大家分別負責一個模塊進行重構，這都是可以安排做起來的。這也需要團隊負責人如何在需求人員的需求與代碼質量的進度上做一個平衡，進行統籌安排。
最後我想說一個可能很少意識到的原因，那就是人員流動問題。國內互聯網目前人員流動非常的大，尤其是北上深這樣的互聯網發達的城市，基本上是平均兩年就會走一大波人，在這樣的情況下，也會考驗從業人員的職業道德，即我到底要把代碼寫的多好，要把代碼的可維護性做到多好，其實這都是從業人員自身需要考驗的問題，因為完成一個功能很容易，但是要考慮的全面就是另外一回事了。而人員流動帶來的另一個問題就是有一些代碼是很難看懂的，即有些代碼在人員離開後成為了「 歷史 」，無人敢動。這也會阻礙著軟體的重構工作的進行。
從我所講的這幾種情況來看，重構其實是大家都能知道的好處，但是真正實施起來卻又有現實的約束，需要負責人來做這樣的統籌安排與推動。
成本太大
大多數軟體產品的開發都是經過了很多開發人員的付出，如果進行代碼重構需要了解產品、了解框架、了解代碼邏輯，這個過程會花費大量的時間和人力成本，對於企業來說，效益是第一位的，與其花費精力進行效益不大的產品重構，不如去承接更多的項目來的實在。
領導決策
由於大部分企業的老闆都是非技術人員出身，他們更關注效益和客戶，為了符合企業的發展，在進行產品開發時會更多的採用新技術來吸引客戶，花費精力重構代碼不如開發一套新產品或者開發更酷炫的效果更具有實在意義。
代碼規范不足
由於國內互聯網較之國外起步較晚，很多企業發展時間較短，加之人員流動比較大等多方面的因素，很難形成標准、嚴謹、行之有效的代碼規范，所以很多技術人員在開發時都是根據個人風格習慣在開發，等其他人接手代碼時，缺少相關標准和文檔，很難理解代碼邏輯，花時間去了解代碼、重構代碼不如直接推翻重做來的方便。
客戶定製化需求
部分企業創業初期對企業信息化是不夠重視的，只有企業發展到一定程度才會考慮信息化建設，而由於業務的限制，大多數標准化的互聯網產品都很難滿足企業的實際需求，需要進行大量定製化的開發，對於互聯網企業來說，即使產品開發足夠完善，在實際項目中也需要進行擴展，倒不如直接在項目中進行調整。
程序員的發展限定
在國內很少有終身的程序員，大部分都會逐漸轉向銷售、售前、項目經理、產品經理等崗位，而這些崗位則需要了解業務、了解客戶，對技術的需求反而不會太高，所以與其花時間去專研技術不如將更多的精力用在業務和項目層面。
代碼能夠重構對底層框架要求深度掌握、且代碼框架本身要足夠靈活，而國內絕大部分技術人員都是停留在對框架的使用層面、少數可以完善、結合使用，極個別的在做同語言山寨或者換一種語言重寫，能夠對產品體系進行把握、與時俱進擴展實在是鳳毛麟角。隨著國家的經濟提升、IT行業逐漸成熟，在我國這么多IT公司基數下，即便是鳳毛麟角的概率，重視基礎框架、積累萃取、不斷迭代完善的一些技術公司也會慢慢嶄露頭角、涌現出來的。
【國內程序員很少進行代碼重構】，這個現象雖然沒有什麼調查統計，不過我寫了十多年代碼，也發現身邊的程序員大多數是這樣的，【寧可寫新的代碼，也不願意重構老代碼】。下面我也談談自己的看法：
系統沒有問題，就是最大的功勞
我見過的大部分的傳統行業的軟體公司或IT部門是這樣的（互聯網公司不太了解），「只要系統穩定，那麼就是最大的功勞」，而保持系統穩定最好的方法是什麼？ 就是盡可能的不要動系統！
可能很多人不能理解，但很多公司確實是這樣，甚至公司對項目的考核標准中，項目有什麼突破的權重很低，是否有生產事故的權重很高。所以很多「機智」的項目組成員，千方百計的不接需求，或者把需求推給別的項目組。在這種單位裡面，別說重構了，新代碼都寫的不多。
測試覆蓋度太低，重構代碼沒辦法保證質量
代碼重構，很重要的一個問題：「重構後的代碼誰來保證？如果影響到原有的功能怎麼辦？」
這時候很有效的一個方法，是使用各種自動化的測試來保證重構代碼的質量。
但是，大部分公司，不管是單元測試還是其他的自動化測試，都是不健全的，甚至是沒有的。所以只要不是被逼不得已，程序員寧可重新寫一個方法，也不願意重構之前的代碼。
其他
進行代碼重構不是一件容易的事情，務必需要對需求熟悉；對代碼 歷史 變更熟悉；對代碼框架，模塊熟悉；對產品更新迭代做好風險把控，時間成本把控……
進行代碼重構需要能力非常高，責任心非常強的人進行，甚至需要一個優秀的團隊完成。
為什麼要代碼重構？理由一大堆，我認為主要有兩條，一是原代碼已不適合擴展新需求，二是原代碼已擁腫不堪，亂七八糟。
為什麼很少重構？除了上述分析外，還有其他因素，如人員流動快，原團隊原作者早已不知何去何從了。又如需求和業務繁多，完成工作開發都累得半死不活，日理萬機似的，哪有時間和心情重構？
謝謝大家。
1.國內程序員技術能力不足以進行代碼重構
大量的軟體從業人員連編程規范都不熟悉，怎麼可能做代碼重構？更多的人只會寫寫hello world，只會拷貝粘貼小段代碼，連if else這種語句都寫不清楚甚至漏掉邏輯，連面向對象的編程思想都沒有，談何重構？
2.國內程序員的溝通能力說服能力一般。
進行軟體重構，必須說服經理，讓經理相信重構會帶來軟體質量的提高和故障率的逐步降低，這樣經理才會安排人力進行重構。
3.國內軟體開發更注重bug的及時解決
國內軟體開發大量的人力被分配到解決短期的某個bug，沒人抽時間思考如何長久的徹底的解決軟體缺陷，其實解決bug不重要，找到軟體的缺陷或者性能低下的地方才重要，這些才是重構的點。國內加班加點疲於奔命式的開發，沒人考慮bug率是否長期內能夠收斂，總是先解決眼前的問題再說，處於一個永遠解決bug的死循環里。
這種工作模式是愚蠢的，不是smart的。
軟體開發，一定要動腦子，不要蠻干，這不是耕地，力氣大就耕的多。
重構代碼的目的說白了，就是讓軟體開發人員更自由。
謝謝樓主的問題，這是一個我特別想回答的問題？
為什麼？因為，第一，我是一個對代碼有潔癖的人，受不了一坨，一坨那樣的代碼。第二，我是一個踐行Clean Code 的人，給大家我主要負責的一個項目的一組數據（JAVA），總代碼量20萬行,UT coverage(單元測試代碼覆蓋率）82%，代碼重復率0.5%，代碼規則(sonar）違反（Code issue）0,甚至連最低的違反都沒有。
也正是因為我的項目在實踐Clean Code上的數據，我經常去給不同的團隊做分享，也對團隊對這個重構不太上心有一些理解。
大致以下幾個原因。
第一，也是最多的，交付壓力，大部分人都會抱怨，你看我們有這么多新功能，還有那麼多bug,根本忙不過來，哪有時間重構？
第二，重構意識不足，老闆，管理人員總是希望這個我們要有，那個我們也要實現？為什麼？因為別人有，別人有我們沒有可能會造成用戶流逝。即使有一些有見識的程序員和老闆反應這個重構問題，但是重構從來不是高優先順序的。畢竟，現在的軟體的生命周期可能很短。
第三，人員流動性大，這個是我聽過最奇葩的一個理由，我問一個來聽培訓的哥們，說你代碼寫成這樣，以後怎麼維護？這個哥們說，我也知道難維護，但我明年就跳槽了。
第四，設計上就不需要重構，曾經給一個保險公司做分享，我本人也是做金融相關產品後台的，我就問你們這樣寫代碼，可能三四年以後就非常難維護了，還是要盡快重構。他們的回答是，我們不重構，我們只重寫。什麼意思那？就是一個系統，三四年以後在寫一遍。
第五，程序員本身的問題，可能第一寫單元測試，修改命名，修改代碼結構，是一件很沒有成就感的事情，也是一個沒有多少附加值的事情。畢竟現在你去找工作，這個代碼質量方面的問題會問得很少。
第六，我見過的我不能反駁的一個回答，我的英文太差，不能很好的命名，而我也不想學英文。
第七，反正我已經實現了功能。
最後，用一句話來提醒程序員們，重構是多麼重要。
出來混遲早要還的，挖了坑遲早要填的。
在國內，【重構】這件事是程序員最喜歡做的事，而不是公司喜歡做的事。
但程序員喜歡並不能影響公司的決策，所以，國內的現象就是軟體系統很少有重構。
其根本的原因在於，國內的公司所推出的系統大多沒有重構的價值。
1、國內的互聯網公司存在這樣一種快節奏，那就是發現一個有價值的創意，就馬上進入開發，開發完成立即上線，並立馬推廣使用。這是一種快速試錯的模式，一旦發現系統在 社會 中沒有引起反響，那就馬上把系統再下線。這種情況下的系統哪來的重構價值呢？
2、即使一個系統上線成功了，也積累了大量的用戶，貌似為了系統的穩定性和性能，可以有重構的機會。但事實上不是，國內公司仍舊不會選擇重構，因為重構帶不來新的價值。所以，公司多數都會在系統上添加新的功能來吸引新的客戶，而不會考慮重構現有系統。
總得來說，引起重構的原因在於能夠有持續的價值。沒有價值的事，企業當然不會做，僅是程序員的一廂情願而已。
你只是見到了你所在的公司現象，不代表所有，也不能代表大部分的。
代碼重構還是存在的現象
代碼設計爛，經常出問題、擴展麻煩、維護心累、數據混亂、結果不清醒、模塊劃分混亂
就可能要考慮到重構了
呵呵，
老大說：
你趕緊去修復一下這個bug，
還有幾個功能沒有實現，加班搞一下，
pm 說：
這個功能改一下，
還有這個，界面重新調整一下，
這個業務流，現在不一樣了，
客戶需求需要多幾個功能，
老闆說：
這東西下周能出來嗎？
⑶ 如何重構代碼
先從接觸過的幾個老項目經歷來談談，對於老項目來說，大家在初步接觸的過程中，大多總是抱著抵觸的情緒，甚至有些是蔑視。總喜歡對以前的代碼挑出一大堆的問題，接著就開始抱怨代碼、抱怨以前的開發人員，經過一段時間郁悶的抱怨階段後，處於職業的責任心，就很想去改變這一切，希望把自己認為好的方式給帶進來，於是接下來的工作就是重構代碼了。 這也許大多數開發人員都經歷過，這種經歷是辛酸的（因為重構工作雖然重要，但是得不到過多的認可，目前國內關注的是可用性，對於代碼質量並沒有得到應有的重視），也是甜蜜的（風雨之後總會有彩虹）。對於年輕的開發人員來說，見到彩虹的過程是痛苦、漫長地。他們都是在失敗中成長，這些失敗除了經驗外，主要是由於太急功盡力了，盲目的重構！ 盲目主要體現在： 1、在還沒有對系統整體架構有個清晰認識的時候，就想用自認為新的技術或架構來替換。 2、根本不分析現有系統架構或程序存在的弊端，只是一味地談設計模式，以設計模式中固有的一套來重構（在重構中，它只作為一個參考，而不是一個依據。） 3、重構比較隨性，每個版本的開發都跳出架構之外隨意帶入新的設計思想 這種盲目重構後給系統會帶來更多問題： 你會發現當你重構完後你的系統運行效率變低了， 系統中同時存在多種思想，新加入人員更難接手， 由於你沒有完全了解系統，反而在你的重構當中帶來了很多重復代碼， 最悲劇的是你重構後的代碼也被其他人當成垃圾，而進行重構。 那麼我們怎麼消除盲目呢！？ 首先，了解目前項目是否存在問題，存在什麼問題，這些問題是否能通過重構來解決，如果能，才進行重構，你的重構時間是需要公司給的，老闆不會因為你說依賴性強偶合性低就同意的，你必須要通過問題來讓他認識，關鍵的是只有通過問題才能得到重構時間和資源，並且你的工作才能得到認可，這是一個很現實的情況。 接下來，你要確定重構的對象，是針對架構還是局部代碼，並且去設定一個理想的目標（為什麼是理想的？因為我們不可能一步到位，理想和現實是有差距的，但是我們要做的是盡力去往理想上靠攏）。 如果是針對架構進行重構，那麼這可不是一件輕松的事情，再真正開始之前需要做到以下幾點： 1、全面的了解系統的過去，包括以前的架構/技術背景、業務需求 2、分析以前架構的問題，例如：可維護性低、在哪個方面已經不滿足現有需求等等 3、查看至少80%的核心代碼，最好有一定時間的真實在以前代碼基礎上編碼的經歷 做到上面幾點就是為了保證你能有一個清晰的認識，做到知己知彼。接下來可以進入實質階段了嗎？不行，還少了一個很重要的東西，重構計劃！ 這種大范圍的重構，在真實情況下，一般老闆給予的時間和重構真正所需用的時間相差很大，所以重構的工作是需要往後延遲的，那麼就會出現又要重構又要進行新需求的開發；還有這項工作不是一個人的事情，是一個團對，既然涉及到多人合作，除了共同的目標外，還需要有一定的評審機制，這是為了保證重構的方向一致，等等，在這些因素下要做好重構，就是需要重構計劃的理由。 針對局部代碼進行重構來說，也許會簡單的許多，不過需要注意的地方是，你一定要符合現有架構的思想，在它的范圍之內去思考。 其實這種方式的重構大多就是提取方法，或者是以真實業務流程的思路去重構現有的代碼執行流程，以便易於理解，或者是降低程序之間的依賴性。要做到這些有個很重要的思維方式： 1、善於從某個事物中分析出什麼是事物的本質和什麼是事物的外部環境。 2、從很多不同事物中去發現共同點，並對這些共同點進行抽象化（舉個簡單的例子：對於寶馬和奧迪，你應該把他們抽象化為汽車）。 為什麼這樣說，因為這些能帶來重構代碼所需要的： 1、在寫代碼過程中降低了依賴性， 2、抽象化的事物復用性更強 做好上述的所有就表示重構完成了嗎！不可能，這只是一個好的開始而已，我們要做到持續重構，就像敏捷中提到的。 也許有的人認為不現實，因為項目經理不會在每個版本周期內給出這個時間，其實，我就納悶了，為什麼不給？！不給的原因一定在你，如果你期望是一周或者更久，那麼誰都不會同意，一周的時間都基本都能做完一個版本的設計了，重構還需要這么久，如果真的需要就說明你前期的設計很差！我所希望的時間是兩天左右，因為這只局限於很小范圍內的變動。 如果你們很好的做這些，那麼你的項目可維護性一定很好，並且加入你的項目會是一件愉快的事情，這並不是什麼理想的事情，只要你持之以恆地去做，實現起來其實很簡單。 架構重構：1、重構計劃代碼重構：2、提取獲取交集的演算法3、簡單、靈活地實現對象復制
⑷ 什麼是代碼重構
代碼重構（英語：Code refactoring）重構就是在不改變軟體系統外部行為的前提下，改善它的內部結構。
軟體重構需要藉助工具完成，重構工具能夠修改代碼同時修改所有引用該代碼的地方。在極限編程的方法學中，重構需要單元測試來支持。
java重構：指程序員對已有程序在盡量不改變介面的前提下，進行重新編寫代碼的工作，一般有以下幾方面：
1、去除已知bug。
2、提高程序運行效率。
3、增加新的功能。
重構舉例：（簡化代碼、提升效率）
重構前：
if(list!=null&&list.size()>0){
for(inti=0;i<list.size();i++){
//skip...
}
}重構後
if(list!=null){
for(inti=0,len=list.size();i<len;i++){
//skip...
}
}
何時著手重構（Refactoring）
新官上任三把火，開始一個全新??、腳不停蹄、加班加點，一支聲勢浩大的千軍萬"碼"夾裹著程序員激情和扣擊鍵盤的鳴金奮力前行，勢如破竹，攻城掠地，直指"黃龍府"。
開發經理是這支浩浩湯湯代碼隊伍的統帥，他負責這支隊伍的命運，當齊桓公站在山頂上看到管仲訓練的隊伍整齊劃一地前進時，他感嘆說"我有這樣一支軍隊哪裡還怕沒有勝利呢？"。但很遺憾，你手中的這支隊伍原本只是散兵游勇，在前進中招兵買馬，不斷壯大，所以隊伍變形在所難免。當開發經理發覺隊伍變形時，也許就是克制住攻克前方山頭的誘惑，停下腳步整頓隊伍的時候了。
Kent Beck提出了"代碼壞味道"的說法，和我們所提出的"隊伍變形"是同樣的意思，隊伍變形的信號是什麼呢？以下列述的代碼症狀就是"隊伍變形"的強烈信號：
·代碼中存在重復的代碼
中國有118 家整車生產企業，數量幾乎等於美、日、歐所有汽車廠家數之和，但是全國的年產量卻不及一個外國大汽車公司的產量。重復建設只會導致效率的低效和資源的浪費。
程序代碼更是不能搞重復建設，如果同一個類中有相同的代碼塊，請把它提煉成類的一個獨立方法，如果不同類中具有相同的代碼，請把它提煉成一個新類，永遠不要重復代碼。
·過大的類和過長的方法
過大的類往往是類抽象不合理的結果，類抽象不合理將降低了代碼的復用率。方法是類王國中的諸侯國，諸侯國太大勢必動搖中央集權。過長的方法由於包含的邏輯過於復雜，錯誤機率將直線上升，而可讀性則直線下降，類的健壯性很容易被打破。當看到一個過長的方法時，需要想辦法將其劃分為多個小方法，以便於分而治之。
·牽一毛而需要動全身的修改
當你發現修改一個小功能，或增加一個小功能時，就引發一次代碼地震，也許是你的設計抽象度不夠理想，功能代碼太過分散所引起的。
·類之間需要過多的通訊
A類需要調用B類的過多方法訪問B的內部數據，在關繫上這兩個類顯得有點狎昵，可能這兩個類本應該在一起，而不應該分家。
·過度耦合的信息鏈
"計算機是這樣一門科學，它相信可以通過添加一個中間層解決任何問題"，所以往往中間層會被過多地追加到程序中。如果你在代碼中看到需要獲取一個信息，需要一個類的方法調用另一個類的方法，層層掛接，就象輸油管一樣節節相連。這往往是因為銜接層太多造成的，需要查看就否有可移除的中間層，或是否可以提供更直接的調用方法。
·各立山頭幹革命
如果你發現有兩個類或兩個方法雖然命名不同但卻擁有相似或相同的功能，你會發現往往是因為開發團隊協調不夠造成的。筆者曾經寫了一個頗好用的字元串處理類，但因為沒有及時通告團隊其他人員，後來發現項目中居然有三個字元串處理類。革命資源是珍貴的，我們不應各立山頭幹革命。
·不完美的設計
在筆者剛完成的一個比對報警項目中，曾安排阿朱開發報警模塊，即通過Socket向指定的簡訊平台、語音平台及客戶端報警器插件發送報警報文信息，阿朱出色地完成了這項任務。後來用戶又提出了實時比對的需求，即要求第三方系統以報文形式向比對報警系統發送請求，比對報警系統接收並響應這個請求。這又需要用到Socket報文通訊，由於原來的設計沒有將報文通訊模塊獨立出來，所以無法復用阿朱開發的代碼。後來我及時調整了這個設計，新增了一個報文收發模塊，使系統所有的對外通訊都復用這個模塊，系統的整體設計也顯得更加合理。
每個系統都或多或少存在不完美的設計，剛開始可能注意不到，到後來才會慢慢凸顯出來，此時唯有勇於更改才是最好的出路。
·缺少必要的注釋
雖然許多軟體工程的書籍常提醒程序員需要防止過多注釋，但這個擔心好象並沒有什麼必要。往往程序員更感興趣的是功能實現而非代碼注釋，因為前者更能帶來成就感，所以代碼注釋往往不是過多而是過少，過於簡單。人的記憶曲線下降的坡度是陡得嚇人的，當過了一段時間後再回頭補注釋時，很容易發生"提筆忘字，愈言且止"的情形。
曾在網上看到過微軟的代碼注釋，其詳盡程度讓人嘆為觀止，也從中體悟到了微軟成功的一個經驗。