這麼糟糕的代碼，真的是我以前寫的嗎？

關鍵時刻，第一時間送達！

作者簡介：Zm，愛生活，愛分享。近五年的實際開發經驗，多個項目的積累與總結，在代碼中經歷太多的喜怒哀樂。

本文來自作者 Zm 在 GitChat 上分享 「日常開發與設計模式的那點事」。

【作者按】很多程序員不知道怎麼組織代碼、怎麼提升效率、怎麼提高代碼的可維護性、可重用性、可擴展性、靈活性，寫出來的代碼一團糟，但這樣一團糟的代碼居然能正常運行。

這樣的代碼經歷，你是否也似曾相識？

身邊好多程序員都會有這樣的一個經歷，過個一年半載再去查看曾經寫下的代碼時，很吃驚的在想，這麼糟糕的代碼，真的是我以前寫的嗎？我居然能寫出這麼糟糕的代碼！

而對於還在維護的代碼，此時，會萌生一種去重構的想法，或者會有一種更好的方式去實現。此時，你與代碼的愛恨情仇已經開始了……

本篇主要從六大基本原則說起，作為設計模式的引子，敘述六大基本原則和設計模式的關係，後續會一篇一個設計模式，詳細介紹設計模式與日常開發。

基本的規範和約束

對於基本的規範和約束，我相信每個合格的團隊都會有一套自己的玩意，一方面統一標準，增加可讀性和可維護性，另一方面也方便離職後出現 Bug，後來者也能更快的去定位並解決問題。

雜亂無章的代碼實現一個大功能，對於後來者去維護，無疑會親切的問候各路祖宗。一個好的編碼習慣，屬於一個合格程序員的自我修養，於己於人，百利而無一害。

對於開發中的規範和約束，第一個要說的就是命名。

這五年多的工作，和形形色色的人合作過，記得最多的時候，我曾同時期開發和維護五個項目，業餘時間，也曾和各路英雄好漢互相合作、互相學習和共同進步，在這個過程中，最讓我覺得頭疼的就是一些命名的不規範。

不規範的樣式有很多，各種奇怪的命名都有。我曾看到過這樣一串命名，其中有兩個功能，一個叫做專欄詳情，一個叫做專欄留言，命名卻是 「ZhuanLaiDetalActivity」 和 「ZhuanLaiLiuYanActivity」，看得我很懵。

這樣的命名，就問你怕不怕！對於這樣的命名都怕了，那真沒見過世面，這個至少還能看出個大概，之前看到過一些漢語拼音的縮寫，比如動檢證命名為 djz，這個看起來才更懵了。

對於拼音命名，這裡說一點不知道會不會被噴，遇到過一些朋友總是喜歡拼音命名，漢語拼音是中華民族推動漢文化的偉大創舉，但是在編程的時候用拼音，真的覺得好 low。

即使再牛逼的技術作支撐，寫出來的代碼也像小學生的作品，這裡沒有看不起漢語拼音的意思，只是發表下內心的一些想法。

建議：大駝峰、小駝峰或者下劃線命名都可以，如果沒有一個統一的標準，可以參考《阿里巴巴 Java 開發手冊》，對於剛入行的朋友，更應該從命名抓起，對於以後的成長有很大的幫助。

開發手冊下載地址：https://pan.baidu.com/s/1mjZxvSW。

再者要強調的就是注釋。很多人也許覺得注釋是越多越好，之前也在書上看到過提倡多加註釋，我覺得不然，有些時候注釋給我們增加了很多負擔和誤解。

上次 Review 的時候發現，一些同事 Copy 我的一些代碼的時候，其實是想做另一個功能，只是想把一些代碼拷貝過去然後大修改（我不喜歡重複造輪子，對於相似的一些功能，最好做的靈活一點，提高代碼的可重用性和靈活性）。

其實可以重用的地方很少，搞不明白為啥不自己寫那麼幾行代碼，這都不是事，讓我很懵逼的是他們把我的備註和作者也拷貝過去了，當我進入那個類的時候，發現作者是我，去 Git 查看歷史提交，完全沒我啥事，而且功能描述和此類完全不相關……

對於注釋，還有一點要說的就是一些多餘的注釋，這個叫需要和命名相結合，好的命名規範，可以省略好多不必要注釋，比如 login、register，再加上登錄、註冊的注釋，完全沒必要。

良好的習慣，可以給我們開發帶來很多便捷，但有些喜歡 textview1、textview2 命名的，這些就算加了注釋，等下文用到的時候，看了也是一群羊駝在奔跑，上下奔騰的那種。

對於這樣的代碼，可能很多人會覺得很正常，也會有部分人會把責任歸咎於譚浩強老師，是的，譚老的書中問題確實很多，但這不是寫這種代碼的理由。

日常開發中，還有平時維護別人代碼的同時，總會去調試 for 語句，難道不覺得這樣的代碼很糟糕，看得有點懵嗎？就算加了注釋，還是一坨一坨的。

因為每個團隊有自己的規範和約束，大的公司，會有一套自己的規範，統一於各個團隊，不同的語言也有不同的約束，如果日後有時間，會專門寫一篇詳細的約束與規範的 Blog 贈送。

對於這塊，想寫的東西真的好多好多，比如 case 後面的亂用，1、2、3 總是讓人費解，比如必要的常量替代變數，比如線程池取代線程，比如必要的地方使用單例，東西真的好多好多，不再比如下去了，今天就先說明兩條重點，命名和注釋。

建議：合理使用注釋，對於新手在學習期間，在陌生的代碼和不清晰的邏輯上，儘可能多一點注釋，便於理解，對於老鳥，儘可能規範的命名。

通過命名達到注釋的效果，但是對於邏輯複雜或者操作狀態太多的時候，必要的注釋還是很重要的，減小維護成本。

一些應該熟知的編程思想

一個程序員用在寫程序上的時間大概占他的工作時間的 10-20%，大部分的程序員每天大約能寫出 10-12 行的能進入最終的產品的代碼——不管他的技術水平有多高。

好的程序員花去 90% 的時間在思考、研究和實驗，來找出最優方案。差的程序員花去 90% 的時間在調試問題程序、盲目的修改程序，期望某種寫法能可行。

對於一個優秀的程序員來說，邏輯才是最重要的，他們願意花更多的時間做思考，這樣做的同時，就是更少 Bug 會出現，甚至可以把 Bug 率降到很低。

我並不是很優秀的開發者，但這些年依然有這麼一個習慣，對於複雜或者多樣的功能，總會先理清思路，先列舉出會有哪些操作，哪些地方是 Bug 的雷區應該多注意，我也經常會和隊友提起，一圖勝千言，理清思路再下手，事半功倍。

不管業務邏輯是否複雜，上去就是干，發現有何不妥的再去修改，發現漏掉的再去添加，這樣導致代碼總是一坨一坨的堆在那裡，經過多次的修改，已經面目全非，對於維護的人來說，更是苦不堪言。

在此，筆者也建議讀者朋友，不妨試一試先繪圖在動手，把一個模塊繼續拆解成一個個介面，通過實現介面去實現這個模塊，做到面向介面編程，這樣可維護性會提升好多……

對於模塊與模塊之間的通信，不應該是類與類之間的關聯，而是通過抽象去實現交互，抽象不應該依賴於細節，細節應該依賴於抽象，這話比較繞口，說白了，就是面向介面編程，而不是面向實現編程。

這樣做的好處就是，將來你要把這個被調用的類換成一個別的實現類時，你就不用去把調用過它的類一個個改掉了，因為它們調的是介面，介面沒變，在配置里把介面的實現類換成新的類，就全部都替換掉了。

類之間的耦合越弱，越有利於復用，一個處在弱耦合的類被修改，不會對有關係的類引起波及。

建議：理清思路再下手，事半功倍。開發過程中，不妨先定義好介面，通過實現介面去完成模塊的開發，儘可能的減小 Bug 率，寫出更加優質的代碼。

技術能力的提高，從代碼上的體現主要在於 「高內聚、低耦合」，因為這些思想衍生出許多開發模式，比如現在比較流行的 MVC、MVP、MVVM 等。

版本迭代與重構

我們在做任何系統的時候，都不要指望系統一開始時需求確定，就再也不會變化，這是不現實也不科學的想法，而既然需求是一定會變化的，那麼如何在面對需求的變化時，設計軟體的可以相對容易修改，不至於說，新需求一來，就要把整個程序推倒重來。

相信很多朋友都遇到過，原本一個很普通的需求，在經歷過 N 次迭代和修改後，已經形成一個龐大的功能，隨著版本的不斷迭代，維護起來的成本也隨著越來越大，這樣就形成了一種惡性循環，重構代碼即將登上歷史舞台。

不可否認，從維護成本上看，重構確實是一個很不錯的方案，重構的成本比原基礎維護的成本更小，也更方便以後的維護。有些公司甚至在多次版本迭代後，直接把整個項目推到重構，這樣的事情不僅僅發生在小公司，在一些大公司，也是會發生多次。

從技術上來說，重構複雜代碼時要做三件事：理解舊代碼、分解舊代碼、構建新代碼。

而待重構的舊代碼往往難以理解，尤其是在多次迭代且多人經手的模塊；模塊之間過度耦合導致牽一髮而動全身，不易控制影響範圍；舊代碼不易測試導致無法保證新代碼的正確性，尤其是在產品文檔不全的時候。

這是上次 Review 時候發現的一段代碼，先不說常量使用的不規範，這是經過一次次產品迭代後的結果，但這不是借口，造了這麼多次輪子，真不應該。做為代碼可重用性的反面教材，此處體現的淋漓盡致，如果有更多的狀態，此處必然還是會重複多次……

建議：重構，並不是萬能的，重構後的代碼，當再次經歷後續幾個版本修改後，代碼又顯的雜亂無章，那一坨坨代碼總是在不斷的重演。

既然無法確定需求日後是否會修改，那我們只能通過提高代碼質量來應對，以不變應萬變，合理設計介面，每次更改需求時多思考，對於多次使用的代碼進行封裝提取，儘可能少的改動既有的邏輯。

設計模式的重要性

會建築設計的是建築工程師，不會建築設計的是搬磚的。

前面已經說了很多，現在直接說一下設計模式的重要性，提到設計模式，就必須要提到六大基本原則和架構設計，提到架構設計，設計模式的重要性便可想而知。

首先，六大基本原則還是有點爭議的，我之前看到的書籍中，一般都是單一職責原則、迪米特法則、里氏替換原則、開閉原則、依賴倒置原則和介面隔離原則。

但我最近在一些帖子上看到，有一種說法是沒有介面隔離原則，而是合成 / 聚合復用原則，為了不影響之前的準備，合成 / 聚合復用原則會單獨拿出來說一下。

六大基本原則，它是整個架構設計的靈魂，是架構設計的一種指導思想，而設計模式是架構設計的一種具體設計技巧，是架構設計的具體實踐。

先從架構設計說起，對於架構設計，主要體現在抽象能力，抽象能力又依賴於架構者編碼的閱歷、功能的拆解和理解、邏輯的嚴密性。

做架構設計應該儘可能且更全面的考慮問題，儘可能做好代碼的包容性，海納百川，有容乃大之勢，這是架構設計者應該具備的基本條件。

考慮的問題越周全，包容性越強，則工作難度越大，給自己造成的障礙也越多。合理的將這些細節問題進行抽象，並提出解決方案，抽象程度越高，解決方案越合理，這才是架構者的價值所在。

從具體的需求，到代碼實現，再到具體的產品。架構設計的目的無外乎系統的復用性、擴展性與穩定性，具體的東西是無法很好地體現這些特性的，只有抽象的事物才能最好的體現。

在架構設計的過程中，單一職責原則告訴我們應該更好的體現高內聚、低耦合，這個類是用來數據請求的，就別放一些解析 JSON 的方法，如果這個類是用來圖片載入的，View 的註解請隔離開，做到一個類只負責一個職責，只有一個引起變化的原因。

如果一個類承擔的職責越多，就等於把這些職責耦合到一起，會帶來一些不必要的維護成本。從大的角度來說，MVP 和 MVC 模式都是單一職責原則的體現，model-視圖-控制相隔離，各司其職。

迪米特法則指導我們如果兩個類不必彼此直接通信，那麼這兩個類就不應當發生直接的相互作用。如果其中一個類需要調用另一個類的某一個方法時，可以通過第三者轉發這個調用。

類之間的耦合越弱，就越有利於復用，一個處在弱耦合的類被修改，不會對有關係的類造成波及。主要是強調了類之間的松耦合。

對於里氏替換原則，或許很多人沒聽過這個名詞，但是在實際開發過程中卻無時無刻不在使用，其實很簡單，子類型必須能夠替換掉它們的父類型。

舉個簡單的例子，「List list = new ArrayList();」，這麼做的好處其實很簡單，比如有一天 ArrayList 滿足不了需求，需要改用 LinkedList，只需要把 ArrayList 替換成 LinkedList，而不是把全局的 list 對象都改一遍，提高了可維護性。

開閉原則是面向對象原則的核心，有兩部分組成，對擴展開放，對修改關閉。軟體需求總是會變化的，對軟體設計人員來說，必須在不需要對原有系統進行修改的情況下，實現靈活的系統擴展。

對擴展開放，就是對抽象編程，而不是具體編程，因為抽象相對穩定，通過介面或者抽象類約束擴展，對擴展進行邊界限定，不允許出現在介面或抽象類中不存在的 public 方法。

讓類依賴於固定的抽象，所以，對修改是關閉的。這是建立在繼承和多態的基礎上，可以實現對抽象類的繼承，通過覆蓋其方法來擴展方法。

依賴倒置原則指的是依賴於抽象而不是依賴於具體實現，這一塊在上述已經說過，其實就是面向介面編程而不是面向實現編程，這樣做的好處就是解決耦合。

一般情況下抽象的變化概率很小，讓用戶程序依賴於抽象，實現的細節也依賴於抽象。即使實現細節不斷變動，只要抽象不變，客戶程序就不需要變化。這大大降低了客戶程序與實現細節的耦合度。

介面隔離原則認為，「使用多個專門的介面總比使用單一的介面要好」。

一個模塊應該依賴它需要的介面，需要什麼介面就提供什麼介面，把不需要的介面剔除掉，同時也應該遵循單一職責原則，這樣避免臃腫的介面帶來的污染，將沒有關係的介面合併在一起，形成臃腫的大介面，就是對介面的一種污染。

介面的粒度也不能太小，太小會導致介面額數量劇增，對開發人員不友好；介面額粒度太大，靈活性降低，無法提供定製服務，給整體項目帶來無法預估的風險，合理的設計介面，也是一門藝術。

對於這張圖，一定存在很多的爭議，因為很多設計模式都用到了多個基本原則，上圖只是對設計模式的一個比較粗糙的總結。

強調六大基本原則 (含有合成 / 聚合復用原則) 在設計模式中的具體體現，同時也說明了六大基本原則和 23 種設計模式是相輔相成的，六大基本原則作為設計模式的基石和模板，設計模式是六大基本原則運用的靈活體現。

合成 / 聚合復用原則這個是存在一定爭議的。目前有的書中還是保留了合成 / 聚合復用原則去掉了介面隔離原則，合成 / 聚合復用原則指的是少用繼承，多用合成關係來實現。

合成和聚合都是對象建模關聯關係的一種，聚合表示一種弱的擁有關係，整體由部分組成，部分可以脫離整體作為一個獨立的個體存在，合成則是一種強的擁有關係，體現了嚴格的部分和整體的關係，部分和整體的生命周期一致，部分不能脫離整體。

總結

六大基本原則是面向對象思想的體現，單一職責原則與介面隔離原則體現了封裝的思想，開閉原則體現了對象的封裝與多態，而里氏替換原則是對對象繼承的規範。

至於依賴倒置原則，則是多態與抽象思想的體現。在充分理解面向對象的基礎上，掌握基本的設計原則，並且能夠在項目設計中靈活運用，就能夠改善我們的代碼質量和結構設計。

尤其能夠保證可重用性、可維護性、可擴展性和靈活性，這也是理解和掌握設計模式必備的知識。

補充

對於六大基本原則，這是我們開發都應該熟記於心並且靈活運用的，對於設計模式在日常開發中的運用，有一點還是要強調的，適合自己的才是最好的。

如果此時一個模塊是很輕量級，僅僅為了使用設計模式而用設計模式，這無疑也會顯得不倫不類，使項目變的臃腫，同時也帶來一些不必要的維護成本（雖然維護成本很低）。

最近開始整理資料，準備寫設計模式專題，主要是 MVP 爬坑與迪米特法則、Framework 與開閉原則、單例與爬坑、換膚與觀察者模式、載入列表與模板方法模式、構造函數與建造者的對比、多個第三方登錄與命令模式，後續還會繼續完善，敬請期待。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！