0 天前，這個系列從一個很簡單的問題開始：為什麼不能直接寫 code？今天作為最後一篇，想回頭梳理這一路走來，思考方式到底發生了什麼轉變，以及作為一個文科背景、準備申請資訊管理研究所的自學者，接下來的學習地圖該怎麼畫。

一、回顧 Top-down 學習法的五個階段

這個系列用同一個代購 App，依序走過五個階段：

1. 界定範疇與約束（Day 1–5）：從鐵三角、User Story、ERD、狀態機到 API 規格，先把「系統該做什麼、不該做什麼」界定清楚。
2. 資料流與狀態管理（Day 6–12）：從陣列與物件的取捨、SSOT、單向資料流、快取，到競態條件與資料驗證，處理資料如何被正確存放與流動。
3. 模組化與 SOLID（Day 13–20）：從程式碼壞味道、分層架構、SRP、OCP、DIP，到工廠模式、錯誤處理與重構，處理程式碼如何組織才經得起變動。
4. 測試與效能（Day 21–26）：從純函式、測試金字塔、Big-O、防抖節流，到打包工具與 Linter，處理系統如何長期維持健康。
5. 系統演進與回顧（Day 27–30）：從規模化、AI 時代的工程師價值、取捨的回顧，到今天的總結。

二、思考模型的三個轉變

回頭看，這 30 天最大的改變不是記住了更多名詞，而是腦中多了三個習慣。

第一，從「名詞」到「關係」。 剛開始讀 User Story、ERD、FSM，每個都是獨立的名詞；後來才發現它們是同一個系統在不同角度的描述，一個功能會依序穿過需求、資料、狀態、介面。

第二，從「找正確答案」到「評估取捨」。 Day 29 談過，架構的一切都是取捨。現在面對同一個需求，腦中會自動多問一句：這樣做的代價是什麼、換來的好處值不值得。

第三，從「怎麼寫」到「怎麼定義與驗證」。 Day 28 談到，程式碼生成的門檻越來越低，價值會集中在釐清問題、定義規則、驗證結果，這也是為什麼 Day 26 的 Linter 與 Day 22 的測試，其實都只是架構的一部分。

三、代購 App 教會我的事

用同一個案例貫穿 30 天，最大的收穫是看到「同一筆訂單」，會被不同的關注點反覆檢視：

• Day 2：這筆訂單的需求，用 User Story 描述。
• Day 3、4：它的資料結構是 ERD，生命週期是狀態機。
• Day 5、12：它透過 API 傳輸，進來之前要先驗證。
• Day 11：兩個人搶最後一件商品時，要靠原子操作。
• Day 14、15：處理它的程式碼，被拆成分層與單一職責的模組。
• Day 19、22：失敗時怎麼優雅降級，邏輯怎麼用測試守住。
• Day 27：訂單量成長 100 倍，架構怎麼演進。

原則不是孤立的知識點，而是同一個問題，從不同角度被反覆檢視的結果。

四、未來的 CS 學習地圖

這個系列走的是 Top-down，優點是先有宏觀地圖，缺點是很多地方只是蜻蜓點水。完賽之後，我想對照一份自學者常用的 CS 路線（Teach Yourself Computer Science），它列出九個核心主題：程式設計、電腦架構、演算法與資料結構、離散數學、作業系統、網路、資料庫、語言與編譯器、分散式系統。對照這個系列碰過的地方：

我自己排的順序是：先補「資料結構與演算法」和「資料庫」，因為這個系列最常碰到它們，也最貼近資訊管理的核心課程；接著是網路與作業系統，最後才是分散式系統與離散數學。這個排序是依這 30 天暴露出的缺口自己排的，並不是該指南的建議順序，之後也許會隨著課程要求調整。

學習方式上，我打算延續這個系列的做法：每讀完一個主題，就回頭問它在代購 App 的哪個環節出現過，再用自己的話寫一次，卡住的地方也照實記錄。這樣學到的就不只是名詞的定義，而是知識之間的連結。對文科背景的人來說，這種「用故事串起概念」的方式，也許比從零開始背誦教科書更容易堅持下去。

五、結語

這系列從「為什麼不能直接寫 code」出發，繞了一圈，最後回到同一個答案：真實世界的複雜度，往往比介面呈現更高，而系統設計的意義，就是在這些複雜度之間，找到一個說得出理由的取捨。如果你也是非本科、正在自學的路上，我想說的是：先有地圖，再慢慢走深，並不會比較慢；每個人卡住的地方不同，把它誠實寫下來，就是最好的學習紀錄。完賽不是終點，而是確認了這條路或許走得通。