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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

對于重構(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)的話，就需要去說服領(lǐng)導(dǎo)，為什么原來的架構(gòu)會降低開發(fā)效率，新做的架構(gòu)能帶來哪方面的提升。一定要讓領(lǐng)導(dǎo)明白，這個能帶來實(shí)實(shí)在在的長期收益，不管性能、效率、安全等都可以，而并非只是“看著不爽”而進(jìn)行的重構(gòu)。

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

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

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

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

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

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