再談 SOLID 原則，Why SOLID?
系列文章
Why SOLID?
在前一篇文章中介紹 SOLID 對一個工程師的影響，這裡再稍微補充一下為什麼軟體開發會需要 SOLID 原則？
軟體複雜的本質
專案經常會歷經「商業邏輯調整」和「快速且多變的需求」，這都不是開發環節所能控制的，但是一個專案會「遇到困難」常常是因為 糟糕的程式設計 和其他技術層面導致。
其中 糟糕的程式設計 又可分成三個因素：
其中 糟糕的程式設計 又可分成三個因素：
- 程式碼變更
- Bug 修復
- 複雜度控制
在添加功能前應該 閱讀代碼並細心設計，但實際上更常發生的是，開發者選擇直接在程式碼上面堆疊新的程式碼。新舊版本 和 意圖不同 的程式碼錯綜複雜之下，會讓專案難以在不引發連鎖反應的情況下增加功能。最後新的功能引入 Bug，從而導致另一個 Bug，然後一個接著一個，這樣的事情不斷發生。
在 沒有做過可擴展性設計的程式碼 上進行擴展功能，常常是火上加油！
那為什麼不把程式「設計」成可擴展就好了呢？
開發者知識普遍不足
一個充滿外行人的產業
開發者們來自不同的背景，且有大量不同的方式去解決問題，但是一個開發者應該具備什麼樣的知識體系，並沒有一個廣泛的共識。
更不幸的是，許多開發者在學校裡面學到的知識是過時的，學校提供的程式設計課程並未給學生做好準備。這些課程通常只關注程式語言的功能，但是 ...
掌握一門程式語言並不能使你成為軟體開發者，正如掌握一門自然語言並不能使你成為作家
學校所教的知識，並不是大部分軟體開發者的工作內容。開發者也許能編寫一個可運行的程式碼，但若要回頭去擴展程式碼卻常常是艱難且冒險的。
軟體開發過程中，開發者需要做出無數個選擇，加上每個開發者用不同的方法解決問題，助長了難以維護、難以擴展的程式碼。最終讓 系統設計的思想溝通 變得困難（工程師必須花費大量時間閱讀程式碼）。
不論是開發者還是管理者都需要對 軟體複雜的本質 做管理。為了編寫出更容易應對變化的程式碼，我們必須填補基礎認知方面的空白。
導入設計原則
若有一些原則可以指導工程師在 一定的情況下理解每個選擇的所得所失 並做出最佳權衡，則可以統一工程師解決問題的方法，降低 系統設計思想溝通 的困難度。
Uncle Bob 花費多年整理了許多開發人員、研究人員的思想和著作結晶，提出了 5 個設計原則：
SOLID 原則指導開發者們該 如何將函式和資料結構安排到類別中，以及這些 類別該如何互相關聯。
遵循 SOLID 原則的程式碼具有以下特性：
順帶一提，SOLID 原則並沒有順序關係，單純是 Michael Feathers(1 發了電子郵件告訴 Uncle Bob 可以用 SOLID 這個詞彙將 5 個原則串起來變成口訣方便記憶。
所以在學習 SOLID 原則的過程中，可以不用按照順序學習。
備註
- 單一職責原則（The Single Responsibility Principle, 簡稱 SRP)
- 開放-封閉原則 (The Open-Close Principle, 簡稱 OCP)
- 里氏替換原則 (The Liskov Substitution Principle, 簡稱 LSP)
- 依賴倒置原則 (The Dependency Inversion Principle, 簡稱 DIP)
- 接口隔離原則 (Interface Segregation Principle, 簡稱 ISP)
SOLID 原則指導開發者們該 如何將函式和資料結構安排到類別中，以及這些 類別該如何互相關聯。
遵循 SOLID 原則的程式碼具有以下特性：
- 能夠容忍變化
- 容易擴展新邏輯
- 容易理解
- 容易複用
順帶一提，SOLID 原則並沒有順序關係，單純是 Michael Feathers(1 發了電子郵件告訴 Uncle Bob 可以用 SOLID 這個詞彙將 5 個原則串起來變成口訣方便記憶。
所以在學習 SOLID 原則的過程中，可以不用按照順序學習。
- Michael Feathers 是 Working Effectively with Legacy Code 的作者，也是一本開發者必讀經典書籍。
留言
張貼留言