我對看到的其中幾句話有一些其他想法和想補充的地方
和大家分享
※ 引述《strlen (strlen)》之銘言：
: .....
: ..... 非到必要時刻不要使用
不是只有 SOLID 原則、設計模式非必要時不要用到
我覺得包括 clean code 裡面提到的東西、重構
甚至到 Effective SQL、CI/CD、SRE 之類的東西也一樣
沒有需要用到
表示手上的工作可以用最簡單的方式解決掉
但這些東西之所以會被整理成冊、流傳多年，甚至有些還被喻為必讀聖經
就是因為這些東西都是在特定領域最常被使用來解決問題的方法、流程
而且想逃避不用還不一定逃得掉
最好的方法是邊做、邊學、邊討論
上面幾句話提到的東西其實不少
再加上自己前一段講的名詞加起來
這輩子要學到透徹、學到精通應該蠻難的 (我想自己是做不到)
但建議把這些專有名詞都看過、知道有這個東西
因為可以大幅降低溝通成本、避免討論上不小心造成的誤解
「覺得這邊做 method extraction 以後再來用類似觀察者模式下去調整，應該就
可以解決 ......」
聽到「method extraction」和「觀察者模式」可能沒辦法理解流程、程式調整方式
但若有聽過、知道這些名詞的概要、特性
就可以很快的了解需要重構、並讓類別提供一些特定的 method 供使用
覺得也不是說業界沒在用、或是不重視
只是這些東西默默融入生活中
討論的時候不一定會以專有名詞的方式出現而已
「試試看走下路，然後在森林出口和草叢附近種香菇」
: 沒有所謂的正確的模式
書上整理出來發法、設計方式
大多是遇到問題比較通用的解決方法，或是可以參考的常見設計方式
我目前幾乎沒有遇到剛剛好可以一模一樣完全照著做就能解決問題的問題
就和人生一樣，多數的問題都沒有最佳解，只有可能的較佳解
但有件事情是肯定的：站在巨人的肩膀上能少走一些冤枉路
累積更多的經驗、了解更多人的思路和解決方案
可以讓你在決策時做出更適當的選擇