設計原則
整潔的程式碼 (clean code) 是軟體的基礎。如果這個磚塊做得不好，那麼建築物的架構就不是那麼重要了。但是即時有好的磚塊，也是可能會製造大量的垃圾，這時就是 SOLID 的原則發揮的場所了
不過我自己是覺得「形」比較重要。如果考量的是能夠容忍變化的條件，而且還有時程上的壓力時，那麼保有好的「形」，才有機會在未來替換掉不好的部分。但兩者能兼顧是最好拉！
SOLID 的原則告訴我們
- 該如何安排函式和資料結構到類別中
- 類別間如何互相關聯
原則的目標是建立中層級的軟體結構
- 能容忍變化
- 容易理解
- 在許多軟體系統中能夠使用的元件基礎
中層級是指：設計師在模組層級工作時應用的原則。1980 年代就開始被討論，2004 年誕生了 SOLID 這個詞彙。
- SRP: 單一職責原則
- OCP: 開放封閉原則
- LSP: Liskov 替換原則
- ISP: 介面隔離原則
- DIP: 依賴反向原則
之後會討論這些原則在架構的含義，而不是在那些詳細的討論。
低語
SOLID 這幾年才仔細品嚐，也試過許多實作，才漸漸明白他的必要性。會使用這樣的原則一開始最常被問的問題是：「為什麼要搞得那麼複雜呢？」
要回答這個問題，首先要先釐清目標。目標是要「完成一項功能」還是「完成一項可以被維護的功能」
如果是「完成一項功能」，那確實可以不見得考量這個原則，只要能達成這個目標，基本上寫法不要太離譜，都是可行的。
但如果是「完成一項可以被維護的功能」？
什麼叫做可以維護？需要維護表示發生 bug 或是有功能的需要變更了。當範圍小時，只要修正或改變原來程式碼部分的行為，應該就可以達到目標。（範圍大就重寫吧 XD）
但是因為只修改了部分，要如何的證明或驗證全部個功能都還「符合預期」呢？寫測試就是一種手段！
如何測試？
可以寫單元測試來確保輸出入符合預期
可以手動跑每個功能步驟來做驗證
可以寫自動化的程序來跑期望的場景
各種層級的測試的著眼點都有所不同，所以都是需要的。
但以這個功能所涵蓋的各項子功能來說，最貼近的就是單元測試。
可以這麼說，修改完後，跑完單元測試，能有比較大的信心，原先考量的功能還是正常的。
所以以工程師的角度而言，是可以交貨給 QA 做整合測試的。
但在開始寫單元測試時，就會發現自己的程式碼到底是不是「Testable」，如果不行，那寫單元測試就會寫得很辛苦，導致無法繼續維護。
無法好好維護的專案或程式，最終會成為…垃圾般的存在。
因此如何寫出 Testable 的程式碼… SOLID 原則將會是一種答案！
