一個(gè)軟件項(xiàng)目從探索階段到發(fā)展方向明確階段，會(huì)經(jīng)歷從簡(jiǎn)單到復(fù)雜的一個(gè)過(guò)程，需求的不斷疊加，會(huì)讓系統(tǒng)越來(lái)越龐大，功能繁多，公司業(yè)務(wù)的擴(kuò)展也讓軟件系統(tǒng)的生命周期變的更長(zhǎng)。

在業(yè)務(wù)變復(fù)雜的過(guò)程中，各種原因的驅(qū)使，代碼質(zhì)量會(huì)退化，維護(hù)和開(kāi)發(fā)新功能的成本也會(huì)相應(yīng)的變高，推倒重新開(kāi)發(fā)的成本也是高的嚇人。

代碼質(zhì)量退化的步驟

大多情況下編碼設(shè)計(jì)質(zhì)量最高的時(shí)候是根據(jù)第一版需求進(jìn)行編碼實(shí)現(xiàn)的時(shí)候，但只要需求一變更，就會(huì)打亂原來(lái)的編碼設(shè)計(jì)，軟件質(zhì)量也就會(huì)越來(lái)越差。或者就沒(méi)有了設(shè)計(jì)。

代碼的變化趨勢(shì)

到了項(xiàng)目中期，有新的功能或者bug的修復(fù)，老板就給我了一天時(shí)間，讓我寫(xiě)好處理代碼？逾期是要被罵的；這個(gè)沒(méi)用的功能，做了也沒(méi)人用，隨便寫(xiě)吧，早點(diǎn)結(jié)束，早去干別的；我手上現(xiàn)在這么多活，你又插進(jìn)來(lái)個(gè)新功能，我只能亂搞了，團(tuán)隊(duì)內(nèi)人員水平的不同寫(xiě)的代碼更是天差地別，等等，這都是我們實(shí)際工作中會(huì)遇到的問(wèn)題。

責(zé)任心讓我們也會(huì)想先這樣寫(xiě)，以后再重構(gòu)，一般以后重構(gòu)表示永遠(yuǎn)不會(huì)重構(gòu)。上面說(shuō)的這些都會(huì)讓我們?cè)黾釉愀獾拇a，混亂的業(yè)務(wù)邏輯分布在我們系統(tǒng)的各個(gè)地方，部門(mén)人員變動(dòng)，新的員工更不可能理解那些雜亂無(wú)章的東西，再接著推糟糕的代碼，想要理清楚一個(gè)業(yè)務(wù)邏輯，非常容易在混亂的代碼中迷路。

最直接的后果就是這些混亂的代碼會(huì)增加新功能的開(kāi)發(fā)周期，領(lǐng)導(dǎo)層問(wèn)為啥現(xiàn)在開(kāi)發(fā)個(gè)功能這么慢？是不是人手不夠，再招幾個(gè)人吧。這雜亂的項(xiàng)目，不是新員工能理的清的，你會(huì)發(fā)現(xiàn)，雖然員工變多了。但開(kāi)發(fā)效率還是上不去。

項(xiàng)目演進(jìn)

那我們重新來(lái)做一個(gè)新的系統(tǒng)完全替代這個(gè)老項(xiàng)目吧，可以用最新的框架，更好的實(shí)現(xiàn)方式去完成這個(gè)系統(tǒng)，這種天真的想法會(huì)在團(tuán)隊(duì)成員的腦海里無(wú)數(shù)次出現(xiàn)。

舊的系統(tǒng)業(yè)務(wù)很復(fù)雜，新的系統(tǒng)在兼容舊系統(tǒng)邏輯的同時(shí)，舊的系統(tǒng)也在更新需求，增加功能，在新系統(tǒng)完全可以抗衡舊系統(tǒng)之前，舊的系統(tǒng)會(huì)一直運(yùn)行。如果你的新系統(tǒng)開(kāi)發(fā)的時(shí)間過(guò)長(zhǎng)，等完成的時(shí)候，可能員工都已經(jīng)不知道換了幾批了，代碼又亂成了一鍋粥，周而復(fù)始。

軟件的退化變的越來(lái)越嚴(yán)重的過(guò)程中，我們也在思考和改變現(xiàn)有的系統(tǒng)，如何才能讓系統(tǒng)的在擁有更長(zhǎng)的生命周期的同時(shí)，提高代碼的質(zhì)量，不讓其退化，并擁有更好的可維護(hù)性和擴(kuò)展性？那就是根據(jù)需求的變化去調(diào)整架構(gòu)、代碼，不斷的打破原來(lái)的設(shè)計(jì)，保持清晰，而不是讓他爛在那里。

漸進(jìn)式架構(gòu)

大多數(shù)人能想到的最直接的方案是從架構(gòu)入手，引入多維度的架構(gòu)，微服務(wù)化，領(lǐng)域驅(qū)動(dòng)模型(DDD)等等，從頂層設(shè)計(jì)出發(fā)引入新的架構(gòu)模型，或者說(shuō)根據(jù)需求的變動(dòng)不斷的調(diào)整代碼的分層和模塊，加上理論知識(shí)的應(yīng)用，會(huì)讓業(yè)務(wù)代碼在結(jié)構(gòu)歸屬上更清晰。分層的嚴(yán)密能讓整體的業(yè)務(wù)邊界更明確，前提是我們要從多維度去審視系統(tǒng)的構(gòu)架，思考如何去現(xiàn)有的架構(gòu)做出合理的改動(dòng)。

從不同的角度去分析和改進(jìn)現(xiàn)有架構(gòu)

比如在項(xiàng)目初期業(yè)務(wù)比較簡(jiǎn)單，最簡(jiǎn)單的分層架構(gòu)就實(shí)現(xiàn)了項(xiàng)目需求，觀察我們的架構(gòu)可能是這樣子的，從上而下的松散分層架構(gòu)：

松散分層架構(gòu)

后來(lái)又加入了緩存，又加入了消息隊(duì)列，業(yè)務(wù)的不斷擴(kuò)張又加入了不同的數(shù)據(jù)庫(kù)nosql。業(yè)務(wù)的升級(jí)有了v2.0、v3.0，新業(yè)務(wù)要兼容舊功能等等，如果還是原來(lái)的分層結(jié)構(gòu)，很快就會(huì)出現(xiàn)邏輯代碼堆積的問(wèn)題，業(yè)務(wù)層之間引用雜亂，一個(gè)代碼文件幾千行代碼，需求變動(dòng)時(shí)牽一發(fā)動(dòng)全身，及時(shí)調(diào)整架構(gòu)的必要性就體現(xiàn)出來(lái)了。

一定要復(fù)用好依賴(lài)倒置原則，層與層之間不應(yīng)該依賴(lài)實(shí)現(xiàn)，要依賴(lài)于抽象。比如，我們的基礎(chǔ)設(shè)施層要為其他三層提供支持，基礎(chǔ)設(shè)施層可以實(shí)現(xiàn)其他層定義的接口來(lái)進(jìn)行抽象，從這個(gè)角度來(lái)開(kāi)的話我們的基礎(chǔ)設(shè)施層應(yīng)該在最上面，也可以是左邊或者右邊。

基礎(chǔ)架構(gòu)

應(yīng)用依賴(lài)倒置后，我們調(diào)用的是抽象接口，你會(huì)發(fā)現(xiàn)層的概念沒(méi)有了，層的概念被打破了，我們可以更激進(jìn)一點(diǎn)把基礎(chǔ)設(shè)施層剝離出去用各種適配器去接入各種組件，把層的關(guān)系拉平，把架構(gòu)調(diào)整為六邊形構(gòu)架。

六邊形架構(gòu)

不要固化自己的思維，根據(jù)業(yè)務(wù)和系統(tǒng)的發(fā)展去調(diào)整你的系統(tǒng)架構(gòu)，能讓系統(tǒng)能更高的可擴(kuò)展和可維護(hù)性。對(duì)于非常老的項(xiàng)目調(diào)整架構(gòu)是痛苦的，一定要得到管理層充分的支持下再去做改造，這樣的工作只能是從上往下推進(jìn)，痛苦的過(guò)程終會(huì)換來(lái)后期維護(hù)的喜悅。

代碼層面

在團(tuán)隊(duì)內(nèi)除了要有代碼規(guī)范，所有人都要遵守，這樣代碼的風(fēng)格才能更統(tǒng)一，和使用Lint工具去檢查代碼，各種語(yǔ)言lint工具，能在早期查檢出你代碼中不合理的地方。還有下面一些辦法。

功能模塊化

程序員最喜歡的就是編碼實(shí)現(xiàn)具體的功能，在這里才是我們真正秀內(nèi)功的地方，可以應(yīng)用各種模式把代碼和邏輯寫(xiě)的很漂亮，但是放到整個(gè)項(xiàng)目結(jié)構(gòu)里，被調(diào)用和使用的過(guò)程又感覺(jué)那么的不協(xié)調(diào)，根源是我們模塊劃分不正確，模塊之間的依賴(lài)耦合性太強(qiáng)。

這就是典型的寫(xiě)的很優(yōu)雅，使用的很粗糙。依賴(lài)倒置原則，依然適用于模塊間的劃分，模塊與模塊之間的依賴(lài)是倒置的，用依賴(lài)注入的方式去解耦，模塊對(duì)外暴露出盡可能少的接口，之間的調(diào)用依賴(lài)于接口。抽象的好處能讓你把模塊的邊界定義的更明確。

對(duì)象之間是協(xié)作關(guān)系，不是糾纏

業(yè)務(wù)越復(fù)雜，需要操作的對(duì)象也就越多，對(duì)象的邊界不明確就會(huì)出現(xiàn)糾纏不清的情況。要不就是一個(gè)對(duì)象負(fù)責(zé)的東西過(guò)多，要不就是幾個(gè)對(duì)象同時(shí)做一件事，邏輯雜亂。

當(dāng)你發(fā)現(xiàn)對(duì)象之前不再是協(xié)作關(guān)系時(shí)就要停下來(lái)，從高處去看你組織的代碼，把大對(duì)象分解，職責(zé)界線理清楚也就是功能單一原則。很多同學(xué)不知道如何確定一個(gè)對(duì)象的職責(zé)，不清楚一個(gè)屬性是不是屬于某個(gè)對(duì)象。最簡(jiǎn)單的方法就是，判斷這個(gè)屬性的變動(dòng)會(huì)不影響某個(gè)對(duì)象，如果沒(méi)有就不屬于這個(gè)對(duì)象。還有就是，面對(duì)新的業(yè)務(wù)需求敢于打破原有的代碼設(shè)計(jì)，不破不立。

不要過(guò)度開(kāi)發(fā)，刪除沒(méi)用的代碼

定期要檢查和刪除沒(méi)用的代碼。少寫(xiě)或者不寫(xiě)感覺(jué)未來(lái)可能會(huì)用到的方法，這些多出來(lái)的代碼會(huì)成為將來(lái)重構(gòu)的絆腳石，會(huì)浪費(fèi)精力在這些沒(méi)有用到的代碼上，查找有沒(méi)有地方在使用他。

SOLID 原則

不能不提的，就是Bob大叔（Robert C. Martin）的SOLID編碼原則，它是設(shè)計(jì)模式的基石，要不斷的去應(yīng)用和實(shí)踐。隨著編碼時(shí)間的增長(zhǎng)，越來(lái)越感覺(jué)SOLID真的是一盞明燈，當(dāng)你在黑暗中找不到方向的時(shí)候，指引你回歸正確的道路。如果你對(duì)SOLID原則應(yīng)用的比較熟練，上面說(shuō)的幾項(xiàng)完全都可以忽略。

(1) 單一職責(zé)原則(Single Responsibility Principle)

每個(gè)對(duì)象只有一個(gè)職責(zé)，明確對(duì)象的邊界，文章上面說(shuō)的對(duì)象之間是協(xié)作關(guān)系，“不是糾纏”里就說(shuō)過(guò)，如何確定一個(gè)屬性是否屬于某個(gè)對(duì)象。

(2) 開(kāi)閉原則(Open Closed Principle)

即可擴(kuò)展(extension)，不可修改(modification)原則，抽取出代碼中不變的邏輯，封裝可變的代碼， 策略模式就很好的表達(dá)這個(gè)原則的模式。

(3) 里氏替換原則(Liskov Substitution Principle)

繼承必須確保超類(lèi)所擁有的性質(zhì)在子類(lèi)中仍然成立，里氏替換原則主要闡述了有關(guān)繼承的一些原則，也就是什么時(shí)候應(yīng)該使用繼承，什么時(shí)候不應(yīng)該使用繼承，以及其中蘊(yùn)含的原理。

里氏替換原是繼承復(fù)用的基礎(chǔ)，它反映了基類(lèi)與子類(lèi)之間的關(guān)系，是對(duì)開(kāi)閉原則的補(bǔ)充，是對(duì)實(shí)現(xiàn)抽象化的具體步驟的規(guī)范。關(guān)于里氏替換原則的例子，最有名的是“正方形不是長(zhǎng)方形“。

(4) 接口隔離原則(Interface Segregation Principle)

盡量將臃腫龐大的接口拆分成更小的和更具體的接口，讓接口中只包含調(diào)用方感興趣的方法，這也是我們把復(fù)雜功能分模塊的應(yīng)用法則。

接口隔離原則和單一職責(zé)都是為了提高類(lèi)的內(nèi)聚性、降低它們之間的耦合性，但兩者是不同的：?jiǎn)我宦氊?zé)原則注重的是職責(zé)，而接口隔離原則注重的是對(duì)接口依賴(lài)的隔離。單一職責(zé)原則主要是約束類(lèi)，它針對(duì)的是程序中的實(shí)現(xiàn)和細(xì)節(jié)；接口隔離原則主要約束接口，主要針對(duì)抽象和程序整體框架的構(gòu)建。

(5) 依賴(lài)倒置原則(Dependence Inversion Principle)

抽象不應(yīng)該依賴(lài)于細(xì)節(jié)，細(xì)節(jié)應(yīng)當(dāng)依賴(lài)于抽象。換言之，要針對(duì)抽象（接口）編程，而不是針對(duì)實(shí)現(xiàn)細(xì)節(jié)編程。上面在說(shuō)改進(jìn)架構(gòu)的時(shí)候有說(shuō)這個(gè)原則。

重構(gòu)代碼

新功能的開(kāi)發(fā)的同時(shí)要重構(gòu)之前邏輯，堅(jiān)持開(kāi)閉原則，能達(dá)到事半功倍的效果。工作閑暇時(shí)間去瀏覽現(xiàn)有的代碼邏輯，我們每天都在成長(zhǎng)，對(duì)系統(tǒng)的認(rèn)知也在改變，思維方式也在不斷的變化，用現(xiàn)在的眼光去審視舊的代碼邏輯，大多數(shù)是能找可以優(yōu)化的地方，或者隱藏的bug，重構(gòu)它。不要以為這些只是一些擠牙膏式的調(diào)優(yōu)，所有的事情都有一個(gè)從質(zhì)變到量變的過(guò)程。

代碼評(píng)審(code review)

代碼評(píng)審在團(tuán)隊(duì)里還是很有必要的，代碼評(píng)審不是口水戰(zhàn)，也不是批斗大會(huì)，如果只是走形式code review的意義也就不存在了。你寫(xiě)的代碼是需要讓團(tuán)隊(duì)的成員能看明白的，將來(lái)也是會(huì)有新的員工來(lái)維護(hù)你寫(xiě)的功能的，code review是一個(gè)能讓團(tuán)隊(duì)內(nèi)的其他成員快速了解新代碼意圖的辦法。

大多數(shù)團(tuán)隊(duì)里程序員的水平參差不齊的，對(duì)業(yè)務(wù)和系統(tǒng)的理解深度也是不一樣的，讓團(tuán)隊(duì)內(nèi)不同的人去code review能及時(shí)發(fā)現(xiàn)代碼中的不足之處，哪些地方邏輯上有問(wèn)題，哪里的業(yè)務(wù)沒(méi)有考慮全面。

代碼評(píng)審

當(dāng)一次提交的代碼太多時(shí)，一下子是看不完，也可能理解不了，就要先評(píng)審整體思路，再review實(shí)現(xiàn)主干邏輯，最后才是實(shí)現(xiàn)細(xì)節(jié)。需說(shuō)明一下的是，code review 并不能完全發(fā)現(xiàn)代碼中隱藏的bug，不要把找bug的任務(wù)和它混在一起。

學(xué)習(xí)多少構(gòu)架或者框架知識(shí)，都不能阻止我們寫(xiě)爛代碼。但當(dāng)你沉下心來(lái)去打磨產(chǎn)品或者認(rèn)真去實(shí)現(xiàn)一個(gè)功能時(shí)，你會(huì)在意你寫(xiě)的代碼，會(huì)主動(dòng)去寫(xiě)更清晰的邏輯，并改變和想辦法去并處理糟糕的代碼，希望這篇帖子有能幫助到你的地方。