一個你可能也遇過的場景

下午艷陽高照的時候，菜鳥工程師阿柴接到了好朋友小黑的電話

阿柴: yo bro, what's up?
小黑: 阿柴救命，我的咖啡店柴咖啡，才剛開幕沒多久，原先設計系統的工程師小黃跑了，我也不會系統，你能不能幫幫我!!

初出茅廬的阿柴一聽，覺得能有這麼棒的經驗，對方還願意找他，當然馬上說好！

故事就是這麼開始的，簡單卻熟悉，雖然阿柴還沒看過程式碼，但反正現在 AI 這麼方便，我可以度過難關的，阿柴心想

我們先來定義主軸

在往下講之前，先讓自己搞清楚: 接下來的旅途，不是要學習怎麼設計系統架構
要不要拆微服務、資料庫怎麼選、API 怎麼設計，這些是系統架構要處理的問題

架構決定系統長什麼樣子，是骨架，而 Design Pattern 決定的是骨架之下，每一段程式碼怎麼寫、怎麼組織，是骨架裡的關節

這系列要訓練自己的，是關節設計的判斷力

AI 給得出語法，但不懂你的取捨

AI 在「寫出能動的程式碼」這件事上，快速又方便，無法反駁，不僅是變數命名、迴圈邏輯、API 呼叫方式，這些「語法層級」的產出，又凶又快

但如果多要求一點，例如:

「這個點餐系統以後要串外送平台、要能加購、要能做促銷活動，這段程式碼現在該怎麼寫，才不用花 88888 大改?」

AI 通常會給一份「看起來合理很專業」的答案，可能一次套上 Factory、Strategy、Observer、Decorator 四五個 Pattern，class 切得又細又漂亮。問題是:

你能看得懂嗎?

這時候真正該問的不是「這樣寫對不對」，而是:

• 這個複雜度，符合現在的規模嗎?
• 半年後如果開始展店了，今天這樣寫會不會反而礙事?
• 如果需求變更，是否能以最低的變動成本達成目的?

而取捨的判斷力，也是我身為 junior 需要磨練的判斷力

而我想 Design Pattern 存在的意義，不是「硬背下 23 種招式，套在程式碼裡」而是

1. 一套共同語言，當你說「這裡可以用 Strategy 處理」，同事(或未來的 AI)能馬上懂你的設計意圖，不用逐行解釋
2. 一套判斷框架，理解每個 Pattern 解決的「具體問題」是什麼，才能反過來問自己「我現在有沒有這個問題」
3. 一面照妖鏡，看得懂 Pattern，才看得出 AI 什麼時候在幫你解決問題，什麼時候在幫你製造問題(?)

所以，這 30 天，我們來經營一間咖啡店吧!

比起條列 23 種 Pattern 的定義，更想讓這件事有畫面感。所以這系列會有一條故事線貫穿柴咖啡。

接下來幾天，我們先跟著阿柴的系統一起長大，一起先經歷系統的痛苦，再學習活用 Design Pattern