前言與初衷

嗨大家好，我是 Derek，一個經驗值還在點的菜鳥轉職仔

在 LLM 誕生的年份選擇踏入 web 開發，在一個方便且快速的年代，任何事情都可以問 AI，coding / 測試 / CICD / 怎麼煮水煮蛋(?) / 這盆花是不是缺水(?)，幾乎都可以問

但也因為是菜鳥，什麼都很新，什麼都要學，每天的輸入跟輸出完全不同

我也逐漸意識到一個問題，手握的知識，到底是不是屬於自己呢，如果不是

那該如何去驗證是不是屬於自己的呢? 唯一想到辦法，就是"輸出"

曾閱讀過前輩的文章，不管是胡立大，還是高見龍大，他們一致推崇的方式就是 "寫文章"

寫文章幾乎是百利而無一害的動作，我懂它的道理，但卻該死遲遲沒有動作，為什麼

1. 不知道從何下筆
2. 下筆了要寫什麼? 文章的脈絡怎麼取捨?
3. 文章給別人看好赤裸
4. 寫太破被當笨蛋怎麼辦...

而在職涯的空檔間，很幸運剛好碰到 IT 鐵人幫的賽程，也發現原來有個分類叫「自我修練」，太棒了

可以專注於自身的成長，訓練自己並持續給予自己壓力，好好在30天產出30篇文章

這時候我想起我入門導師六角學院校長-洧杰校長的經營名言

1. 「你不用一開始就很厲害，但要開始才有辦法變厲害」
2. 「跟自己比較就好」

「 這就是最好的 time 了 」 我心想，所以我註冊帳號，填了基本資料，報名了一年一度的自我修練鐵人幫賽事

怎麼選題的?

在人手可以30秒蹦出一個 Landing Page 的時代，那該如何證明自己的產品是個「好產品」?

讓我想到先前在 ALPHA Camp 看到一個影片，源自於時任 iCook co-Founder CEO Richard Lee 所言，好產品要考慮擴充性、可用性、效能，但這些是系統架構要處理的問題

但架構之下，每一行程式碼要怎麼寫、怎麼組織，才撐得住架構訂下的方向，這才是我想聚焦的地方，也就是可維護性、可擴充性這種「程式碼層級」的判斷力

在使用 C# 開發 side project 過程中，我接觸到了開放封閉原則（Open/Closed Principle）

需要想，該怎麼讓程式碼在未來需求變動時，不用改舊程式碼就能加新功能?

時間就是金錢朋友，源自 WOW 經典名言

軟體開發是一場馬拉松，時時需求會變動，時時有狀況要排除，跑最快的不是贏家，能跑到最後才是；而 Design Pattern，就是幫我在這場馬拉松裡跑得久一點的工具

如何讓時間證明自己的價值，事先好好地規劃，是工程師的基本功，它背後要解決的問題（耦合、擴充性、職責劃分）在任何語言都通用，這就是我選題的由來

那什麼是 Design Pattern 呢

剛入門做 Express 開發時，接觸 MVC / MVVM 架構，以及熟悉連線池設定、各式花式 function 還有堆得比山還高的 SQL 指令，倒也沒有具體使用過 Design Pattern

在初識 C# 物件導向語言時，透過 OOP 理解 SOLID 概念，才知道 Design Pattern 就是「前人踩過的坑，之後整理出來可驗證的解法套路」

想像一下蓋房子，樓梯轉角怎麼接、水管怎麼繞過樑柱，老師傅不會每次都重新想一遍，因為業界早就有「這樣接最穩、以後最好修」的固定工法

寫程式也是，「這個物件該怎麼生出來」「這兩個模組要怎麼溝通，才不會誰改誰就跟著爆炸」「這段流程以後要讓別人擴充，但又不會讓他動到我的程式碼」，這些問題你我遇到的，前人幾乎都遇過，也整理出了幾種好用的解法

我希望自己在身處 AI 當道的世界裡面，不再焦慮的是會不會隨時被取代，而是 AI 給我的 code（或我自己寫的），我能最快速判斷優劣勢

而當然這個題目每年都會出現，每年都有人寫，一堆大神都寫得很好很棒，但始終不是我自己所寫，所以也沒辦法活用與內化

之後我將使用 C# 當作範例，以及輕鬆的小故事，我會透過 Design Pattern 說明

期許自己未來的30天，能穩定且順利的產出，第一次寫文，也請大家多多海涵，謝謝大家

延伸閱讀文章:

每一篇心得都有價值——為什麼初學者才更應該要寫心得筆記
寫作吧，菜鳥工程師！
我為什麼鼓勵工程師寫Blog