時常回到原點思考，可以幫助我們確認做這件事情的價值，物件導向設計原則及模式在網路上有很多文章在介紹它，一篇比一篇寫得還詳細，但是搜尋「為什麼要遵循物件導向設計原則及模式」，文章的數量就不多了，原因我想大概就是有些事情必須要切身體會，才會有所體悟。
良葛格有一篇在 iThome 的文章 - 設計原則五四三，其中在第五段有提到：
有人說到，程式寫太少，看過的程式太少，就無法體會這些原則的重要，而稍微寫過些程式，對程式有些痛苦經驗的，反而會對這些原則抱以崇拜，至於程式設計經驗豐富的人，則又認為這幾個原則不過就只是常識，就像覺得設計模式，不過就是取了些名字的東西罷了。
也就是因為這樣，物件導向設計原則及模式無法藉由單純的上課或看書，就能夠在戰場上派上用場，至少還需要「刻意地練習」，但是台灣的 IT 產業大都只注重結果，過程怎樣並不重要，大部分的老闆也都認為不管黑貓、白貓，能抓老鼠的就是好貓，在這樣的環境下，遵循物件導向設計原則及模式，反而被認為是阻礙抓老鼠的絆腳石，甚至有的時候被批得一無是處。
我個人經歷過那一段「刻意地練習」的過程，驅動著我刻意練習的動力，只是單純覺得我自己那時候寫的程式真 TMD 的爛，可是如果重新再寫一次好像也差不多爛，所以才去上課、看書，加上「刻意地練習」，除此之外，還有一些我認為的好處。
1. 有所本
當我們在解說著我們自己寫的程式時，說出「我這個設計是遵循著 XX 原則」比「這個我花了一個下午自己想出來的」還來得有所本，遵循著原則做出的決策，比較不容易受到個人喜好的影響。
有一次開會的時候，大家在討論著從客服那邊反應的系統問題，應該怎麼分配？多數人都認為「如果那一段的程式是自己寫的應該自己維護，其他的再隨機指派。」，不過，身為敏捷開發的信仰者，基於敏捷開發的精神，我認為應該要多增進團隊成員之間彼此的互動，因此提出的看法是「如果某人已經對該系統問題有解決的經驗，則問題應該分派給其他人，再由有經驗的人協助被分派到問題的人解決問題。」，不管結論如何，若提出的看法能夠有所本，內心多少會有一份踏實感。
寫程式也是一樣，我們寫的程式是否都有所本？寫程式本身是一種設計的行為，而不是建造的行為，所以設計得怎樣是因人而異的，個人的喜好會左右設計出來的樣子，如果沒有原則，就很容易會出現某某哥 Style、某某姐 Style 的獨特設計樣貌。
2. 能夠理解的設計思維更多了
我們所引用的第三方元件幾乎都遵循著設計原則，所以如果能夠熟悉設計原則，我們就比較容易理解這些第三方元件的設計思維，擴展它，甚至修改它就比較不會有問題。
不知道各位朋友的程式裡面埋 log 的那一段是自己寫的，還是引用像是 log4net 這樣的第三方元件，log4net 內建提供的 Appender 就很好用了，可以讓我們將 log 寫到檔案、資料庫、Email、Windows Event...etc.，但是如果我們要將 log 發到 Slack、Line...etc.，我們是只能等待佛心來著的大大提供？還是我們可以自行擴展 log4net 來達成？
log4net 開放了 AppenderSkeleton 這個抽象類別，如果我們熟悉 OCP 跟 DIP，我們就可以理解 AppenderSkeleton 的功用，一切不言而喻。
3. 不需要解釋太多
設計原則及模式可以成為一種的默契跟語言，如同剛才提到的 log4net AppenderSkeleton 的例子，作者不需要來我們面前跟我們解釋一堆，我們就能理解作者在想什麼。
維護程式最難的部分，是理解當初寫這支程式的人（包括自己）在想什麼？想做什麼？尤其程式的設計方式又獨樹一格的時候，這時候我們不管查書本或 Google 都沒有用，絕對找不到答案，這是所有程式設計師心中的痛，但這卻造就了廣大的程式設計就業市場（誤）。
4. 得到好維護的程式
相信大家都聽過「高內聚」、「低耦合」，個人認為好維護的程式應該是兩者兼備，程式的可維護程度與程式碼的複雜度成正比，注意，是程式碼的複雜度，不是程式本身功能的複雜度，有時候程式提供的功能很簡單，但是背後實作的程式碼卻很複雜，還有，當系統需要提供的服務愈多元的時候，程式碼的複雜程度也會愈高。
平常我們自己做做 side project、寫寫小程式，我們可以放過自己一馬，但是如果我們做的是稍具規模的軟體專案，這時候遵循設計原則及模式，可以幫助我們儘量提高程式的內聚程度及降低元件之間的耦合程度，以維持程式的可維護性。
說來說去，還是在說自己對自己交不交待得過去？
在這個業界應該沒有那種「嘿嘿！我就是想寫爛 Code，你想怎樣！？」的程式設計師，但是我絕對相信有那種「哼哼！我就是想完全照著自己的想法寫 Code，你想怎樣！？」的程式設計師，老闆、主管、業主，大都不會關心我們程式是怎麼寫出來的，嚴格說起來我們也是在做一種資訊不對等的買賣，因為大多數的老闆、主管、業主不懂軟體設計，這讓我們有了上下其手的機會，我們可以選擇輕鬆地寫程式，也可以選擇簡單地寫程式，我們可以選擇一年經驗用 10 年，也可以選擇扎扎實實地擁有 10 年的經驗，只看我們自己有自己交不交待得過去？
