因?yàn)楣ぷ鲀?nèi)容的原因，我在前后兩家公司中的工作中主持和經(jīng)歷了十余次代碼和架構(gòu)的重構(gòu)，下面隨便說(shuō)說(shuō)我對(duì)重構(gòu)的一些經(jīng)驗(yàn)和想法。

關(guān)于重構(gòu)

首先重構(gòu)面臨的背景都是相似的，程序員們?yōu)榱丝焖偻瓿尚枨蠛蜕暇€而寫出了最基本的代碼，而在功能的不斷擴(kuò)充過(guò)程中，以打補(bǔ)丁的方式對(duì)代碼進(jìn)行擴(kuò)充，中間還會(huì)面臨著開發(fā)人員的變更和離職。逐漸的，代碼就會(huì)越來(lái)越臃腫，漸漸的變得難以維護(hù)。

糟糕的架構(gòu)會(huì)有什么樣的影響？首先是開發(fā)效率的降低，在糟糕架構(gòu)下加進(jìn)新功能，會(huì)受之前代碼的影響，可能存在意想不到的改動(dòng)點(diǎn)和問(wèn)題點(diǎn)，開發(fā)和調(diào)試時(shí)間都會(huì)大大增加；其次是故障率的提升，在質(zhì)量低下的代碼中，總是容易藏著很多不易發(fā)現(xiàn)的坑，這些都會(huì)成為故障的隱患；同時(shí)，架構(gòu)也會(huì)使得需求的完成大打折扣，使得設(shè)計(jì)好的目標(biāo)，因?yàn)榧軜?gòu)限制或者性能等原因，只能完成80%甚至更低。

重構(gòu)要解決的問(wèn)題

重構(gòu)不能憑空重構(gòu)，一定是要解決一個(gè)問(wèn)題，一般情況下重構(gòu)要解決的問(wèn)題大致有以下幾種：

·結(jié)構(gòu)糟糕。相信很多碼農(nóng)們，都遇到過(guò)接手別人的代碼后都感到撓頭的事情，五千行以上的文件，三千行以上的函數(shù)，面對(duì)這樣子的代碼，對(duì)其進(jìn)行修改和繼續(xù)開發(fā)是件很艱難的事情。

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

·性能問(wèn)題。對(duì)于很多大型服務(wù)，性能高一點(diǎn)可以節(jié)省很多的服務(wù)器費(fèi)用。性能問(wèn)題主要需要找到核心問(wèn)題，有的問(wèn)題出在架構(gòu)，而大多出代碼上。

·功能擴(kuò)展。有的模塊，開始設(shè)計(jì)時(shí)只是實(shí)現(xiàn)一些很基本的功能，而隨著產(chǎn)品功能不斷增強(qiáng)，被賦予了越來(lái)越復(fù)雜的功能，到了一定程度，需要進(jìn)行重構(gòu)以讓其能夠?qū)崿F(xiàn)新賦予的任務(wù)。

·協(xié)同開發(fā)。很多時(shí)候，一個(gè)大系統(tǒng)往往需要多個(gè)人一起進(jìn)行開發(fā)，如果需要這些人改同一個(gè)類甚至同一個(gè)函數(shù)，往往是沖突不斷，而代碼的整合往往也會(huì)存在更多問(wèn)題。這時(shí)候需要很好的架構(gòu)能夠支持多人的共同開發(fā)和修改。

·模塊調(diào)試。在一個(gè)大系統(tǒng)中，往往有很多子模塊互相關(guān)聯(lián)，而假如某個(gè)模塊的調(diào)試需要啟動(dòng)整個(gè)大系統(tǒng)，或者會(huì)受到其他模塊穩(wěn)定性的影響，對(duì)于效率是非常低的。而重構(gòu)建立調(diào)試層或者開發(fā)調(diào)試工具是更好的選擇。

·模塊復(fù)用。有些時(shí)候，多個(gè)系統(tǒng)或算法，可能會(huì)用到子算法和子模塊，而不同項(xiàng)目或模塊重復(fù)開發(fā)相同功能的子模塊，在很多公司都很常見。而很多時(shí)候，將一些公共的部分抽象出來(lái)，能夠?qū)⑦@部分做的更好更精，而從整體上，往往能大幅度提高開發(fā)效率和效果，往往也能優(yōu)化算法性能。

·算法使用不當(dāng)。在有些模塊中，使用了不恰當(dāng)?shù)臄?shù)據(jù)結(jié)構(gòu)或者相關(guān)算法，使得或者是性能，或者是效果出現(xiàn)了問(wèn)題。這種情況，甚至要將原有的體系結(jié)構(gòu)推到重來(lái)，重新設(shè)計(jì)算法和數(shù)據(jù)結(jié)構(gòu)，達(dá)到盡可能好的匹配效果。

·承載規(guī)模不夠。對(duì)于一些系統(tǒng)，都有其設(shè)計(jì)的容納規(guī)模，例如瞬間訪問(wèn)量、同時(shí)在線人數(shù)，很多公司從小到大都經(jīng)歷過(guò)這個(gè)過(guò)城，當(dāng)超過(guò)一定量級(jí)時(shí)，很多時(shí)候并非簡(jiǎn)單通過(guò)加服務(wù)器能解決，有時(shí)需要重新設(shè)計(jì)架構(gòu)。就像12306，因?yàn)榧軜?gòu)問(wèn)題使得很難承擔(dān)過(guò)高的瞬時(shí)在線人數(shù)。

重構(gòu)經(jīng)驗(yàn)感受

重構(gòu)時(shí)，第一道難關(guān)是如何過(guò)領(lǐng)導(dǎo)這道關(guān)。很多領(lǐng)導(dǎo)都要背著產(chǎn)品指標(biāo)和任務(wù)，大多人也更關(guān)心其能夠在多長(zhǎng)時(shí)間做出什么，重構(gòu)這種事情，在很多時(shí)候，有可能是“費(fèi)力不討好”的代名詞，因?yàn)樵诖蠖嗲闆r，無(wú)法幫助領(lǐng)導(dǎo)完成指標(biāo)。這種情況下，如何獲得領(lǐng)導(dǎo)的支持就極其重要了。

對(duì)于重構(gòu)，一種方法是，讓重構(gòu)與某些技術(shù)或產(chǎn)品指標(biāo)掛鉤，例如完成新產(chǎn)品、改進(jìn)效果、提高性能等，相當(dāng)于是重構(gòu)伴隨著其他改進(jìn)搭幫上線，那么這種情況可以比較順利的完成重構(gòu)。

而如果單純的為了架構(gòu)的合理性而去重構(gòu)的話，就需要去說(shuō)服領(lǐng)導(dǎo)，為什么原來(lái)的架構(gòu)會(huì)降低開發(fā)效率，新做的架構(gòu)能帶來(lái)哪方面的提升。一定要讓領(lǐng)導(dǎo)明白，這個(gè)能帶來(lái)實(shí)實(shí)在在的長(zhǎng)期收益，不管性能、效率、安全等都可以，而并非只是“看著不爽”而進(jìn)行的重構(gòu)。

如果團(tuán)隊(duì)規(guī)模有一定的人的話，也可以分出一部分進(jìn)行新型架構(gòu)的開發(fā)，而另一部分人在現(xiàn)有架構(gòu)上進(jìn)行改進(jìn)，使得短期目標(biāo)和長(zhǎng)期目標(biāo)兩不耽誤。這時(shí)候，值得注意的就是，不管從代碼還是設(shè)計(jì)角度上來(lái)看，都要讓現(xiàn)有做的事情能夠復(fù)用，而不是新架構(gòu)上線之后就會(huì)被廢掉。

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

不管怎樣，重構(gòu)，一定不能是為了重構(gòu)而重構(gòu)，或者對(duì)前人的代碼看著不爽，或者抱有技術(shù)完美主義而進(jìn)行重構(gòu)，最重要是找準(zhǔn)其要解決的實(shí)際問(wèn)題，這時(shí)候的重構(gòu)，能帶來(lái)的是開發(fā)效率上的提升。

而在重構(gòu)的過(guò)程中，也需要做好新架構(gòu)的設(shè)計(jì)，并且擁有一定的前瞻性，否則很容易出現(xiàn)新架構(gòu)、新新架構(gòu)、新新新架構(gòu)這樣子的事情。另外，也要盡可能的增強(qiáng)代碼的復(fù)用性，讓其中的模塊，在任何一個(gè)架構(gòu)中都能夠很好的被應(yīng)用，當(dāng)然這個(gè)要根據(jù)具體情況具體分析。

對(duì)于重構(gòu)，也盡量不要擁有技術(shù)完美主義。很多時(shí)候，使用最成熟的方案及最簡(jiǎn)單的架構(gòu)模型實(shí)現(xiàn)所需要的功能一般來(lái)說(shuō)更加“簡(jiǎn)單可依賴”，有的時(shí)候架構(gòu)過(guò)于復(fù)雜反而喧賓奪主，因?yàn)樗屑軜?gòu)都是為了功能服務(wù)的。同時(shí)，也盡量不要使用很多未經(jīng)廣泛使用的前沿技術(shù)，因?yàn)檫@些在開發(fā)和部署過(guò)程中，很多都可能會(huì)遇到意想不到的問(wèn)題，延緩開發(fā)速度并影響線上效果。

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

良好的習(xí)慣，從最初做起

當(dāng)然，重構(gòu)再怎么樣，也是一種推翻重做，耽誤時(shí)間的做法。從我的經(jīng)驗(yàn)來(lái)看，其實(shí)大多數(shù)的重構(gòu)都是可以避免的，這需要從以下幾個(gè)方面去提高。

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

初期的架構(gòu)設(shè)計(jì)，這個(gè)也是非常重要的。架構(gòu)設(shè)計(jì)能不能一次到位，這個(gè)不太好說(shuō)。但是相信好的架構(gòu)，一定比粗糙的設(shè)計(jì)能夠堅(jiān)持更長(zhǎng)得多的時(shí)間。并且好架構(gòu)可以考慮到未來(lái)可能擴(kuò)充的規(guī)模和功能，為未來(lái)的發(fā)展留好接口。同時(shí)在其中所有的模塊都非常有序，即使大的框架要修改的話，也只是搭一個(gè)架子，原有的子功能和子模塊都能夠被很好的復(fù)用。

其實(shí)很多時(shí)候，代碼并非要開發(fā)一陣就重構(gòu)一次，而寫出好的架構(gòu)，也并非是那么難。更重要的是，需要的是不斷的提高程序員的自我修養(yǎng)，不僅僅是能力上的，還有態(tài)度上的。不要只想最初開發(fā)時(shí)省事，而不考慮若干時(shí)間后的事情。好的架構(gòu)，對(duì)未來(lái)的開發(fā)以及發(fā)展，可以說(shuō)是真真實(shí)實(shí)的“事半功倍”。

最后，我們看一個(gè)關(guān)于扁鵲的故事：

扁鵲實(shí)際上就是一個(gè)很好的重構(gòu)高手，但是扁鵲的大哥，就是因?yàn)槟軌驅(qū)?wèn)題看在前面，處理在前面，所以能夠永葆健康，這更是高手中的高手！

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