他們總在說重構，不過是重寫

　　大約是工作三年后，職業倦怠毫無征兆的襲擊了我，我莫名的感到：這一輩子就這樣了，每天的工作就是寫相同的代碼，要命的是，自己在一個領域越精通，別人就越希望自己寫同樣的模塊——再快一點。使我渡過這段時光的，是一些編程行業的老書，對于一個原本追求時髦技術的程序員來說，這樣的反轉令自己也很驚訝，其中就有這本《重構》，多年后，再次捧讀，希望自己如《黑客帝國》里的neo，回到源碼，去理解為何重構即不是傳說中的銀彈，卻又如此重要。本篇為第一部分，先來說說看待重構的三心。

　　回到源碼

　　拋掉對重構的敬畏之心

　　1. 重構給出了具體的操作方法。

　　重構不是建立在空中的構建思想，而是從實踐中歸納出來的操作手冊。比如書中提到的要點之一：

　　事不過三，三要重構。

　　這條規則給出了重構時機的具體判斷方法：一個值，一段代碼，相同的功能，如果重復出現了 兩次以上，就要提取為宏，變量，方法，或模塊，以方便重用。這不是建議，從代碼質量來說，這是要求，也是開發者從小工到專家的必由之路，事實上，除此之外，我不知道還有別的編寫代碼的方法。

　　2. 重構早已在開發者身邊。

　　幾乎所有開發工具(Eclipse、Xcode...)都內置重構工具，他們的使用與代碼編輯器一樣簡單。

　　如果你是一名iOS開發者，請參閱Xcode8 五分鐘重構起步

　　要對重構有耐心

　　由于重構不改變程序的外在表現，換而言之，即沒有加入任何新功能，因此項目經理和老板不會主動要求開發者重構，甚至開發者提出時，會招來反對：這個項目還剩一個星期，還有N個需求未實現，現在你請求花費兩天時間，什么都不做。開發者幾乎都承擔不了這樣的壓力，但是，比延誤工期更嚴重的是，一個臃腫的，不易修改的項目，最終將面臨添加需求困難，運行效率低下，以致達不到可用的性能，項目被砍掉，失敗幾乎不可避免。

　　那么作為開發者，應該怎么處理這個矛盾呢?一個可行的方法是，把重構當做開發的一部分，一邊開發一邊重構，先快速的堆疊代碼，實現功能，然后在功能不變的基礎上(寫好單元測試)，逐步重構。

　　庖丁解牛

　　對于吹噓重構有戒心

　　不要對別人吹噓重構

　　重構是一系列技法，就如一個優秀木匠不會吹噓自己的刀法一樣，他表現自己的，永遠是作品，開發者的作品就是程序，可擴展，少改動，高效，穩健的程序，如果團隊里有人說：我現在不重構就沒法寫代碼。大概他就真的只是不會寫代碼而已。

　　本人面試過一些剛畢業的開發者，在最后的提問環節，他提出的問題是：你們用什么開發環境?接著他還進一步強調自己一定要使用Source Insight (一種Windows平臺流行的開發集成環境，基于代碼語義管理代碼)，否則就無法寫代碼。當時我有點錯愕，面對了解公司環境的寶貴機會，不問福利待遇，不問升職通道，卻糾結一個開發工具。后來我發現，很多初學者(也包括我自己)對工具有種癡迷，這當然也不是壞事，但對自己用的開發工具夸夸其談，只能說明開發者的眼界不夠開闊，水平有局限。

　　木匠不會夸自己錘子好使

　　當聽到有人將重構奉為靈丹妙藥，要格外小心，對此保持警惕。

　　有的技術領導人，動不動就說“下面我們進入重構階段了”，仔細觀察發現：每每他提出的時機，都是項目無法按時完成，某些功能實現不了時，公司領導還無法反駁，懂點技術的都明白重構的重要性。

　　忽悠

　　那么，如何鑒別這種拿重構“忽悠”的行為呢?可以從以下幾點：

原文轉自：http://www.jianshu.com/p/bce0fe294655