1. 設計模式究竟是啥？
相信很多程序員都知道有設計模式這麼個概念，也知道很重要，但至於什麼這麼重要就比較模糊了。沒錯，其實在很多場景開發中，開發者只需要掌握最基本的框架使用，根據不同的業務邏輯去做CRUD開發就行了。軟件也能跑起來，看起來也不錯，對吧。但如果你的代碼並沒有採用合理的設計模式，當我們要改動需求或者增加新的功能或者業務系統過於龐大後，你會發現代碼真的亂成了一鍋粥，你自己都想趕快甩鍋走人了。這時候你問一些大佬，他們通常會告訴你兩個字：重構。而重構的核心意義就是改善既有代碼的設計，說白了就是應對程序開發中的變動的。說白了，設計模式用得好，你就可以很輕鬆自如的應對各種變動，反之則越改越痛苦。設計模式是設計代碼結構的一種指導，但對於沒一些編碼經驗的人來說看起來的確有點抽象難懂。沒錯，學設計模式之前的確需要一些編程實踐，當有了這些編程實踐後在看起來就會有種豁然開朗的感覺。
2. 學好設計模式的意義
其實學好設計模式最直接的意義就是你可以寫出很有層次結構高質量代碼，避免了在團隊開發中被打。此外，無論你打算做什麼工程師，無論是前端後端還是客戶端面試都會問道設計模式相關的問題，這就足以證明了它的價值與意義。所以如果你不平時不把這塊內容給夯實了打好基礎很容易在面試的時候漏出馬腳。
不知道你有沒有閱讀源代碼的習慣，無論是語言的源代碼還是常用框架的源代碼，其實內部都蘊含了大量的設計模式，如果你沒有相應的知識可能連源代碼都看不懂。因爲像這些框架基本是中間件，爲了滿足各種複雜場景的通用性都做到了高內聚低耦合，沒有相應的知識很容易出現雲裏霧裏的自己把自己都繞暈了。
我們經常說，“Talk is cheap，show me the code。”實際上，代碼能力是一個程序員最基礎的能力，是基本功，是展示一個程序員基礎素養的最直接的衡量標準。你寫的代碼，實際上就是你名片。隨着日積月累的經驗，成爲技術大牛，升職加薪還不是早晚的事。
3. 如何評價代碼質量的高低?
實際上，我們很難通過其中的某個或者某幾個詞彙來全面地評價代碼質量。因爲這些詞彙都 是從不同維度來說的。這就好比，對於一個人的評價，我們需要綜合各個方面來給出，比如 性格、相貌、能力、財富等等。代碼質量高低也是一個綜合各種因素得到的結論。我們並不 能通過單一的維度去評價一段代碼寫的好壞。比如，即使一段代碼的可擴展性很好，但可讀 性很差，那我們也不能說這段代碼質量高。
除此之外，不同的評價維度也並不是完全獨立的，有些是具有包含關係、重疊關係或者可以 互相影響的。比如，代碼的可讀性好、可擴展性好，就意味着代碼的可維護性好。而且，各 種評價維度也不是非黑即白的。比如，我們不能簡單地將代碼分爲可讀與不可讀。如果用數 字來量化代碼的可讀性的話，它應該是一個連續的區間值，而非 0、1 這樣的離散值。
不過，我們真的可以客觀地量化一段代碼質量的高低嗎?答案是否定的。對一段代碼的質量 評價，常常有很強的主觀性。比如，怎麼樣的代碼纔算可讀性好，每個人的評判標準都不大 一樣。這就好比我們去評價一本小說寫得是否精彩，本身就是一個很難量化的、非常主觀的 事情。
正是因爲代碼質量評價的主觀性，使得這種主觀評價的準確度，跟工程師自身經驗有極大的 關係。越是有經驗的工程師，給出的評價也就越準確。相反，資歷比較淺的工程師就常常會 覺得，沒有一個可執行的客觀的評價標準作爲參考，很難準確地判斷一段代碼寫得好與壞。 有的時候，自己覺得代碼寫得已經夠好了，但實際上並不是。所以，這也導致如果沒有人指 導的話，自己一個人悶頭寫代碼，即便寫再多的代碼，代碼能力也可能一直沒有太大提高。
仔細看前面羅列的所有代碼質量評價標準，你會發現，有些詞語過於籠統、抽象，比較偏向 對於整體的描述，比如優雅、好、壞、整潔、清晰等;有些過於細節、偏重方法論，比如模 塊化、高內聚低耦合、文檔詳盡、分層清晰等;有些可能並不僅僅侷限於編碼，跟架構設計 等也有關係，比如可伸縮性、可用性、穩定性等。其中幾個最常用的、最重要的評價標準，來詳 細講解，其中就包括:可維護性、可讀性、可擴展性、靈活性、簡潔性(簡單、複雜)、可 複用性、可測試性。實際上，思從深而行從簡，真正的 高手能雲淡風輕地用最簡單的方法解決最複雜的問題。這也是一個編程老手跟編程新手的本 質區別之一。
4. 面向對象、設計原則、設計模式、編程規範、重構，這五者有何關係？
簡單來說：面向對象是武器，設計模式是招式，設計原則是心法，以心法爲基礎，以武器運用招式應對複雜的編程問題。總體來說就是爲了編寫高質量代碼而服務的，如下圖所示。
好了，相信你看到這裏已經明白爲什麼要學號設計模式了，後續我也會寫一些關於設計模式有關的博文，喜歡的敬請關注。
關於我
顏值與BUG並存的程序員👨💻
請關注👀、點贊👍、評論👯♀️
微信公衆號：Peachou
