因為工作內容的原因，我在前后兩家公司中的工作中主持和經歷了十余次代碼和架構的重構，下面隨便說說我對重構的一些經驗和想法。

關于重構

首先重構面臨的背景都是相似的，程序員們為了快速完成需求和上線而寫出了最基本的代碼，而在功能的不斷擴充過程中，以打補丁的方式對代碼進行擴充，中間還會面臨著開發人員的變更和離職。逐漸的，代碼就會越來越臃腫，漸漸的變得難以維護。

糟糕的架構會有什么樣的影響？首先是開發效率的降低，在糟糕架構下加進新功能，會受之前代碼的影響，可能存在意想不到的改動點和問題點，開發和調試時間都會大大增加；其次是故障率的提升，在質量低下的代碼中，總是容易藏著很多不易發現的坑，這些都會成為故障的隱患；同時，架構也會使得需求的完成大打折扣，使得設計好的目標，因為架構限制或者性能等原因，只能完成80%甚至更低。

重構要解決的問題

重構不能憑空重構，一定是要解決一個問題，一般情況下重構要解決的問題大致有以下幾種：

·結構糟糕。相信很多碼農們，都遇到過接手別人的代碼后都感到撓頭的事情，五千行以上的文件，三千行以上的函數，面對這樣子的代碼，對其進行修改和繼續開發是件很艱難的事情。

·安全隱患。很多代碼，都只是為了功能上快速完成，而對很多潛在的安全風險置之不管，如內存管理、異常處理、模塊接口等。有的雷如果不掃，可能遲早有一天會爆發。

·性能問題。對于很多大型服務，性能高一點可以節省很多的服務器費用。性能問題主要需要找到核心問題，有的問題出在架構，而大多出代碼上。

·功能擴展。有的模塊，開始設計時只是實現一些很基本的功能，而隨著產品功能不斷增強，被賦予了越來越復雜的功能，到了一定程度，需要進行重構以讓其能夠實現新賦予的任務。

·協同開發。很多時候，一個大系統往往需要多個人一起進行開發，如果需要這些人改同一個類甚至同一個函數，往往是沖突不斷，而代碼的整合往往也會存在更多問題。這時候需要很好的架構能夠支持多人的共同開發和修改。

·模塊調試。在一個大系統中，往往有很多子模塊互相關聯，而假如某個模塊的調試需要啟動整個大系統，或者會受到其他模塊穩定性的影響，對于效率是非常低的。而重構建立調試層或者開發調試工具是更好的選擇。

·模塊復用。有些時候，多個系統或算法，可能會用到子算法和子模塊，而不同項目或模塊重復開發相同功能的子模塊，在很多公司都很常見。而很多時候，將一些公共的部分抽象出來，能夠將這部分做的更好更精，而從整體上，往往能大幅度提高開發效率和效果，往往也能優化算法性能。

·算法使用不當。在有些模塊中，使用了不恰當的數據結構或者相關算法，使得或者是性能，或者是效果出現了問題。這種情況，甚至要將原有的體系結構推到重來，重新設計算法和數據結構，達到盡可能好的匹配效果。

·承載規模不夠。對于一些系統，都有其設計的容納規模，例如瞬間訪問量、同時在線人數，很多公司從小到大都經歷過這個過城，當超過一定量級時，很多時候并非簡單通過加服務器能解決，有時需要重新設計架構。就像12306，因為架構問題使得很難承擔過高的瞬時在線人數。

重構經驗感受

重構時，第一道難關是如何過領導這道關。很多領導都要背著產品指標和任務，大多人也更關心其能夠在多長時間做出什么，重構這種事情，在很多時候，有可能是“費力不討好”的代名詞，因為在大多情況，無法幫助領導完成指標。這種情況下，如何獲得領導的支持就極其重要了。

對于重構，一種方法是，讓重構與某些技術或產品指標掛鉤，例如完成新產品、改進效果、提高性能等，相當于是重構伴隨著其他改進搭幫上線，那么這種情況可以比較順利的完成重構。

而如果單純的為了架構的合理性而去重構的話，就需要去說服領導，為什么原來的架構會降低開發效率，新做的架構能帶來哪方面的提升。一定要讓領導明白，這個能帶來實實在在的長期收益，不管性能、效率、安全等都可以，而并非只是“看著不爽”而進行的重構。

如果團隊規模有一定的人的話，也可以分出一部分進行新型架構的開發，而另一部分人在現有架構上進行改進，使得短期目標和長期目標兩不耽誤。這時候，值得注意的就是，不管從代碼還是設計角度上來看，都要讓現有做的事情能夠復用，而不是新架構上線之后就會被廢掉。

如何進行漸進式重構，也是很多架構師需要去思考的問題。就是不搞一下子半年一年的重構，而是以月為單位，快速的迭代，能夠很快的看到效果，并且小規模投入使用。

不管怎樣，重構，一定不能是為了重構而重構，或者對前人的代碼看著不爽，或者抱有技術完美主義而進行重構，最重要是找準其要解決的實際問題，這時候的重構，能帶來的是開發效率上的提升。

而在重構的過程中，也需要做好新架構的設計，并且擁有一定的前瞻性，否則很容易出現新架構、新新架構、新新新架構這樣子的事情。另外，也要盡可能的增強代碼的復用性，讓其中的模塊，在任何一個架構中都能夠很好的被應用，當然這個要根據具體情況具體分析。

對于重構，也盡量不要擁有技術完美主義。很多時候，使用最成熟的方案及最簡單的架構模型實現所需要的功能一般來說更加“簡單可依賴”，有的時候架構過于復雜反而喧賓奪主，因為所有架構都是為了功能服務的。同時，也盡量不要使用很多未經廣泛使用的前沿技術，因為這些在開發和部署過程中，很多都可能會遇到意想不到的問題，延緩開發速度并影響線上效果。

此外，作為重構時的負責人，一定要緊跟代碼開發的過程，并隨時進行指導，一般情況下，不要相信寫出糟糕代碼的人，經過略加指導就能寫出漂亮代碼了。我曾經有過這樣的經歷，要將一個超大的類按照功能進行模塊化拆分，設計好了架構及每個子模塊就讓組員進行開發。開發完了我看代碼時登時就抓狂了，模塊是拆分了，每個功能也都建立好了子類，并通過主類調用子類，但是每個子類又都將主類作為友元，又去調用主類里面的成員變量和函數。這種代碼，再次重構也是難免的，這個給我的經驗教訓就是，重構的工作一定要做細，迭代中的代碼檢查也是必不可少的。

良好的習慣，從最初做起

當然，重構再怎么樣，也是一種推翻重做，耽誤時間的做法。從我的經驗來看，其實大多數的重構都是可以避免的，這需要從以下幾個方面去提高。

良好的編碼風格，好的習慣往往很難是天然形成的，更多是在工作中不斷的老帶新中耳濡目染練出來的。很多領導希望員工全部時間都用來做項目，不斷地去壓更多的活，實際上是在用跑短跑的方式跑長跑，很容易出現后勁不足的情況。而我在微軟的經歷，也讓自己感受到了從潮手到逐漸成熟的過程，后來在搜狗時即使再忙沒法搞team review，我也會去盡量給每個組員檢查他們的代碼，幫助別人去提高。

初期的架構設計，這個也是非常重要的。架構設計能不能一次到位，這個不太好說。但是相信好的架構，一定比粗糙的設計能夠堅持更長得多的時間。并且好架構可以考慮到未來可能擴充的規模和功能，為未來的發展留好接口。同時在其中所有的模塊都非常有序，即使大的框架要修改的話，也只是搭一個架子，原有的子功能和子模塊都能夠被很好的復用。

其實很多時候，代碼并非要開發一陣就重構一次，而寫出好的架構，也并非是那么難。更重要的是，需要的是不斷的提高程序員的自我修養，不僅僅是能力上的，還有態度上的。不要只想最初開發時省事，而不考慮若干時間后的事情。好的架構，對未來的開發以及發展，可以說是真真實實的“事半功倍”。

最后，我們看一個關于扁鵲的故事：

扁鵲實際上就是一個很好的重構高手，但是扁鵲的大哥，就是因為能夠將問題看在前面，處理在前面，所以能夠永葆健康，這更是高手中的高手！

原文鏈接：http://blog.sina.com.cn/s/blog_6592c40501018e9y.html