在開發過程中，經常會遇到一種很常見的問題：即使程式碼本身是正確的，最終做出來的成果，卻仍然和使用者真正想要的東西存在落差。這種落差通常不是技術實作的問題，而是來自於不同角色之間，對「系統行為」的理解並不一致。

自從踏入軟體開發職場後，我最早認識到的開發流程之一就是 TDD，我也認為他應該是每位軟體開發者都應該知道的開發流程，即使在實務上並非所有專案或情境都適合採用，但我覺得能有 TDD 的概念也很棒。

自數位轉型年代開始，軟體開發領域開始流行 DDD 一詞的說法，所謂領域驅動設計 Domain-Driven Design (DDD) 是一種軟體設計方法論，核心目的是讓程式設計與商業邏輯緊密對齊，以便未來因應商業需求變更。

為了解決層與層之間的耦合，內部核心 Entities、Use Cases 去依賴外部格式，可能會造成今天欄位異動，連動核心需要跟著去修改，違反了依賴反轉原則（DIP），日後要擴充或是重構也是一大挑戰。

近期在重構部落格時，發現過去一直都有靜態資源載入的問題，例如 layout structure 先出來了，但圖片還在 loading，後來也發現其實 astro 有針對這類靜態資源做優化。

題是經典的 Catalan Number / Unique BST 問題，給你 1～n 不同數字，問可以組出多少種不同結構的 BST（Binary Search Tree），主要想記錄一下 DP 的練習題。

Power of Three，主要想記錄看到一個很有趣的解法，這題非常簡單，就是找到3的冪次方，回傳 true，要挑戰的就是不要用迴圈來完成。

在日常開發中，你可能會經常使用 rebase 來重新定義分支的基準點，讓 commit history 保持線性與乾淨。不過在第一次操作時，很多人會對它感到不安，擔心一不小心就把 commit 弄不見。但實際上，rebase 並不會真的刪除你的歷史 commit。

從過去不管是找工作或推甄面試，還是社交場合與人溝通，又或是跨部門合作時，有多次情境會碰到需要短時間介紹或敘事一個內容，這也是最快讓別人認識你的機會，如果沒有經過練習通常很難講得流暢。