鐵人檔案
我是文科背景、正準備轉職的軟體小白。這系列用同一個「代購 App」案例貫穿 30 天，以 Top-down 學習法先建立系統設計的宏觀視角，再逐步深入細節。內容分五階段：界定範疇與約束、資料流與狀態管理、模組化與 SOLID 原則、測試與效能、系統演進與回顧。每篇都誠實記錄我卡在哪裡、怎麼想通的。如果你也是非本科、正在自學路上，這系列是寫給你們的！
昨天我們替瀏覽器裡的資料規劃了三種儲存機制的生命週期。但不管資料存在哪裡，前端要拿到後端的資料，中間永遠有一段「等待」的時間——這段等待處理不好，會產生比資料遺...
昨天我們確保了「操作發生的順序」不會出錯——檢查跟扣除庫存綁成同一個原子操作，不怕被插隊。但操作順序再正確，如果送進來的資料本身就是錯的、甚至是惡意的，系統一樣...
前兩天我們處理的是資料本身的正確性——操作順序不能亂、送進來的內容不能假。從今天開始進入系列的第三階段，視角要往上拉一層：不再看「這筆資料對不對」，而是看「程式...
昨天我們看到高耦合怎麼把程式碼纏成一團麻——商品抓取、訂單計算、通知、資料庫連線全擠在同一個函式裡，改一處就牽動全部。今天要談的分層架構，就是預防這件事發生的具...
昨天我們用分層架構把系統切成表現層、邏輯層、資料層三塊。但「層」本身還是可能很肥大——邏輯層裡如果塞了十件不相干的事，一樣會變回 Day 13 講的高耦合，只是...
昨天的 SRP 讓每個類別、模組都只負責一件事。但職責分乾淨之後，還有一個問題沒解決：當系統要「新增」一項功能時，該怎麼加，才不會又把已經寫好、測過的程式碼弄壞...
昨天談到 OCP 和 DIP，重點都放在「程式碼之間該怎麼依賴抽象」這個概念層次。今天要往下一層，看實際的程式碼要怎麼被組織成一個個可以獨立替換、匯入匯出的單位...
過去兩天，抽象介面在 OCP、DIP 和工廠模式裡反覆出現。今天要把「依賴於介面，而非依賴於實作」這句設計模式領域最早提出的核心原則單獨拆開來講清楚——它其實是...
過去三天談的都是「程式碼正常運作時，該怎麼被組織」。今天要換一個角度：當程式碼「不正常運作」、發生錯誤的時候，系統該怎麼被設計來應對——這同樣需要架構層級的規劃...
過去幾天談的 OCP、DIP、模組化、介面抽象、錯誤處理，都是「理想中程式碼該有的樣子」。但現實中大部分程式碼都是先求能動、再求好——今天要談的重構，就是把已經...
