前面的篇章中分享了SOLID五大原則，
我們可以在分析、設計時不斷的反思是否有遵循這些原則，
不至於到了最後才發現，我們做出一個結構松散的架構。
也分享了一些OOA、OOD的觀念，
讓我們在需要處理分析、設計的時候能有一些基本的認識。

平常時常常會遇到一個狀況，知道MVC、MVVM、VIPER....等一拖拉庫的架構，
但真當程式碼到了我的手上之後，發現我還是無從撰寫起。
這是因為在我們的腦中沒有相對應的工具-設計模式。

甚麼是設計模式

前人將一些在開發上反覆發生的情境彙編整理出一套
將程式架構變成可程式化的方式。
這邊通俗一點的說，設計模式就是前人常用的程式撰寫方式。

設計模式，也是我個人覺得非常重要的一環，
更是工程師精進的路上最先應該被接觸到的技能之一。

為什麼我沒聽過設計模式

我們常常聽到 MVC、MVP、MVI...等架構，
都聽到可以倒被如流了怎麼還沒聽過設計模式?

這邊大概可以分成幾個部分來探討。
一部分的原因是我們職位制度和專案開發架構下的問題，
在以前瀑布式開發下大概有這幾個職位 PM、SA、SD、PG。
而在SA與PM溝通時，大多數也只是討論到架構的部分。
當部門需要新的人才時，就會PM跑去跟HR說需要甚麼樣的人才...
這時當我們打開人力銀行求職的時候就會發現上面滿滿的
懂MVC架構、懂三層式架構...等需求。

另一部份的原因則是自身目前的能力還不夠，
在這時候，通常我們也只是在前人所訂定好的框架下進行開發，
所以在開發的時候不會有人來跟你討論設計的問題，
當然也就不會有討論到任何的設計模式。

基於以上兩點，就產生了第三個問題就是傳度不夠，
知道的人不一定會分享，會分享的人又不知道。
工作上又常常只要求懂架構(MVC、MVP....等)
導致大家都只知道框架，而沒聽過設計模式。

學習設計模式有甚麼用

設計模式就像數學中的公式一樣。
當你不懂公式，我們一樣可以透過原理推導出我們要的答案。
但理解原理後，使用公式來計算不僅能幫助我們更快速的解決問題，
也能讓我們把問題解決得更漂亮(程式可以寫得很優雅)。

在開發上使用一些廣為人知的設計模式大概有幾個好處:

• 增加思路，幫助理解問題
• 更容易實踐架構上的需求
• 方便與其他工程師溝通

這邊個人認為第三點是最為重要的一點。
在一些大型專案中開發，不免都需要與其他工程師溝通，
不論你是負責設計，或是你只是負責撰寫程式。
當大家都對設計模式了解時，
就不需要花太多時間把整個物件關係、運作原理...等都說明一次。
可以大幅降低溝通上的成本。

結語

在職場中懂得設計模式，其實不是甚麼必備的項目。
撰寫程式時，不外乎就是注意整體架構強、有彈性就可以了。
所以開發時也可以透過一些原則去推導出自己想要的設計模式，
可以自己選擇成為巨人、或是站在巨人的肩膀上。

在接下來的篇章會開始分享一些設計模式。