鐵人檔案
我是文科背景、正準備轉職的軟體小白。這系列用同一個「代購 App」案例貫穿 30 天，以 Top-down 學習法先建立系統設計的宏觀視角，再逐步深入細節。內容分五階段：界定範疇與約束、資料流與狀態管理、模組化與 SOLID 原則、測試與效能、系統演進與回顧。每篇都誠實記錄我卡在哪裡、怎麼想通的。如果你也是非本科、正在自學路上，這系列是寫給你們的！
Overview：新手上路，請多包容 作為一個軟體小白，網路上的資訊琳瑯滿目，最容易碰到的問題莫過於沒有頭緒、不知道從何下手的棘手狀況。有了 AI 的協助以後，...
昨天提及系統的 In Scope 與 Out of Scope，但知道要做什麼跟能動手寫 code，中間還差了一大截。以我們的代購 App 為例：如果只是把買家...
上一篇我們透過使用者故事、使用案例、驗收標準，把痛點轉化為更嚴謹的規格，了解使用者想做什麼、系統該做什麼反應。但軟體系統不能只有動態行為，還必須有承載這些行為的...
昨天我們把代購 App 的靜態資料結構定案——買家、商品、訂單這些實體怎麼互相關聯，也知道哪張表該有哪些欄位。但資料表只回答了「東西存在哪裡」，沒有回答「畫面現...
昨天我們用有限狀態機把代購 App 的訂單生命週期定義清楚——待採購、採購中、已購入、運送中、已送達、已取消，每個狀態能往哪裡轉、不能往哪裡轉，都畫成了圖。但那...
昨天我們談的是 API 怎麼定義前後端之間的合約——資料怎麼包裝、怎麼送、送到之後狀態碼代表什麼意思。但那份合約只解決了「資料怎麼安全地從後端搬到前端」，沒有回...
昨天我們把訂單資料正規化成 byId 物件加 allIds 陣列，解決了「查找快不快」的問題。但正規化只處理了資料怎麼擺放，沒有處理另一個更容易出錯的問題：像「...
昨天我們談的是 SSOT：狀態應該只存一份原始資料，其他都是即時算出來的衍生結果。但那只解決了「資料該放在哪裡」，沒有回答另一個問題：這份原始資料，誰都可以隨手...
在掌握了單向資料流的基礎後，我們開始面對另一個棘手的挑戰：狀態應該存放在哪裡？剛開始，我們傾向於將所有狀態放在組件內部（Local State），但隨著代購 A...
昨天我們解決了「這份狀態誰拿得到」的問題——局部狀態留在元件裡，跨頁共用的狀態升級成全域狀態。但升級成全域狀態，不代表它撐得過使用者按下重新整理。只要沒有額外寫...
