Hao程式筆記

FE Day 45 延伸路線：全端工程師的下一步 執行需求：CPU 可跑 。今天是「前端開發實戰：React 與 Next.js 全套」系列的最後一天。今天不學新框架、不裝新套件、不寫產品功能，而是把「下一步該往哪裡走」變成一條可以執行的路線：第一，用 Day 44 的能力盤點找出自己的缺口，而不是憑感覺決定要學什麼；第二，把缺口排成一份 90 天的計畫，每一週都有具體產出；第三，建立一份個人技術雷達，分成「採用、試驗、評估、暫緩」四環，讓追逐新工具這件事有節制；第四，把預約系統延伸成三個新作品的提案，用作品驅動學習。今天所有內容都是虛構示範，沿用 Day 31–44 的專案設定與資料格式，全部在本機 CPU 上就能跑。 引言 學完一個系列之後最危險的狀態，是「知道很多名詞，但不知道自己缺什麼」。最常發生的兩件事：一是繼續看更多教學，把學習本身當成產出，看了一百小時卻沒有多一個能用的作品；二是追著最新的工具跑，每次重寫都讓上一個作品變成沒人維護的孤島。兩者的共同問題不是「不夠努力」，而是「沒有方向」。 貫穿專案的「預約管理系統」是個小型服務業線上預約平台（情境涵蓋攝影棚、健身教練、諮詢工作室，所有資料都是虛構示範）。Day 44 結案時它是 11 個頁面、兩種角色、可測試、可部署、可交接的 v1.0.0。這是一個「完整但不夠深」的作品：它證明了你能把需求做成系統，還沒有回答「能把它做多深」。今天要把「深」與「廣」兩條路畫出來，並排出先後順序。 今天的內容分四段：第一段做最後一次對照，說明哪些能力已具備；第二段說明 T 型能力、作品驅動學習、技術雷達三個觀念；第三段實作缺口分析、90 天計畫、技術雷達、三個延伸提案與開源貢獻流程；第四段講長期學習的節奏。讀完之後你會拿到一份可以照著跑的 90 天計畫，以及一套判斷「這個新東西該不該花時間」的準則。 貫穿專案共用設定（Day 31–44 沿用） 最後一天同樣沿用這份設定，作為「已經具備什麼」的對照基準： 框架：Next.js 15（App Router、Server Components 預設）、React 19.x、TypeScript 5.9 樣式：Tailwind CSS 4.x、CSS variables 設計 token、 components/ui/ 六個基礎元件...

FE Day 44 系列總結 執行需求：CPU 可跑 。今天是「前端開發實戰：React 與 Next.js 全套」系列的第四十四天，也是貫穿專案「預約管理系統前端」的收尾日。今天做四件事：第一，把 44 天的路徑完整回顧一次，說清楚每個階段為什麼排在這個位置；第二，寫一支盤點腳本，用客觀數字回答「這個專案最後到底交付了什麼」；第三，跑一次完整的驗收流程（型別檢查、lint、單元測試、端對端與無障礙檢查、production 建置），並把結果寫成結案報告；第四，標記 v1.0.0 並列出已知限制。今天不引入任何新工具、不新增功能，全部沿用 Day 31–43 的共用設定，在 CPU 上就能完整跑完。 引言 學習系列最容易被跳過的就是最後一天。前面每一天都有明確的產出（一個元件、一支測試、一次部署），到了總結日反而變成「說感想」，讀者看過就忘。今天刻意反過來做：把總結變成一次可執行的驗收。因為「這個系列到底學到什麼」這個問題，不該用形容詞回答，而該用「跑得過的檢查、數得出來的檔案、說得出理由的決定」回答。 貫穿專案的「預約管理系統」是個小型服務業線上預約平台（情境涵蓋攝影棚、健身教練、諮詢工作室，所有資料都是虛構示範）。這個專案從 2026 年 3 月 17 日的導論開始，到今天剛好走完 44 篇：從 Node.js 22 與 pnpm 的環境配置、TypeScript 5.9 的型別系統、React 19.x 的元件與狀態、Vitest 3.x 與 Playwright 1.5x 的測試、Next.js 15 的 App Router 與 Server Components，一路做到 Day 31–43 的 11 個頁面、兩角色登入、三層錯誤處理、效能調校、部署與交接資料。今天的任務是把這些片段接成一條線。 今天的內容分四段：第一段把 Day 31–43 的共用設定做最後一次統整；第二段說明這 44 天的路徑設計邏輯，以及「後端工程師轉全端」真正的心態變化；第三段實作盤點腳本、結案報告產生器、發布前檢查與完整驗收 workflow，最後標記 v1.0.0；第四段講這個專案接下來最該補的三個地方。讀完之後你會拿到一份自己的結案報告範本，以及一套能在任何專案重複使用的驗收清單。 貫穿專案共用設定（Day 31–44 沿用） 這份設定從 Day...

FE Day 43 文件與交接 執行需求：CPU 可跑 。今天是「前端開發實戰：React 與 Next.js 全套」系列的第四十三天，貫穿專案「預約管理系統前端」進入交付階段。今天不寫產品功能，只做一件事：把 42 天累積的知識從「在某個人腦子裡」變成「在專案裡」。具體交付八份資料：一份主說明（README）、一份架構與路由地圖、一份 API 契約對照表、三份決策紀錄（ADR）、一份環境變數清單、一份值班手冊（Runbook）、一份貢獻指南加 PR 模板、一份新成員上線檢核表；再寫一支自動產生路由文件的腳本，讓文件不會跟程式碼脫節。今天所有資料都是虛構示範，沿用 Day 31–42 的共用設定，不連任何外部服務。 引言 大部分 side project 不是死在「做不出來」，而是死在「做出來之後沒人敢動」。三個月後你想加一個新欄位，打開專案才發現：不知道 AuthProvider 為什麼把 access token 放非 httpOnly cookie、不知道 NEXT_PUBLIC_API_MODE 有哪幾種值、不知道 mock 帳號在哪、不知道部署失敗時該先看哪個儀表板。於是你花了半天重新讀程式碼，才敢下第一行修改。這段「重新理解」的時間就是交接成本，而它的高低完全取決於今天這一天有沒有做。 貫穿專案的「預約管理系統」是個小型服務業線上預約平台（情境涵蓋攝影棚、健身教練、諮詢工作室，所有資料都是虛構示範）。專案到 Day 42 為止的樣貌是：Next.js 15 App Router、React 19.x、TypeScript 5.9、Tailwind CSS 4.x；11 個頁面、兩種角色、5 個 reducer 動作的登入狀態機、一套 components/ui/ 設計系統、三層錯誤處理、Vitest 3.x 加 Playwright 1.5x 的測試、以及 Day 41 的部署設定與 Day 42 的品質檢查。 今天的內容分四段：第一段把 Day 31–42 的共用設定再次統整；第二段說明「交接要交付哪四種資料」以及為什麼「為什麼」比「怎麼做」重要；第三段實作八份交接資料與一支自動產生腳本；第四段講文件維護的節奏與常見錯誤。讀完之後你會拿到一套可以直接放進自己專案的資料骨架。 貫穿專案共用設定（Day 31–44 沿用） ...

FE Day 42 無障礙與響應式總檢 執行需求：CPU 可跑 。今天是「前端開發實戰：React 與 Next.js 全套」系列的第四十二天，貫穿專案「預約管理系統前端」進入上線前的最後一輪品質檢查。今天不寫新功能，只做四件事：第一，用 @axe-core/playwright 把 11 個頁面全部掃一遍，違規就讓 CI 失敗；第二，用 Playwright 走一遍純鍵盤流程（Skip Link、篩選面板、對話框焦點鎖定）；第三，在 390、768、1200、1440 四種寬度各截一張圖，並自動檢查水平溢出與觸控目標大小；第四，把掃出來的違規一項一項修掉（對話框焦點、手機版篩選收合、響應式表格、色彩對比、減少動畫偏好）。今天所有資料都是虛構示範，沿用 Day 31–41 的 NEXT_PUBLIC_API_MODE=mock 離線模式，不連任何後端也能完整跑完檢查。 引言 無障礙（a11y）與響應式（responsive）是兩個最常在「上線前最後一週」才被想起來的主題。它們的共同點是：平時看不出問題，出問題時代價很高。一個沒有 label 的輸入框在桌機上看起來完全正常，但螢幕閱讀器使用者會聽到「編輯框」而不知道要填什麼；一個寫死的 320 像素側欄在 1440 寬的螢幕上像教科書，在 390 寬的手機上卻會把整個版面撐出水平捲軸。 貫穿專案的「預約管理系統」是個小型服務業線上預約平台（情境涵蓋攝影棚、健身教練、諮詢工作室，所有資料都是虛構示範）。Day 31–37 把 11 個頁面做完、Day 38 做完登入與角色導向、Day 39 做完效能調校、Day 40 做完測試金字塔、Day 41 部署到 Vercel。今天要做的，是把 Day 28 的 a11y 基礎與 Day 33 提到的「手機版篩選」收尾：把自動掃描、鍵盤走訪、多斷點檢視這三件事寫成可重複執行的測試，並且讓每一條都接進 Day 40 的 CI 流程。做完之後，「上線品質」不再靠人工憑感覺，而是有一組會自動擋下回歸的檢查。 今天的內容分四段：第一段把 Day 31–41 的共用設定再次統整；第二段說明 WCAG 2.2 AA 的判準、行動優先的斷點策略、以及觸控目標與焦點可見性的具體數字；第三段實作三支 Playwright 檢查與四個修正；第四段整合進 CI 並跑一次完整結...

FE Day 41 部署實戰 執行需求：需外部服務帳號 。今天是「前端開發實戰：React 與 Next.js 全套」系列的第四十一天，貫穿專案「預約管理系統前端」進入上線階段。前 40 天我們把 11 個頁面、角色導向、資料層、測試與效能都做完，今天把整套部署流程跑完：建立 Vercel 專案、設定三層環境變數、串接 GitHub Actions 做持續整合、啟用 Speed Insights 與 Sentry、設定自訂網域與 HTTPS，並補上一條不依賴 Vercel 的自架伺服器路線。本文所有設定都以 2026 年 3 月的主流版本為準，環境變數與金鑰一律放在平台的環境設定裡，不寫進程式碼。 引言 部署是前端最容易被低估的工作。看起來「把程式碼推上去就好」，但真正上線後才會遇到：環境變數少設一個就整頁壞、預覽環境不小心連到正式資料庫、原始碼對照檔（source map）沒上傳所以錯誤堆疊看不懂、持續整合沒接好所以合併前不知道有沒有壞。這些都不是「寫程式的問題」，而是「部署工程的問題」。 貫穿專案的「預約管理系統」是個小型服務業線上預約平台（情境涵蓋攝影棚、健身教練、語言家教、諮詢工作室，所有資料皆為虛構示範）。前 40 天我們完成了 11 個頁面、admin 與 customer 兩種角色的分流、Day 36 的資料層、Day 37 的錯誤處理、Day 39 的效能調整與 Day 40 的測試套件。今天要把這些成果推上正式環境：前端部署到 Vercel，後端維持 Web 系列的 FastAPI（自架或放在託管平台），並把 CORS、cookie 與環境變數對齊。Day 41 是「可上線的完整系統」這個里程碑的兌現日。 今天的內容分五段：第一段把部署選項與環境分離講清楚；第二段走 Vercel 的完整流程（環境變數、設定檔、持續整合、Sentry、自訂網域）；第三段補一條自架伺服器路線（standalone 輸出、systemd、Caddy）；第四段整理常見錯誤；第五段說明部署後的驗收與巡檢。讀完之後你會拿到完整的部署設定、一份 CI workflow、一份 Runbook，以及一份部署後的驗收清單。 貫穿專案共用設定（Day 31–44 沿用） 今天所有部署相關設定都建立在 Day 31–40 的技術堆疊上： 框架：Nex...

FE Day 40 測試與驗收 執行需求：CPU 可跑 。今天把 Day 38 的登入流程、Day 39 的效能調校都用 Vitest 3.x 與 Playwright 1.5x 寫成可重現的回歸測試，並補上 axe-core 的無障礙自動檢查。具體四件事：第一，把 AuthProvider 的 reducer 寫成 Vitest 單元測試（沿用 Day 38）；第二，用 Playwright 寫 E2E 測試覆蓋登入、下單、後台確認三條核心路徑；第三，在每個 E2E 測試內加入 axe-core 掃描，a11y 違規就 fail；第四，把 Lighthouse 跑進 CI，效能預算超標就 fail。所有資料仍是虛構示範，沿用 Day 31-39 的共用設定；無真實後端時用 mock 模式讓測試可以完全離線跑。 引言 測試是軟體工程的「保險絲」。沒寫測試的程式碼在規模還小時看起來「沒事」，一旦擴充就會開始出現「改 A 壞 B」的鬼故事。對前端來說測試有三個層次：單元測試驗證函式邏輯、元件測試驗證渲染、E2E 測試驗證使用者流程。今天會把這三層都寫一遍，讓預約管理系統在 CI 階段就能抓到 90% 的回歸問題。 貫穿專案的「預約管理系統」是個小型服務業線上預約平台（情境涵蓋攝影棚、健身教練、諮詢工作室，所有資料都是虛構示範）。Day 31-37 把介面建好、Day 38 把登入與角色導向完成、Day 39 把效能調到健康。今天進入「測試與驗收」：把所有流程包成 Vitest + Playwright 雙層測試，並用 axe-core 自動檢查 a11y、用 Lighthouse 守住效能預算。這層做完之後，整個專案的「可維護性」就到位了：未來任何改動都能在 5 分鐘內被驗證。 今天的內容分四段：第一段設定 Vitest 環境並寫 reducer / API client 的單元測試；第二段用 Playwright 寫 E2E 測試覆蓋三條核心路徑；第三段在 E2E 內嵌入 axe-core 做 a11y 自動檢查；第四段用 Lighthouse 與 bundle 大小設定 CI 守護。讀完這篇你會了解：Vitest 3.x 與 React Testing Library 的搭配、Playwright 1.5x 的 fixture 與平行測試、axe...