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

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

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

不過，你可能還是會覺得設(shè)計模式是把屠龍刀，看起來很厲害，但平時的開發(fā)根本用不上。基于這種觀點，接下來，我們就具體地聊一聊，我們?yōu)槭裁匆獙W(xué)習(xí)設(shè)計模式？

1. 應(yīng)對面試中的設(shè)計模式相關(guān)問題

學(xué)習(xí)設(shè)計模式和算法一樣，最功利、最直接的目的，可能就是應(yīng)對面試了。

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

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

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

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

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

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

我們經(jīng)常說，“Talk is cheap，show me the code?！睂嶋H上，代碼能力是一個程序員最基礎(chǔ)的能力，是基本功，是展示一個程序員基礎(chǔ)素養(yǎng)的最直接的衡量標(biāo)準(zhǔn)。你寫的代碼，實際上就是你名片。

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

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

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

3. 提高復(fù)雜代碼的設(shè)計和開發(fā)能力

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

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

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

而我當(dāng)時并沒有對設(shè)計模式相關(guān)的知識（包括設(shè)計模式、設(shè)計原則、面向?qū)ο笤O(shè)計思想等）有太多的了解和積累，所以一時間搞得我手足無措。好在因此我意識到了這方面知識的重要性，所以在之后很多年的開發(fā)中，我都一直刻意鍛煉、積累這方面的能力。面對復(fù)雜代碼、功能、系統(tǒng)的設(shè)計和開發(fā)，我也越來越得心應(yīng)手，游刃有余。寫出高質(zhì)量代碼已經(jīng)成為了我的習(xí)慣，不經(jīng)意間寫出來的代碼，都能作為同事學(xué)習(xí)、臨摹的范例，這也成為了我職場中最引以為豪的亮點之一。

4. 讓讀源碼、學(xué)框架事半功倍

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

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

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

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

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

5. 為你的職場發(fā)展做鋪墊

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

你去看大牛寫的代碼，或者優(yōu)秀的開源項目，代碼寫得都非常的優(yōu)美，質(zhì)量都很高。如果你只是框架用得很溜，架構(gòu)聊得頭頭是道，但寫出來的代碼很爛，讓人一眼就能看出很多不合理的、可以改進(jìn)的地方，那你永遠(yuǎn)都成不了別人心目中的“技術(shù)大?！薄?/p>

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

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

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

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

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

重點回顧

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

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

設(shè)計模式作為一門與編碼、開發(fā)有著直接關(guān)系的基礎(chǔ)知識，是你現(xiàn)在就要開始學(xué)習(xí)的。早點去學(xué)習(xí)，以后的項目就都可以拿來鍛煉，每寫一行代碼都是對內(nèi)功的利用和加深，是可以受益一整個職業(yè)生涯的事情。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。