算法像是單兵的作戰能力和武器裝備，設計模式像打仗列的陣型。只是單挑的話，陣型就不重要了；如果是群斗，請參考戚家軍是如何用鴛鴦陣吊打單兵作戰能力爆表的日本武士；如果上升到產品成敗的戰略高度，不好意思，除非能開掛做到《硅谷傳奇》里男豬腳那個牛逼的壓縮算法，同時還要開主角光環才行個人建議先學好算法，會養成一個工程師必須具備的心態：不斷優化自己程序的效率，低效一點都無法容忍。妥協的事情等到開始工作后再慢慢做吧。最最不濟，學好算法，面試的時候也是極有用的…至于設計模式，學也只是摸到皮毛，這需要大量的實踐經驗才可以。很多人在寫了n年代碼，直到開始帶團隊單挑項目后，才發現23種設計模式是這么牛逼閃閃和有用.

我相信，很多程序員都已經意識到基礎知識的重要性，覺得要夯實基礎，才能走得更遠，但同時對于如何將基礎知識轉化成開發“生產力”仍然有些疑惑。所以，你可能看了很多基礎的書籍，比如操作系統、組成原理、編譯原理等，但還是覺得很迷茫，覺得在開發中用不上，起碼在平時的 CRUD 業務開發中用不上。實際上，這些基礎的知識確實很難直接轉化成開發“生產力”。但是，它能潛移默化地、間接地提高你對技術的理解。

不過，我覺得，設計模式和操作系統、組成原理、編譯原理等這些基礎學科是不一樣的。它雖然也算是一門基礎知識，但是它和數據結構、算法更像是一道兒的，相比那些更加基礎的學科，設計模式能更直接地提高你的開發能力。我在開篇詞里也說了，如果說數據結構和算法是教你如何寫出高效代碼，那設計模式講的是如何寫出可擴展、可讀、可維護的高質量代碼，所以，它們跟平時的編碼會有直接的關系，也會直接影響到你的開發能力。

不過，你可能還是會覺得設計模式是把屠龍刀，看起來很厲害，但平時的開發根本用不上?；谶@種觀點，接下來，我們就具體地聊一聊，我們為什么要學習設計模式？

1. 應對面試中的設計模式相關問題

學習設計模式和算法一樣，最功利、最直接的目的，可能就是應對面試了。

不管你是前端工程師、后端工程師，還是全棧工程師，在求職面試中，設計模式問題是被問得頻率比較高的一類問題。特別是一些像 BAT、TMD 這樣的大公司，比較重視候選人的基本功，經常會拿算法、設計模式之類的問題來考察候選人。

所以，我在求職面試的時候，都會提前準備、溫習一遍設計模式。盡管并不是每次面試都會被問到，但一旦被問到，如果回答得不好，就是一個敗筆，這場面試基本上也就涼涼了。所以，為了保證萬無一失，擺脫一旦被問到答不出來的窘境，對于設計模式這種大概率被問到的問題，我都會未雨綢繆，提前準備一下。

當然，我并不是臨時抱佛腳。我平時就比較重視設計模式相關知識的積累，所以底子比較好，只需要在每次面試前花很短的時間，重新溫習一下，便可以自信滿滿地去面試，而不是心里老是擔心被問到，影響正常的面試發揮。

所以，如果你也不想讓設計模式相關問題成為你面試中的短板，那跟著我把專欄中的知識點都搞清楚，以后面試再遇到設計模式相關的問題，就不會懼怕了，甚至還會成為你面試中的亮點。

2. 告別寫被人吐槽的爛代碼

教你告別寫被人吐槽的爛代碼，成為技術大牛！

我們經常說，“Talk is cheap，show me the code。”實際上，代碼能力是一個程序員最基礎的能力，是基本功，是展示一個程序員基礎素養的最直接的衡量標準。你寫的代碼，實際上就是你名片。

盡管我已經工作近十年，但我一直沒有脫離編碼一線，現在每天也都在堅持寫代碼、review 指導同事寫代碼、重構遺留系統的爛代碼。這些年的工作經歷中，我見過太多的爛代碼，比如命名不規范、類設計不合理、分層不清晰、沒有模塊化概念、代碼結構混亂、高度耦合等等。這樣的代碼維護起來非常費勁，添加或者修改一個功能，常常會牽一發而動全身，讓你無從下手，恨不得將全部的代碼刪掉重寫！

當然，在這些年的工作經歷中，我也看到過很多讓我眼前一亮的代碼。每當我看到這樣的好代碼，都會立刻對作者產生無比的好感和認可。且不管這個人處在公司的何種級別，從代碼就能看出，他是一個基礎扎實的高潛員工，值得培養，前途無量！因此，代碼寫得好，能讓你在團隊中脫穎而出。

所以，我的專欄，不僅僅只是講解設計模式，更加重要的是，我會通過實戰例子，手把手教你如何避免剛剛提到的代碼問題，告別被人詬病的爛代碼，寫出令人稱道的好代碼，成為團隊中的代碼標桿！而且，寫出一份漂亮的代碼，你自己也會很有成就感。

3. 提高復雜代碼的設計和開發能力

大部分工程師比較熟悉的都是編程語言、工具、框架這些東西，因為每天的工作就是在框架里根據業務需求，填充代碼。實際上，我剛工作的時候，也是做這類事情。相對來說，這樣的工作并不需要你具備很強的代碼設計能力，只要單純地能理解業務，翻譯成代碼就可以了。

但是，有一天，我的 leader 讓我開發一個跟業務無關的比較通用的功能模塊，面對這樣稍微復雜的代碼設計和開發，我就發現我有點力不從心，不知從何下手了。因為我知道只是完成功能、代碼能用，可能并不復雜，但是要想寫出易擴展、易用、易維護的代碼，并不容易。

如何分層、分模塊？應該怎么劃分類？每個類應該具有哪些屬性、方法？怎么設計類之間的交互？該用繼承還是組合？該使用接口還是抽象類？怎樣做到解耦、高內聚低耦合？該用單例模式還是靜態方法？用工廠模式創建對象還是直接 new 出來？如何避免引入設計模式提高擴展性的同時帶來的降低可讀性問題？……各種問題，一下子擠到了我面前。

而我當時并沒有對設計模式相關的知識（包括設計模式、設計原則、面向對象設計思想等）有太多的了解和積累，所以一時間搞得我手足無措。好在因此我意識到了這方面知識的重要性，所以在之后很多年的開發中，我都一直刻意鍛煉、積累這方面的能力。面對復雜代碼、功能、系統的設計和開發，我也越來越得心應手，游刃有余。寫出高質量代碼已經成為了我的習慣，不經意間寫出來的代碼，都能作為同事學習、臨摹的范例，這也成為了我職場中最引以為豪的亮點之一。

4. 讓讀源碼、學框架事半功倍

對于一個有追求的程序員來說，對技術的積累，既要有廣度，也要有深度。很多技術人早早就意識到了這一點，所以在學習框架、中間件的時候，都會抽空去研究研究原理，讀一讀源碼，希望能在深度上有所積累，而不只是略知皮毛，會用而已。

從我的經驗和同事的反饋來看，有些人看源碼的時候，經常會遇到看不懂、看不下去的問題。不知道你有沒有遇到過這種情況？實際上，這個問題的原因很簡單，那就是你積累的基本功還不夠，你的能力還不足以看懂這些代碼。為什么我會這么說呢？

優秀的開源項目、框架、中間件，代碼量、類的個數都會比較多，類結構、類之間的關系極其復雜，常常調用來調用去。所以，為了保證代碼的擴展性、靈活性、可維護性等，代碼中會使用到很多設計模式、設計原則或者設計思想。如果你不懂這些設計模式、原則、思想，在看代碼的時候，你可能就會琢磨不透作者的設計思路，對于一些很明顯的設計思路，你可能要花費很多時間才能參悟。相反，如果你對設計模式、原則、思想非常了解，一眼就能參透作者的設計思路、設計初衷，很快就可以把腦容量釋放出來，重點思考其他問題，代碼讀起來就會變得輕松了。

實際上，除了看不懂、看不下去的問題，還有一個隱藏的問題，你可能自己都發現不了，那就是你自己覺得看懂了，實際上，里面的精髓你并沒有get到多少！因為優秀的開源項目、框架、中間件，就像一個集各種高精尖技術在一起的戰斗機。如果你想剖析它的原理、學習它的技術，而你沒有積累深厚的基本功，就算把這臺戰斗機擺在你面前，你也不能完全參透它的精髓，只是了解個皮毛，看個熱鬧而已。

因此，學好設計模式相關的知識，不僅能讓你更輕松地讀懂開源項目，還能更深入地參透里面的技術精髓，做到事半功倍。

5. 為你的職場發展做鋪墊

普通的、低級別的開發工程師，只需要把框架、開發工具、編程語言用熟練，再做幾個項目練練手，基本上就能應付平時的開發工作了。但是，如果你不想一輩子做一個低級的碼農，想成長為技術專家、大牛、技術 leader，希望在職場有更高的成就、更好的發展，那就要重視基本功的訓練、基礎知識的積累。

你去看大牛寫的代碼，或者優秀的開源項目，代碼寫得都非常的優美，質量都很高。如果你只是框架用得很溜，架構聊得頭頭是道，但寫出來的代碼很爛，讓人一眼就能看出很多不合理的、可以改進的地方，那你永遠都成不了別人心目中的“技術大牛”。

再者，在技術這條職場道路上，當成長到一定階段之后，你勢必要承擔一些指導培養初級員工、新人，以及 code review 的工作。這個時候，如果你自己都對“什么是好的代碼？如何寫出好的代碼？”不了解，那又該如何指導別人，如何讓人家信服呢？

還有，如果你是一個技術 leader，負責一個項目整體的開發工作，你就需要為開發進度、開發效率和項目質量負責。你也不希望團隊堆砌垃圾代碼，讓整個項目無法維護，添加、修改一個功能都要費老大勁，最終拉低整個團隊的開發效率吧？

除此之外，代碼質量低還會導致線上 bug 頻發，排查困難。整個團隊都陷在成天修改無意義的低級 bug、在爛代碼中添補丁的事情中。而一個設計良好、易維護的系統，可以解放我們的時間，讓我們做些更加有意義、更能提高自己和團隊能力的事情。

最后，當你成為 leader、或者團隊中的資深工程師、技術專家之后，你勢必要負責一部分團隊的招聘工作。這個時候，如果你要考察候選人的設計能力、代碼能力，那設計模式相關的問題便是一個很好的考察點。

不過，我也了解到，很多面試官實際上對設計模式也并不是很了解，只能拿一些簡單的單例模式、工廠模式來考察候選人，而且所出的題目往往都脫離實踐，比如，如何設計一個餐廳系統、停車場系統、售票系統等。這些題目都是網上萬年不變的老題目，幾乎考察不出候選人的能力。在我的專欄中，有200多個真實項目開發中的設計模式相關問題，你跟著看下來，足以讓你成為設計模式方面的大牛，再來面試候選人的時候，就不用因為題目老套、脫離實踐而尷尬了！

重點回顧

今天，我們講了為什么要學習設計模式相關的知識，總結一下的話，主要有這樣五點：應對面試中的設計模式相關問題；告別寫被人吐槽的爛代碼；提高復雜代碼的設計和開發能力；讓讀源碼、學框架事半功倍；為你的職場發展做鋪墊。

投資要趁早，這樣我們才能盡早享受復利。同樣，有些能力，要早點鍛煉；有些東西，要早點知道；有些書，要早點讀。這樣在你后面的生活、工作、學習中，才能一直都發揮作用。不要等到好多年后，看到了，才恍然大悟，后悔沒有早點去學、去看。

設計模式作為一門與編碼、開發有著直接關系的基礎知識，是你現在就要開始學習的。早點去學習，以后的項目就都可以拿來鍛煉，每寫一行代碼都是對內功的利用和加深，是可以受益一整個職業生涯的事情。

總結

以上是生活随笔為你收集整理的算法为屠龙刀，设计模式为倚天剑的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。