編寫高質(zhì)量可維護(hù)的代碼既是程序員的基本修養(yǎng)，也是能決定項(xiàng)目成敗的關(guān)鍵因素，本文試圖總結(jié)出問題項(xiàng)目普遍存在的共性問題并給出相應(yīng)的解決方案。

1. 程序員的宿命？

程序員的職業(yè)生涯中難免遇到爛項(xiàng)目，有些項(xiàng)目是你加入時(shí)已經(jīng)爛了，有些是自己從頭開始親手做成了爛項(xiàng)目，有些是從里到外的爛，有些是表面光鮮等你深入進(jìn)去發(fā)現(xiàn)是個(gè)“焦油坑”，有些是此時(shí)還沒爛但是已經(jīng)出現(xiàn)問題征兆走在了腐爛的路上。

國內(nèi)基本上是這樣，國外情況我了解不多，不過從英文社區(qū)和技術(shù)媒體上老外同行的抱怨程度看，應(yīng)該是差不多的，雖然整體素質(zhì)可能更高，但是也因更久的信息化而積累了更多問題。畢竟“焦油坑、Shit_Mountain 屎山”這些舶來的術(shù)語不是無緣無故被發(fā)明出來的。

Any way，這大概就是我們這個(gè)行業(yè)的宿命——要么改行，要么就是與爛項(xiàng)目爛代碼長相伴。就像宇宙的“熵增加定律”一樣：

孤立系統(tǒng)的一切自發(fā)過程均向著令其狀態(tài)更無序的方向發(fā)展，如果要使系統(tǒng)恢復(fù)到原先的有序狀態(tài)是不可能的，除非外界對(duì)它做功。

面對(duì)這宿命的陰影，有些人認(rèn)命了麻木了，逐漸對(duì)這個(gè)行業(yè)失去熱情。

那些不認(rèn)命的選擇與之抗?fàn)帲堑厣喜]有路，當(dāng)年軟件危機(jī)的陰云也從未真正散去，人月神話仍然是神話，于是人們做出了各自不同的判斷和嘗試：

• 掀桌子另起爐灶派：
• 很多人把項(xiàng)目做爛的原因歸咎于項(xiàng)目前期的基礎(chǔ)沒打好、需求不穩(wěn)定一路打補(bǔ)丁、前面的架構(gòu)師和程序員留下的爛攤子難以收拾。
• 他們要么沒有信心去收拾爛攤子，要么覺得這是費(fèi)力不討好，于是要放棄掉項(xiàng)目，寄希望于出現(xiàn)一個(gè)機(jī)會(huì)能重頭再來。
• 但是他們對(duì)于如何避免重蹈覆轍、做出另一個(gè)爛項(xiàng)目是沒有把握也沒有深入思考的，只是盲目樂觀的認(rèn)為自己比前任更高明。
• 激進(jìn)改革派：
• 這個(gè)派別把原因歸結(jié)于爛項(xiàng)目當(dāng)初沒有采用正確的編程語言、最新最強(qiáng)大的技術(shù)棧或工具。
• 他們中一部分人也想著有機(jī)會(huì)另起爐灶，用上時(shí)下最流行最熱門的技術(shù)棧（spring boot、springcloud、redis、nosql、docker、vue）。
• 或者即便不另起爐灶，也認(rèn)為現(xiàn)有技術(shù)棧太過時(shí)無法容忍了（其實(shí)可能并不算過時(shí)），不用微服務(wù)不用分布式就不能接受，于是激進(jìn)的引入新技術(shù)棧，魯莽的對(duì)項(xiàng)目做大手術(shù)。
• 這種對(duì)剛剛流行還不成熟技術(shù)的盲目跟風(fēng)、技術(shù)選型不慎重的情況非常普遍，今天在他們眼中落伍的技術(shù)棧，其實(shí)也不過是幾年前另一批人趕的時(shí)髦。
• 我不反對(duì)技術(shù)上的追新，但是同樣的，這里的問題是：他們對(duì)于大手術(shù)的風(fēng)險(xiǎn)和副作用，對(duì)如何避免重蹈覆轍用新技術(shù)架構(gòu)做出另一個(gè)爛項(xiàng)目，沒有把握也沒有深入思考的，只是盲目樂觀的認(rèn)為新技術(shù)能帶來成功。
• 也沒人能阻止這種簡歷驅(qū)動(dòng)的技術(shù)選型浮躁風(fēng)氣，畢竟花的是公司的資源，用新東西顯得自己很有追求，失敗了也不影響簡歷美化，簡歷上只會(huì)增加一段項(xiàng)目履歷和幾種精通技能，不會(huì)提到又做爛了一個(gè)項(xiàng)目，名利雙收穩(wěn)賺不賠。
• 保守改良派：
• 還有一類人他們不愿輕易放棄這個(gè)有問題但仍在創(chuàng)造效益的項(xiàng)目，因?yàn)樗麄兛吹搅隧?xiàng)目仍然有維護(hù)的價(jià)值，也看到了另起爐灶的難度（萬事開頭難，其實(shí)項(xiàng)目的冷啟動(dòng)存在很多外部制約因素）、大手術(shù)對(duì)業(yè)務(wù)造成影響的代價(jià)、系統(tǒng)遷移的難度和風(fēng)險(xiǎn)。
• 同時(shí)他們嘗試用溫和漸進(jìn)的方式逐步改善項(xiàng)目質(zhì)量，采用一系列工程實(shí)踐（主要包括重構(gòu)熱點(diǎn)代碼、補(bǔ)自動(dòng)化測試、補(bǔ)文檔）來清理“技術(shù)債”，消除制約項(xiàng)目開發(fā)效率和交付質(zhì)量的瓶頸。

如果把一個(gè)問題項(xiàng)目比作病入膏肓的病人，那么這三種做法分別相當(dāng)于是放棄治療、截肢手術(shù)、保守治療。

2. 一個(gè) 35+ 程序員的反思

年輕時(shí)候我也是掀桌子派和激進(jìn)派的，新工程新框架大開大合，一路走來經(jīng)驗(yàn)值技能樹蹭蹭的漲，跳槽加薪好不快活。

但是近幾年隨著年齡增長，一方面新東西學(xué)不動(dòng)了，另一方面對(duì)經(jīng)歷過的項(xiàng)目反思的多了觀念逐漸改變了。

對(duì)我觸動(dòng)最大的一件事是那個(gè)我在 2016 年初開始從零搭建起的項(xiàng)目，在我 2018 年底離開的時(shí)候（僅從代碼質(zhì)量角度）已經(jīng)讓我很不滿意了。只是，這一次沒有任何借口了：

• 從技術(shù)選型到架構(gòu)設(shè)計(jì)到代碼規(guī)范，都是我自己做的，團(tuán)隊(duì)不大，也是我自己組建和一手帶出來的；
• 最開始的半年進(jìn)展非常順利，用著我最趁手的技術(shù)和工具一路狂奔，年底前替換掉了之前采購的那個(gè)垃圾產(chǎn)品（對(duì)的，有個(gè)前任在業(yè)務(wù)上做參照也算是個(gè)很大的有利因素）；
• 做的過程我也算是全力以赴，用盡畢生所學(xué)——前面 13 年工作的經(jīng)驗(yàn)值和走過的彎路、教訓(xùn)，使得公司只用其它同類公司同類項(xiàng)目 20% 的資源就把平臺(tái)做起來了；
• 如果說多快好省是最高境界，那么當(dāng)時(shí)的我算是做到了多、快、省——交付的功能非常豐富且貼近業(yè)務(wù)需求、開發(fā)節(jié)奏快速、對(duì)公司開發(fā)資源很節(jié)省；
• 但是現(xiàn)在看來，“好”就遠(yuǎn)遠(yuǎn)沒有達(dá)到了，到了項(xiàng)目中期，簡單優(yōu)先級(jí)高的需求都已經(jīng)做完了，公司業(yè)務(wù)上出現(xiàn)了新的挑戰(zhàn)——接入另一個(gè)核心系統(tǒng)以及外部平臺(tái)，真正的考驗(yàn)來了。
• 那個(gè)改造工程影響面比較大，需要對(duì)我們的系統(tǒng)做大面積修改，最麻煩的是這意味著從一個(gè)簡單的單體系統(tǒng)變成了一個(gè)分布式的系統(tǒng)，而且業(yè)務(wù)涉及資金交易，可靠性要求較高，是難上加難。
• 于是問題開始出現(xiàn)了：我之前架構(gòu)的優(yōu)點(diǎn)——簡單直接——這個(gè)時(shí)候不再是優(yōu)點(diǎn)了，簡單直接的架構(gòu)在業(yè)務(wù)環(huán)境、技術(shù)環(huán)境都簡單的情況下可以做到多快好省，但是當(dāng)業(yè)務(wù)、技術(shù)環(huán)境都陡然復(fù)雜起來時(shí)，就不行了；
• 具體的表現(xiàn)就是：架構(gòu)和代碼層面的結(jié)構(gòu)都快速的變得復(fù)雜、混亂起來了——熵急劇增加；
• 后面的事情就一發(fā)不可收拾：代碼改起來越來越吃力、測試問題變多、生產(chǎn)環(huán)境故障和問題變多、于是消耗在排查測試問題生產(chǎn)問題和修復(fù)數(shù)據(jù)方面的精力急劇增加、出現(xiàn)惡性循環(huán)。。。
• 到了這個(gè)境地，項(xiàng)目就算是做爛了！一個(gè)我從頭開始做起的沒有任何借口的失敗！

于是我意識(shí)到一個(gè)非常淺顯的道理：擁有一張空白的畫卷、一支最高級(jí)的畫筆、一間專業(yè)的畫室，無法保證你可以畫出美麗的畫卷。如果你不善于畫畫，那么一切都是空想和意淫。

然后我變成了一個(gè)“保守改良派”，因?yàn)槲乙庾R(shí)到掀桌子和激進(jìn)的改革都是不負(fù)責(zé)任的，說不好聽的那樣其實(shí)是掩耳盜鈴、逃避困難，人不可能逃避一輩子，你總要面對(duì)。

即便掀了桌子另起爐灶了，你還是需要找到一種辦法把這個(gè)新的爐灶燒好，因?yàn)殡S著項(xiàng)目發(fā)展之前的老問題還是會(huì)一個(gè)一個(gè)冒出來，還是需要面對(duì)現(xiàn)實(shí)、不逃避、找辦法。

面對(duì)問題不僅有助于你把當(dāng)前項(xiàng)目做好，也同樣有助于將來有新的項(xiàng)目時(shí)更好的把握住機(jī)會(huì)。

無論是職業(yè)生涯還是自然年齡，人到了這個(gè)階段都開始喜歡回顧和總結(jié)，也變得比過去更在乎項(xiàng)目、產(chǎn)品乃至公司的商業(yè)成敗。

軟件開發(fā)作為一種商業(yè)活動(dòng)，判斷其成敗的依據(jù)應(yīng)該是：能否以可接受的成本、可預(yù)期的時(shí)間節(jié)奏、穩(wěn)定的質(zhì)量水平、持續(xù)交付滿足業(yè)務(wù)需要的功能市場需要的產(chǎn)品。

其實(shí)就是項(xiàng)目管理四要素——成本、進(jìn)度、范圍、質(zhì)量，傳統(tǒng)項(xiàng)目管理理論認(rèn)為這四要素彼此制約難以兼得，項(xiàng)目管理的藝術(shù)在于四要素的平衡取舍。

關(guān)于軟件工程和項(xiàng)目管理的理論和著作已經(jīng)很多很成熟，這里我從程序員的視角提出一個(gè)新的觀點(diǎn)——質(zhì)量不可妥協(xié)：

• 質(zhì)量要素不是一個(gè)可以被犧牲和妥協(xié)的要素——犧牲質(zhì)量會(huì)導(dǎo)致其它三要素全都受損，反之同理，追求質(zhì)量會(huì)讓你在其它三個(gè)方面同時(shí)受益。
• 在保持一個(gè)質(zhì)量水平的前提下，成本、進(jìn)度、范圍三要素確確實(shí)實(shí)是互相制約關(guān)系——典型的比如犧牲成本（加班加點(diǎn)）來加快進(jìn)度交付急需的功能。
• 正如著名的“破窗效應(yīng)”所啟示的那樣：任何一種不良現(xiàn)象的存在，都在傳遞著一種信息，這種信息會(huì)導(dǎo)致不良現(xiàn)象的無限擴(kuò)展，同時(shí)必須高度警覺那些看起來是偶然的、個(gè)別的、輕微的“過錯(cuò)”，如果對(duì)這種行為不聞不問、熟視無睹、反應(yīng)遲鈍或糾正不力，就會(huì)縱容更多的人“去打爛更多的窗戶玻璃”，就極有可能演變成“千里之堤，潰于蟻穴”的惡果——質(zhì)量不佳的代碼之于一個(gè)項(xiàng)目，正如一扇破了的窗之于一幢建筑、一個(gè)螞蟻巢之于一座大堤。
• 好消息是，只要把質(zhì)量提上去項(xiàng)目就會(huì)逐漸走上健康的軌道，其它三個(gè)方面也都會(huì)改善。管好了質(zhì)量，你就很大程度上把握住了項(xiàng)目成敗的關(guān)鍵因素。
• 壞消息是，項(xiàng)目的質(zhì)量很容易失控，現(xiàn)實(shí)中質(zhì)量不佳、越做越臃腫混亂的項(xiàng)目比比皆是，質(zhì)量改善越做越好的案例聞所未聞，以至于人們將其視為如同物理學(xué)中“熵增加定律”一樣的必然規(guī)律了。
• 當(dāng)然任何事情都有一個(gè)度的問題，當(dāng)質(zhì)量低于某個(gè)水平時(shí)才會(huì)導(dǎo)致其它三要素同時(shí)受損。反之當(dāng)質(zhì)量高到某個(gè)水平以后，繼續(xù)追求質(zhì)量不僅得不到明顯收益，而且也會(huì)損害其它三要素——邊際效用遞減定律。
• 這個(gè)度需要你為自己去評(píng)估和測量，如果目前的質(zhì)量水平還在兩者之間，那么就應(yīng)該重點(diǎn)改進(jìn)項(xiàng)目質(zhì)量。當(dāng)然，現(xiàn)實(shí)世界中很少看到哪個(gè)項(xiàng)目質(zhì)量高到了不需要重視的程度。

3. 項(xiàng)目走向衰敗的最常見誘因——代碼質(zhì)量不佳

一個(gè)項(xiàng)目的衰敗一如一個(gè)人健康狀況的惡化，當(dāng)然可能有多種多樣的原因——比如需求失控、業(yè)務(wù)調(diào)整、人員變動(dòng)流失。但是作為我們技術(shù)人，如果能做好自己分內(nèi)的工作——編寫出可維護(hù)的代碼、減少技術(shù)債利息成本、交付一個(gè)健壯靈活的應(yīng)用架構(gòu)，那也絕對(duì)是功德無量的。

雖然很難估算出這究竟能挽救多少項(xiàng)目，但是在我十多年職業(yè)生涯中，經(jīng)歷的和近距離觀察的幾十個(gè)項(xiàng)目，確實(shí)看到了大量的項(xiàng)目正是由于代碼質(zhì)量不佳導(dǎo)致的失敗和遺憾，同時(shí)我也發(fā)現(xiàn)其實(shí)失敗項(xiàng)目的很多問題、癥結(jié)也確確實(shí)實(shí)都可以歸因到項(xiàng)目代碼的混亂和質(zhì)量低下，比如一個(gè)常見的項(xiàng)目腐爛惡性循環(huán)：代碼亂》bug 多》排查問題耗時(shí)》復(fù)用度低》加班 996》士氣低落……

所謂“千里之堤，毀于蟻穴”，代碼問題就是蟻穴。

接下來，讓我們從項(xiàng)目管理聚焦到項(xiàng)目代碼質(zhì)量這個(gè)相對(duì)小的領(lǐng)域來深入剖析。編寫高質(zhì)量可維護(hù)的代碼是程序員的基本修養(yǎng)，本文試圖在代碼層面找到一些失敗項(xiàng)目中普遍存在的癥結(jié)問題，同時(shí)基于個(gè)人十幾年開發(fā)經(jīng)驗(yàn)總結(jié)出的一些設(shè)計(jì)模式作為藥方分享出來。

關(guān)于代碼質(zhì)量的話題其實(shí)很難通過一篇文章闡述明白，甚至需要一本書的篇幅，里面涉及到的很多概念關(guān)注點(diǎn)之間存在復(fù)雜微妙關(guān)系。

推薦《設(shè)計(jì)模式之美》的第二章節(jié)《從哪些維度評(píng)判代碼質(zhì)量的好壞？如何具備寫出高質(zhì)量代碼的能力？》，這是我看到的關(guān)于代碼質(zhì)量主題最精彩深刻的論述。

4. 一個(gè)失敗項(xiàng)目復(fù)盤

先貼幾張代碼截圖，看一下這個(gè)重病纏身的項(xiàng)目的病灶和癥狀：

• 這是該項(xiàng)目中一個(gè)最核心、最復(fù)雜也是最經(jīng)常要被改動(dòng)的 class，代碼行數(shù) 4881；
• 結(jié)果就是冗長的 API 列表（列表需要滾動(dòng) 4 屏才能到底，公有私有 API 180 個(gè)）；

• 還是那個(gè) Class，頭部的 import 延綿到了 139 行，去掉第一行 package 聲明和少量空行總共 import 引入了 130 個(gè) class！

• 還是那個(gè)坑爹的組件，從 156 行開始到 235 行聲明了 Spring 依賴注入的組件 40 個(gè)！

這里先不去分析這個(gè)類的問題，只是初步展示一下病情嚴(yán)重程度。

我相信這應(yīng)該不算是特別糟糕的情況，比這個(gè)嚴(yán)重的項(xiàng)目俯拾皆是，但是這也應(yīng)該足夠拿來暴露問題、剖析成因了。

4.1 癥結(jié) 1：組件粒度過大、API 泛濫

分層的理念早已深入人心，尤其是業(yè)務(wù)邏輯層的獨(dú)立，徹底杜絕了之前（不分層的年代）業(yè)務(wù)邏輯與展現(xiàn)邏輯、持久化邏輯等混雜的問題。

但是好景不長，隨著業(yè)務(wù)的復(fù)雜和變更，在業(yè)務(wù)邏輯層的復(fù)雜性也急劇增加，成為了新的開發(fā)效率瓶頸， 問題就出在了業(yè)務(wù)邏輯組件的劃分方式——按領(lǐng)域模型劃分業(yè)務(wù)邏輯組件：

• 業(yè)界關(guān)于如何設(shè)計(jì)業(yè)務(wù)邏輯層 并沒有標(biāo)準(zhǔn)和最佳實(shí)踐，絕大多數(shù)項(xiàng)目（我自己經(jīng)歷過的項(xiàng)目以及我有機(jī)會(huì)深入了解的項(xiàng)目）中大家都是想當(dāng)然的按照業(yè)務(wù)領(lǐng)域?qū)ο髞碓O(shè)計(jì)；
• 例如：領(lǐng)域?qū)嶓w對(duì)象有 Account、Order、Delivery、Campaign。于是業(yè)務(wù)邏輯層就設(shè)計(jì)出 AccountService、OrderService、DeliveryService、CampaignService
• 這種做法在項(xiàng)目簡單是沒什么問題，事實(shí)上項(xiàng)目簡單時(shí) 你隨便怎么設(shè)計(jì)都問題不大。
• 但是當(dāng)項(xiàng)目變大和復(fù)雜以后，就會(huì)出現(xiàn)問題了：
• 組件臃腫：Service 組件的個(gè)數(shù)跟領(lǐng)域?qū)嶓w對(duì)象個(gè)數(shù)基本相當(dāng)，必然造成個(gè)別 Service 組件變得非常臃腫——API 非常多，代碼行數(shù)達(dá)到幾千行；
• 職責(zé)模糊：業(yè)務(wù)邏輯往往跨多個(gè)領(lǐng)域?qū)嶓w，無論放在哪個(gè) Service 都不合適，同樣的，要找一個(gè)功能的實(shí)現(xiàn)邏輯也無法確定在哪個(gè) Service 中；
• 代碼重復(fù) or 邏輯糾纏的兩難選擇：當(dāng)遇到一個(gè)業(yè)務(wù)邏輯，其中的某個(gè)環(huán)節(jié)在另一個(gè)業(yè)務(wù)邏輯 API 中已經(jīng)實(shí)現(xiàn)，這時(shí)如果不想忍受重復(fù)實(shí)現(xiàn)和代碼，就只能去調(diào)用那個(gè) API。但這樣就造成了業(yè)務(wù)邏輯組件之間的耦合與依賴，這種耦合與依賴很快會(huì)擴(kuò)散——新的 API 又會(huì)被其它業(yè)務(wù)邏輯依賴，最終形成蜘蛛網(wǎng)一樣的復(fù)雜依賴甚至循環(huán)依賴；
• 復(fù)用代碼、減少重復(fù)雖然是好的，但是復(fù)雜耦合依賴的害處也很大——趕走一只狼引來了一只虎。兩杯毒酒給你選！

前面截圖的那個(gè)問題組件 ContractService 就是一個(gè)典型案例，這樣的組件往往是熱點(diǎn)代碼以及整個(gè)項(xiàng)目的開發(fā)效率的瓶頸。

4.2 藥方 1：倒金字塔結(jié)構(gòu)——業(yè)務(wù)邏輯組件職責(zé)單一、禁止層內(nèi)依賴

問題根源的反面其實(shí)就藏著解決方案，只是需要我們有意識(shí)的去改變習(xí)慣、遵循新的設(shè)計(jì)風(fēng)格，而不是憑直覺去設(shè)計(jì)：

• 業(yè)務(wù)邏輯層應(yīng)該被設(shè)計(jì)成一個(gè)個(gè)功能非常單一的小組件，所謂小是指 API 數(shù)量少、代碼行數(shù)少；
• 由于職責(zé)單一因此必然組件數(shù)量多，每一個(gè)組件對(duì)應(yīng)一個(gè)很具體的業(yè)務(wù)功能點(diǎn)（或者幾個(gè)相近的）；
• 復(fù)用（調(diào)用、依賴）只應(yīng)該發(fā)生在相鄰的兩層之間——上層調(diào)用下層的 API 來實(shí)現(xiàn)對(duì)下層功能的復(fù)用；
• 于是系統(tǒng)架構(gòu)就自然呈現(xiàn)出倒立的金字塔形狀：越接近頂層的業(yè)務(wù)場景組件數(shù)量越多，越往下層的復(fù)用性高，于是組件數(shù)量越少。

4.3 癥結(jié) 2：低內(nèi)聚、高耦合

經(jīng)典面向?qū)ο罄碚摳嬖V我們，好的代碼結(jié)構(gòu)應(yīng)該是“高內(nèi)聚、低耦合”的：

• 高內(nèi)聚：組件本身應(yīng)該盡可能的包含其所實(shí)現(xiàn)功能的所有重要信息和細(xì)節(jié)，以便讓維護(hù)者無需跳轉(zhuǎn)到其它多個(gè)地方去了解必要的知識(shí)。
• 低耦合：組件之間的互相依賴和了解盡可能少，以便在一個(gè)組件需要改動(dòng)時(shí)其它組件不受影響。

其實(shí)這兩者就是一體兩面，做到了高內(nèi)聚基本也就做到了低耦合，相反如果內(nèi)聚度很低，勢必存在大量高耦合的組件。

我觀察發(fā)現(xiàn)，很多項(xiàng)目都存在低內(nèi)聚、高耦合的問題。根本原因在于很多程序員，甚至是很多經(jīng)驗(yàn)豐富的程序員也缺少這方面的意識(shí)——對(duì)“內(nèi)聚性”概念不甚清楚，對(duì)內(nèi)聚性被破壞的危害沒有意識(shí)，對(duì)如何避免更是無從談起。

很多人從一開始就憑直覺寫程序，有了一定經(jīng)驗(yàn)以后一般能認(rèn)識(shí)到重復(fù)代碼的危害，對(duì)復(fù)用性有很強(qiáng)的認(rèn)識(shí)，于是就會(huì)掉進(jìn)一個(gè)陷阱——盲目追求復(fù)用，結(jié)果破壞了內(nèi)聚性。

• 業(yè)界關(guān)于“復(fù)用性”的認(rèn)識(shí)存在一個(gè)誤區(qū)—— 認(rèn)為包括業(yè)務(wù)邏輯組件在內(nèi)的任何層面的組件都應(yīng)該追求最大限度的可復(fù)用性；
• 復(fù)用當(dāng)然是好的，但那應(yīng)該有個(gè)前提條件：不增加系統(tǒng)復(fù)雜度的情況下的復(fù)用，才是好的。
• 什么樣的復(fù)用會(huì)增加系統(tǒng)復(fù)雜性、是不好的呢？前面提到的，一個(gè)業(yè)務(wù)邏輯 API 被另一個(gè)業(yè)務(wù)邏輯 API 復(fù)用——就是不好的：
• 損害了穩(wěn)定性：因?yàn)闃I(yè)務(wù)邏輯本身是跟現(xiàn)實(shí)世界的業(yè)務(wù)掛鉤的，而業(yè)務(wù)會(huì)發(fā)生變化；當(dāng)你復(fù)用一個(gè)會(huì)發(fā)生變化的 API，相當(dāng)于在沙子上建高樓——地基是松動(dòng)的；
• 增加了復(fù)雜性：這樣的依賴還造成代碼可讀性降低——在一個(gè)本就復(fù)雜的業(yè)務(wù)邏輯代碼中，包含了對(duì)另一個(gè)復(fù)雜業(yè)務(wù)邏輯的調(diào)用，復(fù)雜度會(huì)急劇增加，而且會(huì)不斷泛濫和傳遞；
• 內(nèi)聚性被破壞：由于業(yè)務(wù)邏輯被打散在了多個(gè)組件的方法內(nèi)，變得支離破碎，無法在一個(gè)地方看清整體邏輯脈絡(luò)和實(shí)現(xiàn)步驟——內(nèi)聚性被破壞，同時(shí)也意味著，這個(gè)調(diào)用鏈條上涉及的所有組件之間存在高耦合。

4.4 藥方 2：復(fù)用的兩種正確姿勢——打造自己的 lib 和 framework

軟件架構(gòu)中有兩種東西來實(shí)現(xiàn)復(fù)用——lib 和 framework，

• lib 庫是供你（應(yīng)用程序）調(diào)用的，它幫你實(shí)現(xiàn)特定的能力（比如日志、數(shù)據(jù)庫驅(qū)動(dòng)、json 序列化、日期計(jì)算、http 請(qǐng)求）。
• framework 框架是供你擴(kuò)展的，它本身就是半個(gè)應(yīng)用程序，定義好了組件劃分和交互機(jī)制，你需要按照其規(guī)則擴(kuò)展出特定的實(shí)現(xiàn)并綁定集成到其中，來完成一個(gè)應(yīng)用程序。
• lib 就是組合方式的復(fù)用，framework 則是繼承式的復(fù)用，繼承的 Java 關(guān)鍵字是 extends，所以本質(zhì)上是擴(kuò)展。
• 過去有個(gè)說法：“組合優(yōu)于繼承，能用組合解決的問題盡量不要繼承”。我不同意這個(gè)說法，這容易誤導(dǎo)初學(xué)者以為組合優(yōu)于繼承，其實(shí)繼承才是面向?qū)ο笞顝?qiáng)大的地方，當(dāng)然任何東西都不能亂用。
• 典型的繼承亂用就是為了獲得父類的某個(gè) API 而去繼承，繼承一定是為了擴(kuò)展，而不是為了直接獲得一個(gè)能力，獲得能力應(yīng)該調(diào)用 lib，父類不應(yīng)該去實(shí)現(xiàn)具體功能，那是 lib 該做的事。
• 也不應(yīng)該為了使用 lib 而去繼承 lib 中的 Class。lib 就是用來被組合被調(diào)用的，framework 就是用來被繼承、擴(kuò)展的。
• 再展開一下：lib 既可以是第三方的（log4j、httpclient、fastjson），也可是你自己工程的（比如你的持久層 Dao、你的 utils）；
• framework 同理，既可以是第三方的（springmvc、jpa、springsecurity），也可以是你項(xiàng)目內(nèi)封裝的面向具體業(yè)務(wù)領(lǐng)域的（比如 report、excel 導(dǎo)出、paging 或任何可復(fù)用的算法、流程）。
• 從這個(gè)意義上說， 一個(gè)項(xiàng)目中的代碼其實(shí)只有 3 種：自定義的 lib class、自定義的 framework 相關(guān) class、擴(kuò)展第三方或自定義 framework 的組件 class。
• 再擴(kuò)展一下：相對(duì)于過去，現(xiàn)在我們已經(jīng)有了足夠多的第三方 lib 和 framework 來復(fù)用，來幫助項(xiàng)目節(jié)省大量代碼，開發(fā)工作似乎變成了索然無味、沒技術(shù)含量的 CRUD。但是對(duì)于業(yè)務(wù)非常復(fù)雜的項(xiàng)目，則需要有經(jīng)驗(yàn)、有抽象思維、懂設(shè)計(jì)模式的人，去設(shè)計(jì)面向業(yè)務(wù)的 framework 和面向業(yè)務(wù)的 lib，只有這樣才能交付可維護(hù)、可擴(kuò)展、可復(fù)用的軟件架構(gòu)——高質(zhì)量架構(gòu)，幫助項(xiàng)目或產(chǎn)品取得成功。

4.5 癥結(jié) 3：抽象不夠、邏輯糾纏——High Level 業(yè)務(wù)邏輯和 Low Level 實(shí)現(xiàn)邏輯糾纏

當(dāng)我們說“代碼中包含的業(yè)務(wù)邏輯”的時(shí)候，我們到底在說什么？業(yè)界并沒有一個(gè)標(biāo)準(zhǔn)，大家經(jīng)常講的 CRUD 增刪改查其實(shí)屬于更底層的數(shù)據(jù)訪問邏輯。

我的觀點(diǎn)是：所謂代碼中的業(yè)務(wù)邏輯，是指這段代碼所表現(xiàn)出的所有輸入輸出規(guī)則、算法和行為，通?？梢苑譃橐韵?5 類：

• 輸入合法性校驗(yàn)；
• 業(yè)務(wù)規(guī)則校驗(yàn)：典型的如檢查交易記錄狀態(tài)、金額、時(shí)限、權(quán)限等，通常包含數(shù)據(jù)庫或外部接口的查詢作為參考；
• 數(shù)據(jù)持久化行為：數(shù)據(jù)庫、緩存、文件、日志等任何形式的數(shù)據(jù)寫入行為；
• 外部接口調(diào)用行為；
• 輸出/返回值準(zhǔn)備。

當(dāng)然具體到某一個(gè)組件實(shí)例，可能不會(huì)包括上述全部 5 類業(yè)務(wù)邏輯，但是也可能每一類業(yè)務(wù)邏輯存在多個(gè)。

單這樣看你可能覺得并不是特別復(fù)雜，但是現(xiàn)實(shí)中上述 5 類業(yè)務(wù)邏輯中的每一個(gè)通常還包含著一到多個(gè)底層實(shí)現(xiàn)邏輯，如 CRUD 數(shù)據(jù)訪問邏輯或第三方 API 的調(diào)用。

例如輸入合法性校驗(yàn)，通常需要查詢對(duì)應(yīng)記錄是否存在，外部接口調(diào)用前通常需要查詢相關(guān)記錄以獲得調(diào)用接口需要的參數(shù)，調(diào)用接口后還需要根據(jù)結(jié)果更新相關(guān)記錄狀態(tài)。

顯然這里存在兩個(gè) Level 的邏輯——High Level 的與業(yè)務(wù)需求對(duì)應(yīng)且關(guān)聯(lián)緊密的邏輯、Low Level 的實(shí)現(xiàn)邏輯。

如果對(duì)兩個(gè) Level 的邏輯不加以區(qū)分、混為一談，代碼質(zhì)量立刻就會(huì)遭到嚴(yán)重?fù)p害：

• 可讀性變差：兩個(gè)維度的復(fù)雜性——業(yè)務(wù)復(fù)雜性和底層實(shí)現(xiàn)的技術(shù)復(fù)雜性——被摻雜在了一起，復(fù)雜度 1+1>2 劇增，給其他人閱讀代碼增加很大負(fù)擔(dān)；
• 可維護(hù)性差：可維護(hù)性通常指排查和解決問題所需花費(fèi)的代價(jià)高低，當(dāng)兩個(gè) level 的邏輯糾纏在一起，會(huì)使排查問題變的更困難，修復(fù)問題時(shí)也更容易出錯(cuò)；
• 可擴(kuò)展性無從談起：擴(kuò)展性通常指為系統(tǒng)增加一個(gè)特性所需花費(fèi)的代價(jià)高低，代價(jià)越高擴(kuò)展性越差；與排查修復(fù)問題類似，邏輯糾纏顯然也會(huì)使添加新特性變得困難、一不小心就破壞了已有功能。

下面這段代碼就是一個(gè)典型案例——High Level 的邏輯流程（參數(shù)獲取、反序列化、參數(shù)校驗(yàn)、緩存寫入、數(shù)據(jù)庫持久化、更新相關(guān)交易記錄）完全淹沒在了 Low Level 的實(shí)現(xiàn)邏輯（字符串比較、Json 反序列化、redis 操作、dao 操作以及前后各種瑣碎的參數(shù)準(zhǔn)備和返回值處理）。下一節(jié)我會(huì)針對(duì)這段問題代碼給出重構(gòu)方案。

@Overridepublic void updateFromMQ(String compress) { try { JSONObject object = JSON.parseObject(compress); if (StringUtils.isBlank(object.getString("type")) || StringUtils.isBlank(object.getString("mobile")) || StringUtils.isBlank(object.getString("data"))){ throw new AppException("MQ返回參數(shù)異常"); } logger.info(object.getString("mobile")+"<<<<<<<<<獲取來自MQ的授權(quán)數(shù)據(jù)>>>>>>>>>"+object.getString("type")); Map map = new HashMap(); map.put("type",CrawlingTaskType.get(object.getInteger("type"))); map.put("mobile", object.getString("mobile")); List list = baseDAO.find("from crt c where c.phoneNumber=:mobile and c.taskType=:type", map); redisClientTemplate.set(object.getString("mobile") + "_" + object.getString("type"),CompressUtil.compress( object.getString("data"))); redisClientTemplate.expire(object.getString("mobile") + "_" + object.getString("type"), 2*24*60*60); //保存成功 存入redis 保存48小時(shí) CrawlingTask crawlingTask = null; // providType:（0：新顏，1XX支付寶，2：ZZ淘寶,3:TT淘寶） if (CollectionUtils.isNotEmpty(list)){ crawlingTask = list.get(0); crawlingTask.setJsonStr(object.getString("data")); }else{ //新增 crawlingTask = new CrawlingTask(UUID.randomUUID().toString(), object.getString("data"), object.getString("mobile"), CrawlingTaskType.get(object.getInteger("type"))); crawlingTask.setNeedUpdate(true); } baseDAO.saveOrUpdate(crawlingTask); //保存芝麻分到xyz if ("3".equals(object.getString("type"))){ String data = object.getString("data"); Integer zmf = JSON.parseObject(data).getJSONObject("taobao_user_info").getInteger("zm_score"); Map param = new HashMap(); param.put("phoneNumber", object.getString("mobile")); List list1 = personBaseDaoI.find("from xyz where phoneNumber=:phoneNumber", param); if (list1 !=null){ for (Dperson dperson:list1){ dperson.setZmScore(zmf); personBaseDaoI.saveOrUpdate(dperson); AppFlowUtil.updateAppUserInfo(dperson.getToken(),null,null,zmf);//查詢多租戶表 身份認(rèn)證、淘寶認(rèn)證 為0 置為1 } } } } catch (Exception e) { logger.error("更新my MQ授權(quán)信息失敗", e); throw new AppException(e.getMessage(),e); }}

4.6 藥方 3：控制邏輯分離——業(yè)務(wù)模板 Pattern of NestedBusinessTemplate

解決“邏輯糾纏”最關(guān)鍵是要找到一種隔離機(jī)制，把兩個(gè) Level 的邏輯分開——控制邏輯分離，分離的好處很多：

• 根據(jù)經(jīng)驗(yàn)，當(dāng)我們著手維護(hù)一段代碼時(shí)，一定是想先弄清楚它的整體流程、算法和行為，而不是一上來就去研究它的細(xì)枝末節(jié)；
• 控制邏輯分離后，只需要去看 High Level 部分就能了解到上述內(nèi)容，閱讀代碼的負(fù)擔(dān)大幅度降低，代碼可讀性顯著增強(qiáng)；
• 讀懂代碼是后續(xù)一切維護(hù)、重構(gòu)工作的前提，而且一份代碼被讀的次數(shù)遠(yuǎn)遠(yuǎn)高于被修改的次數(shù)（高一個(gè)數(shù)量級(jí)），因此代碼對(duì)人的可讀性再怎么強(qiáng)調(diào)都不為過，可讀性增強(qiáng)可以大幅度提高系統(tǒng)可維護(hù)性，也是重構(gòu)的最主要目標(biāo)。
• 同時(shí)，根據(jù)我的經(jīng)驗(yàn)，High Level 業(yè)務(wù)邏輯的變更往往比 Low Level 實(shí)現(xiàn)邏輯變更要來的頻繁，畢竟前者跟業(yè)務(wù)直接對(duì)應(yīng)。當(dāng)然不同類型項(xiàng)目情況不一樣，另外它們發(fā)生變更的時(shí)間點(diǎn)往往也不同；
• 在這樣的背景下，控制邏輯分離的好處就更明顯了：每次維護(hù)、擴(kuò)充系統(tǒng)功能只需改動(dòng)一個(gè) Levle 的代碼，另一個(gè) Level 不受影響或影響很小，這會(huì)大幅降低修改成本和風(fēng)險(xiǎn)。

我在總結(jié)過去多個(gè)項(xiàng)目中的教訓(xùn)和經(jīng)驗(yàn)后，總結(jié)出了一項(xiàng)最佳實(shí)踐或者說是設(shè)計(jì)模式——業(yè)務(wù)模板 Pattern of NestedBusinessTemplat，可以非常簡單、有效的分離兩類邏輯，先看代碼：

public class XyzService {
abstract class AbsUpdateFromMQ { public final void doProcess(String jsonStr) { try { JSONObject json = doParseAndValidate(jsonStr); cache2Redis(json); saveJsonStr2CrawingTask(json); updateZmScore4Dperson(json); } catch (Exception e) { logger.error("更新my MQ授權(quán)信息失敗", e); throw new AppException(e.getMessage(), e); } } protected abstract void updateZmScore4Dperson(JSONObject json); protected abstract void saveJsonStr2CrawingTask(JSONObject json); protected abstract void cache2Redis(JSONObject json); protected abstract JSONObject doParseAndValidate(String json) throws AppException;}

@SuppressWarnings({ "unchecked", "rawtypes" })public void processAuthResultDataCallback(String compress) { new AbsUpdateFromMQ() {@Overrideprotected void updateZmScore4Dperson(JSONObject json) { //保存芝麻分到xyz if ("3".equals(json.getString("type"))){ String data = json.getString("data"); Integer zmf = JSON.parseObject(data).getJSONObject("taobao_user_info").getInteger("zm_score"); Map param = new HashMap(); param.put("phoneNumber", json.getString("mobile")); List list1 = personBaseDaoI.find("from xyz where phoneNumber=:phoneNumber", param); if (list1 !=null){ for (Dperson dperson:list1){ dperson.setZmScore(zmf); personBaseDaoI.saveOrUpdate(dperson); AppFlowUtil.updateAppUserInfo(dperson.getToken(),null,null,zmf); } } }} @Overrideprotected void saveJsonStr2CrawingTask(JSONObject json) { Map map = new HashMap(); map.put("type",CrawlingTaskType.get(json.getInteger("type"))); map.put("mobile", json.getString("mobile")); List list = baseDAO.find("from crt c where c.phoneNumber=:mobile and c.taskType=:type", map); CrawlingTask crawlingTask = null; // providType:（0：xx，1yy支付寶，2：zz淘寶,3:tt淘寶） if (CollectionUtils.isNotEmpty(list)){ crawlingTask = list.get(0); crawlingTask.setJsonStr(json.getString("data")); }else{ //新增 crawlingTask = new CrawlingTask(UUID.randomUUID().toString(), json.getString("data"), json.getString("mobile"), CrawlingTaskType.get(json.getInteger("type"))); crawlingTask.setNeedUpdate(true); } baseDAO.saveOrUpdate(crawlingTask);}
@Overrideprotected void cache2Redis(JSONObject json) { redisClientTemplate.set(json.getString("mobile") + "_" + json.getString("type"),CompressUtil.compress( json.getString("data"))); redisClientTemplate.expire(json.getString("mobile") + "_" + json.getString("type"), 2*24*60*60);}
@Overrideprotected JSONObject doParseAndValidate(String json) throws AppException { JSONObject object = JSON.parseObject(json); if (StringUtils.isBlank(object.getString("type")) || StringUtils.isBlank(object.getString("mobile")) || StringUtils.isBlank(object.getString("data"))){ throw new AppException("MQ返回參數(shù)異常"); } logger.info(object.getString("mobile")+"<<<<<<<<<獲取來自MQ的授權(quán)數(shù)據(jù)>>>>>>>>>"+object.getString("type")); return object; } }.doProcess(compress);}

如果你熟悉經(jīng)典的 GOF23 種設(shè)計(jì)模式，很容易發(fā)現(xiàn)上面的代碼示例其實(shí)就是 Template Method 設(shè)計(jì)模式的運(yùn)用，沒什么新鮮的。

沒錯(cuò)，我這個(gè)方案沒有提出和創(chuàng)造任何新東西，我只是在實(shí)踐中偶然發(fā)現(xiàn) Template Method 設(shè)計(jì)模式真的非常適合解決廣泛存在的邏輯糾纏問題，而且也發(fā)現(xiàn)很少有程序員能主動(dòng)運(yùn)用這個(gè)設(shè)計(jì)模式；一部分原因可能是意識(shí)到“邏輯糾纏”問題的人本就不多，同時(shí)熟悉這個(gè)設(shè)計(jì)模式并能自如運(yùn)用的人也不算多，兩者的交集自然就是少得可憐；不管是什么原因，結(jié)果就是這個(gè)問題廣泛存在成了通病。

我看到一部分對(duì)代碼質(zhì)量有追求的程序員 他們的解決辦法是通過"結(jié)構(gòu)化編程"和“模塊化編程”：

• 把 Low Level 邏輯提取成 private function，被 High Level 代碼所在的 function 直接調(diào)用；
• 問題 1 硬連接不靈活：首先，這樣雖然起到了一定的隔離效果，但是兩個(gè) level 之間是靜態(tài)的硬關(guān)聯(lián)，Low Level 無法被簡單的替換，替換時(shí)還是需要修改和影響到 High Level 部分；
• 問題 2 組件內(nèi)可見性造成混亂：提取出來的 private function 在當(dāng)前組件內(nèi)是全局可見的——對(duì)其它無關(guān)的 High Level function 也是可見的，各個(gè)模塊之間仍然存在邏輯糾纏。這在很多項(xiàng)目中的熱點(diǎn)代碼中很常見，問題也很突出：試想一個(gè)包含幾十個(gè) API 的組件，每個(gè) API 的 function 存在一兩個(gè)關(guān)聯(lián)的 private function，那這個(gè)組件內(nèi)部的混亂程度、維護(hù)難度是難以承受的。
• 把 Low Level 邏輯抽取到新的組件中，供 High Level 代碼所在的組件依賴和調(diào)用；更有經(jīng)驗(yàn)的程序員可能會(huì)增加一層接口并且借助 Spring 依賴注入；
• 問題 1 API 泛濫：提取出新的組件似乎避免了“結(jié)構(gòu)化編程”的局限性，但是帶來了新的問題——API 泛濫：因?yàn)榻M件之間調(diào)用只能走 public 方法，而這個(gè) API 其實(shí)沒有太多復(fù)用機(jī)會(huì)根本沒必要做成 public 這種最高可見性。
• 問題 2 同層組件依賴失控：組件和 API 泛濫后必然導(dǎo)致組件之間互相依賴成為常態(tài)，慢慢變得失控以后最終變成所有組件都依賴其它大部分組件，甚至出現(xiàn)循環(huán)依賴；比如那個(gè)擁有 130 個(gè) import 和 40 個(gè) Spring 依賴組件的 ContractService。

下面介紹一下 Template Method 設(shè)計(jì)模式的運(yùn)用，簡單歸納就是：

• High Level邏輯封裝在抽象父類AbsUpdateFromMQ的一個(gè)final function中，形成一個(gè)業(yè)務(wù)邏輯的模板；
• final function保證了其中邏輯不會(huì)被子類有意或無意的篡改破壞，因此其中封裝的一定是業(yè)務(wù)邏輯中那些相對(duì)固定不變的東西。至于那些可變的部分以及暫時(shí)不確定的部分，以abstract protected function形式預(yù)留擴(kuò)展點(diǎn)；
• 子類（一個(gè)匿名內(nèi)部類）像“做填空題”一樣，填充模板實(shí)現(xiàn)Low Level邏輯——實(shí)現(xiàn)那些protected function擴(kuò)展點(diǎn)；由于擴(kuò)展點(diǎn)在父類中是abstract的，因此編譯器會(huì)提醒子類的程序員該擴(kuò)展什么。

那么它是如何避免上面兩個(gè)方案的 4 個(gè)局限性的：

• Low Level 需要修改或替換時(shí)，只需從父類擴(kuò)展出一個(gè)新的子類，父類全然不知無需任何改動(dòng)；
• 無論是父類還是子類，其中的 function 對(duì)外層的 XyzService 組件都是不可見的，即便是父類中的 public function 也不可見，因?yàn)橹挥谐钟蓄惖膶?shí)例對(duì)象才能訪問到其中的 function；
• 無論是父類還是子類，它們都是作為 XyzService 的內(nèi)部類存在的，不會(huì)增加新的 java 類文件更不會(huì)增加大量無意義的 API（API 只有在被項(xiàng)目內(nèi)復(fù)用或發(fā)布出去供外部使用才有意義，只有唯一的調(diào)用者的 API 是沒有必要的）；
• 組件依賴失控的問題當(dāng)然也就不存在了。

SpringFramework 等框架型的開源項(xiàng)目中，其實(shí)早已大量使用 Template Method 設(shè)計(jì)模式，這本該給我們這些應(yīng)用開發(fā)程序員帶來啟發(fā)和示范，但是很可惜業(yè)界沒有注意到和充分發(fā)揮它的價(jià)值。

NestedBusinessTemplat 模式就是對(duì)其充分和積極的應(yīng)用，前面一節(jié)提到過的復(fù)用的兩種正確姿勢——打造自己的 lib 和 framework，其實(shí) NestedBusinessTemplat 就是項(xiàng)目自身的 framework。

4.7 癥結(jié) 4：無處不在的 if else 牛皮癬

無論你的編程啟蒙語言是什么，最早學(xué)會(huì)的邏輯控制語句一定是 if else，但是不幸的是它在你開始真正的編程工作以后，會(huì)變成一個(gè)損害項(xiàng)目質(zhì)量的壞習(xí)慣。

幾乎所有的項(xiàng)目都存在 if else 泛濫的問題，但是卻沒有引起足夠重視警惕，甚至被很多程序員認(rèn)為是正?，F(xiàn)象。

首先我來解釋一下為什么 if else 這個(gè)看上去人畜無害的東西是有害的、是需要嚴(yán)格管控的：

• if else if ...else 以及類似的 switch 控制語句，本質(zhì)上是一種 hard coding 硬編碼行為，如果你同意“magic number 魔法數(shù)字”是一種錯(cuò)誤的編程習(xí)慣，那么同理，if else 也是錯(cuò)誤的 hard coding 編程風(fēng)格；
• hard coding 的問題在于當(dāng)需求發(fā)生改變時(shí)，需要到處去修改，很容易遺漏和出錯(cuò)；
• 以一段代碼為例來具體分析：

if ("3".equals(object.getString("type"))){ String data = object.getString("data"); Integer zmf = JSON.parseObject(data).getJSONObject("taobao_user_info").getInteger("zm_score"); Map param = new HashMap(); param.put("phoneNumber", object.getString("mobile")); List list1 = personBaseDaoI.find("from xyz where phoneNumber=:phoneNumber", param); if (list1 !=null){ for (Dperson dperson:list1){ dperson.setZmScore(zmf); personBaseDaoI.saveOrUpdate(dperson); AppFlowUtil.updateAppUserInfo(dperson.getToken(),null,null,zmf); } }}

• if ("3".equals(object.getString("type")))
• 顯然這里的"3"是一個(gè) magic number，沒人知道 3 是什么含義，只能推測；
• 但是僅僅將“3”重構(gòu)成常量 ABC_XYZ 并不會(huì)改善多少，因?yàn)?if (ABC_XYZ.equals(object.getString("type"))) 仍然是面向過程的編程風(fēng)格，無法擴(kuò)展；
• 到處被引用的常量 ABC_XYZ 并沒有比到處被 hard coding 的 magic number 好多少，只不過有了含義而已；
• 把常量升級(jí)成 Enum 枚舉類型呢，也沒有好多少，當(dāng)需要判斷的類型增加了或判斷的規(guī)則改變了，還是需要到處修改——Shotgun Surgery(霰彈式修改)
• 并非所有的 if else 都有害，比如上面示例中的 if (list1 !=null) { 就是無害的，沒有必要去消除，也沒有消除它的可行性。判斷是否有害的依據(jù)：
• 如果 if 判斷的變量狀態(tài)只有兩種可能性（比如 boolean、比如 null 判斷）時(shí)，是無傷大雅的；
• 反之，如果 if 判斷的變量存在多種狀態(tài)，而且將來可能會(huì)增加新的狀態(tài)，那么這就是個(gè)問題；
• switch 判斷語句無疑是有害的，因?yàn)槭褂?switch 的地方往往存在很多種狀態(tài)。

4.8 藥方 4：充血枚舉類型——Rich Enum Type

正如前面分析呈現(xiàn)的那樣，對(duì)于代碼中廣泛存在的狀態(tài)、類型 if 條件判斷，僅僅把被比較的值重構(gòu)成常量或 enum 枚舉類型并沒有太大改善——使用者仍然直接依賴具體的枚舉值或常量，而不是依賴一個(gè)抽象。

于是解決方案就自然浮出水面了：在 enum 枚舉類型基礎(chǔ)上進(jìn)一步抽象封裝，得到一個(gè)所謂的“充血”的枚舉類型，代碼說話：

• 實(shí)現(xiàn)多種系統(tǒng)通知機(jī)制，傳統(tǒng)做法:

enum NOTIFY_TYPE { email,sms,wechat; } //先定義一個(gè)enum——一個(gè)只定義了值不包含任何行為的“貧血”的枚舉類型
if(type==NOTIFY_TYPE.email){ //if判斷類型 調(diào)用不同通知機(jī)制的實(shí)現(xiàn)  。。。}else if (type=NOTIFY_TYPE.sms){ 。。。}else{ 。。。}

• 實(shí)現(xiàn)多種系統(tǒng)通知方式，充血枚舉類型——Rich Enum Type 模式:

enum NOTIFY_TYPE { //1、定義一個(gè)包含通知實(shí)現(xiàn)機(jī)制的“充血”的枚舉類型 email("郵件",NotifyMechanismInterface.byEmail()), sms("短信",NotifyMechanismInterface.bySms()), wechat("微信",NotifyMechanismInterface.byWechat());   String memo; NotifyMechanismInterface notifyMechanism;  private NOTIFY_TYPE(String memo,NotifyMechanismInterface notifyMechanism){//2、私有構(gòu)造函數(shù)，用于初始化枚舉值 this.memo=memo; this.notifyMechanism=notifyMechanism; } //getters ...}
public interface NotifyMechanismInterface{ //3、定義通知機(jī)制的接口或抽象父類 public boolean doNotify(String msg);  public static NotifyMechanismInterface byEmail(){//3.1 返回一個(gè)定義了郵件通知機(jī)制的策的實(shí)現(xiàn)——一個(gè)匿名內(nèi)部類實(shí)例 return new NotifyMechanismInterface(){ public boolean doNotify(String msg){ ....... } }; } public static NotifyMechanismInterface bySms(){//3.2 定義短信通知機(jī)制的實(shí)現(xiàn)策略 return new NotifyMechanismInterface(){ public boolean doNotify(String msg){ ....... } }; }  public static NotifyMechanismInterface byWechat(){//3.3 定義微信通知機(jī)制的實(shí)現(xiàn)策略 return new NotifyMechanismInterface(){ public boolean doNotify(String msg){ ....... } }; }}
//4、使用場景NOTIFY_TYPE.valueof(type).getNotifyMechanism().doNotify(msg);

• 充血枚舉類型——Rich Enum Type 模式的優(yōu)勢：
• 不難發(fā)現(xiàn)，這其實(shí)就是 enum 枚舉類型和 Strategy Pattern 策略模式的巧妙結(jié)合運(yùn)用；
• 當(dāng)需要增加新的通知方式時(shí)，只需在枚舉類 NOTIFY_TYPE 增加一個(gè)值，同時(shí)在策略接口 NotifyMechanismInterface 中增加一個(gè) by 方法返回對(duì)應(yīng)的策略實(shí)現(xiàn)；
• 當(dāng)需要修改某個(gè)通知機(jī)制的實(shí)現(xiàn)細(xì)節(jié)，只需修改 NotifyMechanismInterface 中對(duì)應(yīng)的策略實(shí)現(xiàn)；
• 無論新增還是修改通知機(jī)制，調(diào)用方完全不受影響，仍然是 NOTIFY_TYPE.valueof(type).getNotifyMechanism().doNotify(msg);
• 與傳統(tǒng) Strategy Pattern 策略模式的比較優(yōu)勢：常見的策略模式也能消滅 if else 判斷，但是實(shí)現(xiàn)起來比較麻煩，需要開發(fā)更多的 class 和代碼量：
• 每個(gè)策略實(shí)現(xiàn)需單獨(dú)定義成一個(gè) class；
• 還需要一個(gè) Context 類來做初始化——用 Map 把類型與對(duì)應(yīng)的策略實(shí)現(xiàn)做映射；
• 使用時(shí)從 Context 獲取具體的策略；
• Rich Enum Type 的進(jìn)一步的充血：
• 上面的例子中的枚舉類型包含了行為，因此已經(jīng)算作充血模型了，但是還可以為其進(jìn)一步充血；
• 例如有些場景下，只是要對(duì)枚舉值做個(gè)簡單的計(jì)算獲得某種 flag 標(biāo)記，那就沒必要把計(jì)算邏輯抽象成 NotifyMechanismInterface 那樣的接口，殺雞用了牛刀；
• 這時(shí)就可以在枚舉類型中增加 static function 封裝簡單的計(jì)算邏輯；
• 策略實(shí)現(xiàn)的進(jìn)一步抽象：
• 當(dāng)各個(gè)策略實(shí)現(xiàn)（byEmail bySms byWechat）存在共性部分、重復(fù)邏輯時(shí)，可以將其抽取成一個(gè)抽象父類；
• 然后就像前一章節(jié)——業(yè)務(wù)模板 Pattern of NestedBusinessTemplate 那樣，在各個(gè)子類之間實(shí)現(xiàn)優(yōu)雅的邏輯分離和復(fù)用。

5. 重構(gòu)前的火力偵察：為你的項(xiàng)目編制一套代碼庫目錄/索引——CODEX

以上就是我總結(jié)出的最常見也最影響代碼質(zhì)量的 4 個(gè)問題及其解決方案：

• 職責(zé)單一、小顆粒度、高內(nèi)聚、低耦合的業(yè)務(wù)邏輯層組件——倒金字塔結(jié)構(gòu)；
• 打造項(xiàng)目自身的 lib 層和 framework——正確的復(fù)用姿勢；
• 業(yè)務(wù)模板 Pattern of NestedBusinessTemplate——控制邏輯分離；
• 充血的枚舉類型 Rich Enum Type——消滅硬編碼風(fēng)格的 if else 條件判斷；

接下來就是如何動(dòng)手去針對(duì)這 4 個(gè)方面進(jìn)行重構(gòu)了，但是事情還沒有那么簡單。

上面所有的內(nèi)容雖然來自實(shí)踐經(jīng)驗(yàn)，但是要應(yīng)用到你的具體項(xiàng)目，還需要一個(gè)步驟——火力偵察——弄清楚你要重構(gòu)的那個(gè)模塊的邏輯脈絡(luò)、算法以致實(shí)現(xiàn)細(xì)節(jié)，否則貿(mào)然動(dòng)手，很容易遺漏關(guān)鍵細(xì)節(jié)造成風(fēng)險(xiǎn)，重構(gòu)的效率更難以保證，陷入進(jìn)退兩難的尷尬境地。

我 2019 年一整年經(jīng)歷了 3 個(gè)代碼十分混亂的項(xiàng)目，最大的收獲就是摸索出了一個(gè)梳理爛代碼的最佳實(shí)踐——CODEX：

• 在閱讀代碼過程中，在關(guān)鍵位置添加結(jié)構(gòu)化的注釋，形如：//CODEX ProjectA 1 體檢預(yù)約流程 1 預(yù)約服務(wù) API 入口

• 所謂結(jié)構(gòu)化注釋，就是在注釋內(nèi)容中通過規(guī)范命名的編號(hào)前綴、分隔符等來體現(xiàn)出其所對(duì)應(yīng)的項(xiàng)目、模塊、流程步驟等信息，類似文本編輯中的標(biāo)題 1、2、3；
• 然后設(shè)置 IDE 工具識(shí)別這種特殊的注釋，以便結(jié)構(gòu)化的顯示。Eclipse 的 Tasks 顯示效果類似下圖；

• 這個(gè)結(jié)構(gòu)化視圖，本質(zhì)上相對(duì)于是代碼庫的索引、目錄，不同于 javadoc 文檔，CODEX 具有更清晰的邏輯層次和更強(qiáng)的代碼查找便利性，在 Eclipse Tasks 中點(diǎn)擊就能跳轉(zhuǎn)到對(duì)應(yīng)的代碼行；
• 這些結(jié)構(gòu)化注釋隨著代碼一起提交后就實(shí)現(xiàn)了團(tuán)隊(duì)共享；
• 這樣的一份精確無誤、共享的、活的源代碼索引，無疑會(huì)對(duì)整個(gè)團(tuán)隊(duì)的開發(fā)維護(hù)工作產(chǎn)生巨大助力；
• 進(jìn)一步的，如果在 CODEX 中添加 Markdown 關(guān)鍵字，甚至可以將導(dǎo)出的 CODEX 簡單加工后，變成一張業(yè)務(wù)邏輯的 Sequence 序列圖，如下所示。

6. 總結(jié)陳詞——不要辜負(fù)這個(gè)程序員最好的時(shí)代

毫無疑問這是程序員最好的時(shí)代，互聯(lián)網(wǎng)浪潮已經(jīng)席卷了世界每個(gè)角落，各行各業(yè)正在越來越多的依賴 IT。過去只有軟件公司、互聯(lián)網(wǎng)公司和銀行業(yè)會(huì)雇傭程序員，隨著云計(jì)算的普及、產(chǎn)業(yè)互聯(lián)網(wǎng)和互聯(lián)網(wǎng)+興起，已經(jīng)有越來越多的傳統(tǒng)企業(yè)開始雇傭程序員搭建 IT 系統(tǒng)來支撐業(yè)務(wù)運(yùn)營。

資本的推動(dòng) IT 需求的旺盛，使得程序員成了稀缺人才，各大招聘平臺(tái)上，程序員的崗位數(shù)量和薪資水平長期名列前茅。

但是我們這個(gè)群體的整體表現(xiàn)怎么樣呢，捫心自問，我覺得很難令人滿意，我所經(jīng)歷過的以及近距離觀察到的項(xiàng)目，鮮有能夠稱得上成功的。這里的成功不是商業(yè)上的成功，僅限于作為一個(gè)軟件項(xiàng)目和工程是否能夠以可接受的成本和質(zhì)量長期穩(wěn)定的交付。

商業(yè)的短期成功與否，很多時(shí)候與項(xiàng)目工程的成功與否沒有必然聯(lián)系，一個(gè)商業(yè)上很成功的項(xiàng)目可能在工程上做的并不好，只是通過巨量的資金資源投入換來的暫時(shí)成功而已。

歸根結(jié)底，我們程序員群體需要為自己的聲譽(yù)負(fù)責(zé)，長期來看也終究會(huì)為自己的聲譽(yù)獲益或受損。

我認(rèn)為程序員最大的聲譽(yù)、最重要的職業(yè)素養(yǎng)，就是通過寫出高質(zhì)量的代碼做好一個(gè)個(gè)項(xiàng)目、產(chǎn)品，來幫助團(tuán)隊(duì)、幫助公司、幫助組織創(chuàng)造價(jià)值、增加成功的機(jī)會(huì)。

希望本文分享的經(jīng)驗(yàn)和方法能夠?qū)Υ擞兴鶐椭?/p>

本文是我的一位技術(shù)總監(jiān)好友：權(quán)哥花了半個(gè)月時(shí)間寫出來的良心文章，強(qiáng)烈推薦給大家，文章很長很硬很有價(jià)值，大家可以收藏多看幾遍。希望大家看完之后轉(zhuǎn)發(fā)、點(diǎn)在看，好文章要讓更多的人看到。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：

長按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠摯感謝