Re: [請益] 如何選擇適合的設計模式
我對看到的其中幾句話有一些其他想法和想補充的地方
和大家分享
※ 引述《strlen (strlen)》之銘言：
: .....
: ..... 非到必要時刻不要使用
不是只有 SOLID 原則、設計模式非必要時不要用到
我覺得包括 clean code 裡面提到的東西、重構
甚至到 Effective SQL、CI/CD、SRE 之類的東西也一樣
沒有需要用到
表示手上的工作可以用最簡單的方式解決掉
但這些東西之所以會被整理成冊、流傳多年，甚至有些還被喻為必讀聖經
就是因為這些東西都是在特定領域最常被使用來解決問題的方法、流程
而且想逃避不用還不一定逃得掉
最好的方法是邊做、邊學、邊討論
上面幾句話提到的東西其實不少
再加上自己前一段講的名詞加起來
這輩子要學到透徹、學到精通應該蠻難的 (我想自己是做不到)
但建議把這些專有名詞都看過、知道有這個東西
因為可以大幅降低溝通成本、避免討論上不小心造成的誤解
「覺得這邊做 method extraction 以後再來用類似觀察者模式下去調整，應該就
可以解決 ......」
聽到「method extraction」和「觀察者模式」可能沒辦法理解流程、程式調整方式
但若有聽過、知道這些名詞的概要、特性
就可以很快的了解需要重構、並讓類別提供一些特定的 method 供使用
覺得也不是說業界沒在用、或是不重視
只是這些東西默默融入生活中
討論的時候不一定會以專有名詞的方式出現而已
「試試看走下路，然後在森林出口和草叢附近種香菇」
: 沒有所謂的正確的模式
書上整理出來發法、設計方式
大多是遇到問題比較通用的解決方法，或是可以參考的常見設計方式
我目前幾乎沒有遇到剛剛好可以一模一樣完全照著做就能解決問題的問題
就和人生一樣，多數的問題都沒有最佳解，只有可能的較佳解
但有件事情是肯定的：站在巨人的肩膀上能少走一些冤枉路
累積更多的經驗、了解更多人的思路和解決方案
可以讓你在決策時做出更適當的選擇
----
突然覺得好像不該選擇在半夜寫垃圾 QQ
--
clean code 跟能不能簡單解決沒太大關係吧
回樓上 看完clean最痛苦的我 就是明明只是寫一個簡單的
資料夾文件整理的程式 一個寫在main就能完成的事 我卻
還要想怎麼抽出函式 怎麼命名...
clean講得東西其實要分兩種 一種是所有地方皆通用的建議
一種是所謂的「招式」 通用建議就是好好命名 一個method只
做一件事 這些不管你什麼寫法都應該最好要知道的東西
另一個「招式」就是SOLID和設計模式 這個就是你不只要會用
還要會「選擇對的時機用」 後者比前者更困難
clean code參考而已吧 你看阿里巴巴的開發guidelines
有些根本就和clean code背道而馳
舉exception為例子 clean code認為拋exception讓接收錯誤
的處理器用多型處理
阿里巴巴卻是強調要精確的exception
再來說程式撰寫的顆粒度 clean code不會和你說那些物件有坑
阿里巴巴會明確敘述 例如SimpleDateFormat
多看看幾本書 每本互相參考才比較好吧
越簡單越好 ... 也不用假想太多未來的狀況 9成都不會
看完clean跟怎麼寫應該是兩回事? 沒有一定要這麼做
程式沒有唯一解 只有適合的解法
越簡單越好+1
多型事實上就是屬於「招式」的那一邊 有時間多看當然是好
事 看越多你越能斟酌你目前的現況使用這些工具
我只是說clean code有一些基本不能再基本的東西 DRY之類的
不管你是寫什麼毛都應該要注意
12
請你把clean code三本都看完 可以的話clean architecture也一起 這系列就是在講什麼時候該用什麼模式的準則 我這篇也講幾個重點原則 1. 保持簡單![Re: [請益] 如何選擇適合的設計模式](http://lh3.ggpht.com/-T8swUhZ6xkY/Ux_B9YjiyaI/AAAAAAAAxM0/biy5nMfIjNw/w1200-h630-p-k-no-nu/image_thumb%25255B1%25255D.png?imgmax=800 "Re: [請益] 如何選擇適合的設計模式")
1
這個問題就跟大部分的系統都可以用任何程式語言開發一樣 那你要選哪個語言進行開發？ 準則就是如果套用這個模式讓你的系統架構 可以更容易開發新功能/除錯 那就是好的 比如說原本架構你要加一個新功能要花三週要改動50個檔案18
首Po小弟在設計系統的功能時，時常會不知該用什麼準則來判斷適合的模式 之前曾在某個網站中看到同一個問題，拿來套進 23 個模式之中 當下看完後，心想：所以大部份的問題都可以任意套用模式？ 應該不是這樣子，否則四人幫就沒有必要把它們分成三大類了 那到底該如何決擇正確的模式
9
[分享] 用一個簡單的數學公式來幫忙設計OOP類別大家好，小弟一直覺得 OOP 很困難、設計類別很困難。 我一直想找一個比較量化分析的方式，在工作時輔助設計類別。 於是我設計了一個簡單的數學公式 跟大家分享一下這個公式，謝謝大家 網頁好讀版：![[分享] 用一個簡單的數學公式來幫忙設計OOP類別](https://res.cloudinary.com/howtomakeaturn/image/upload/v1589772259/qhe3feyrjueqensuylyk.png "[分享] 用一個簡單的數學公式來幫忙設計OOP類別")
9
Re: [閒聊] 作文：我的家鄉教我的事我是以台南和高雄做為對比，但我沒把台南和高雄寫出來，怕寫出來會被扣分 家鄉在台南，求學時在高雄 台南市有歷史文化底蘊，中產階級多 因此型塑的思考問題方式有； 1.環境的和諧8
Re: [討論] 請大家聊聊 JavaScript的缺陷不太認同, 如果今天的task是計算1加到10000 從紙上開始 1 + 2 + 3...一直算到10000可以解決問題 用等差數列的公式也可以解決問題 寫段code直接寫個function讓function可以支援不同的min, max也同樣能解決問題 這些方法都能解決問題？難道他們都是好方法嗎？6
[心得] 【書摘】做自己的生命設計師圖文好讀版 在當兵煩悶的日子當中認識到這本書，看了幾頁就直接愛上了，簡言之就是用設計思考（ design thinking）的方法去設計自己的人生，書中有提供整套流程跟方法，對於思考未 來、選擇職涯非常有幫助。![[心得] 【書摘】做自己的生命設計師](https://i.imgur.com/71kJEsZb.png "[心得] 【書摘】做自己的生命設計師")
2
[心得] 一頁式專案章程幫你定義、解決問題【前言 - 解決對的問題遠比解決問題重要】 工作總是永無止盡，時間卻總是稍縱即逝嗎？解決問題其實很容易，但是解決對的問題 很困難，尤其是找到痛點對症下藥。今年，當我正在規劃我下半年的專案和目標時，我 採取了這五個步驟來幫助我理清邏輯： 1) 首先，問對「為什麼」，搞清楚問題的本質，你才不會走錯方向![[心得] 一頁式專案章程幫你定義、解決問題](https://static.wixstatic.com/media/f01147_e3cc2edf03c24a9686de184eb2794174~mv2.jpg/v1/fill/w_1000,h_562,al_c,q_85,usm_0.66_1.00_0.01/f01147_e3cc2edf03c24a9686de184eb2794174~mv2.jpg "[心得] 一頁式專案章程幫你定義、解決問題")