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

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

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

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

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

基本的規范和約束

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

for (int i = 0; i < j; i++) { 
       // TODO 
   } 

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

日常開發中，還有平時維護別人代碼的同時，總會去調試 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< String> list = new ArrayList<>();”，這么做的好處其實很簡單，比如有一天 ArrayList 滿足不了需求，需要改用 LinkedList，只需要把 ArrayList 替換成 LinkedList，而不是把全局的 list 對象都改一遍，提高了可維護性。

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

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

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

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

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

接口隔離原則認為，“使用多個專門的接口總比使用單一的接口要好”。

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

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

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

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

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

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

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

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

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

補充

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

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

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