Day30_程式開發完成了，下一步是讓它繼續變好

回到第一天按下按鈕的那一刻

Day0 提到，我第一次寫 WinForms 時，只是讓一個按鈕照著自己的想法動起來，就開心得像小孩把積木拼成功。30 天後回頭看，那份開心還在，只是我現在更清楚：按鈕會動，是故事的開頭，不是結尾。

一個真的要交給別人使用的網站，背後有很多人看不到的工作。畫面要讓人知道怎麼操作，後端要守住業務規則，資料庫不能把紀錄弄丟；功能完成後，還要測試、部署，也要準備面對下一次修改。寫程式有趣的地方就在這裡。你解完一題，常常只是終於看見下一題。

這 30 天，我沒有把重點放在大量的程式語法，而是跟著 ProjectManagementWeb 走過一次比較完整的開發過程。因為語法忘了可以查，套件也會更新；如果連問題是什麼、誰要使用、怎樣才算完成都說不清楚，程式寫得再快也可能走錯方向。

這 30 天，其實是在走同一條路

前幾天先從專案管理、運算思維與 User Story 出發，確認網站要替誰解決什麼問題。接著用 Mermaid、C4、流程圖與資料庫 Schema 畫出系統的骨架，再逐步碰到前後端分離、JWT、API 契約和規格驅動開發。

中段開始談測試、模擬資料、排程、Log、Git 與 Docker。到了後段，才真正讓 Agent 依規格實作前後端，把文件和程式對在一起，進行自動化測試與人工驗收，最後部署到 Google Cloud。網站上線後又加入大頭貼需求，於是 Change Request、Git Flow 與 CI/CD 也跟著登場。

看起來像 30 個分散的主題，攤開後其實是一條連續的路：

這張圖故意沒有列出每一個工具。Vue、ASP.NET Core、SQL Server、Docker 或 Google Cloud 都很重要，但它們是在不同路段派上用場的交通工具。真正把整段路串起來的，是前一個決定會成為下一步的依據：User Story 影響畫面和流程，流程影響 API 與資料，規格再變成測試與驗收條件。

一個網站比較像一間工坊

剛接觸軟體開發時，很容易把網站想成「會寫 Code 的人做出來的東西」。實際走過一次後，我覺得它更像一間工坊。

前端像接待區，負責讓使用者看懂資訊並完成操作。後端像裡面的工作台，收到要求後，按照規則處理事情。資料庫是檔案室，保管帳號、專案與工作項目。測試則像品管員，拿著檢查表確認原本能用的地方沒有被新修改弄壞。最後，部署流程把成品送到使用者面前；CI/CD 則把每次都要重做的檢查與搬運流程固定下來。

少了任何一個角色，網站都可能「看起來完成」，卻不一定能安心使用。畫面漂亮但權限沒守好，問題很大；API 回傳正常，但資料寫錯地方，也不算成功。軟體工程師的工作因此不只是把程式打進編輯器，而是在這些角色之間找出問題、釐清責任，再確認它們能一起工作。

AI 把速度加快了，方向盤還是要有人握著

AI 確實降低了開始寫程式的門檻。以前需要查很久的語法，現在幾句描述就能得到範例；規格、測試與文件也可以更快整理。不過，速度變快不代表背後的知識消失了。

我會把人與 AI 的合作想成騎一台協力車。AI 坐在後座，很會踩，也帶著一整箱工具；人坐在前面，要看路、握方向盤，還得知道何時煞車。前面的人如果只喊「快一點」，後座真的可能踩得很快，只是兩個人一起衝進錯的岔路。

這也是為什麼系列中一直反覆出現規格、責任邊界和驗證。Prompt Engineering、Context Engineering 或 Harness Engineering 這些名稱可能還會繼續變，但實際工作離不開幾個老問題：要解決什麼？哪些規則不能破壞？Agent 做完後，我拿什麼證明結果正確？

Agent 可以幫忙找路、搬工具，也能一次處理很多檔案。需求取捨、風險判斷與最後驗收，仍然需要人負責。這不是因為 AI 不好用，正好相反；工具越有力量，越需要知道它正在往哪裡使力。

這一版 ProjectManagementWeb 完成了

走到第 30 天，ProjectManagementWeb 已經完成這次系列設定的開發目標。前端提供實際操作畫面，後端處理權限與業務規則，資料由 SQL Server 保存；共用規格則記錄 User Story、架構、流程、Schema 與測試案例。系統也走過自動化測試、手動驗收，並部署到 Google Cloud。

Day29 再把三個 Repository 接上 CI/CD。程式 Push 到 GitHub 後，Workflow 會執行各自需要的檢查；正式版本則經過核准，再部署到 Google Cloud。Branch Ruleset、Production Environment 與 Workload Identity Federation 也把合併規則、部署權限和雲端身分接在同一條交付流程上。

所以，這一版可以說是完成了最初的第一版。它能從需求、規格一路走到實作、測試與部署，也有文件和版本紀錄可以追查。完成並不是把 Repository 鎖起來，而是目前答應要做的事情已經交付；之後想到的新功能，會從這個穩定版本繼續往下發展。

三個 Repository，各自留下一份可以接手的成果

這個專案拆成三個 Repository，不是把檔案隨便分成三堆，而是讓每一邊有清楚的責任：

• ProjectManagementWeb Spec：保存 User Story、系統規格、C4、流程圖、Schema、測試案例與變更紀錄。它回答「我們準備做什麼」。
• ProjectManagementWeb Frontend：使用 Vue 3、TypeScript 與 Vite 實作操作畫面，並透過明確的 HTTP Service 與後端溝通。它處理「使用者怎麼操作」。
• ProjectManagementWeb Backend：使用 ASP.NET Core、EF Core 與 SQL Server 實作 API、權限、資料規則、排程與稽核。它負責「系統如何守住規則」。

三份成果必須互相對得上。規格說可以做，前端卻沒有入口；前端送出一個欄位，後端契約卻不接受；資料庫已改，文件仍停在舊版本，這些都會讓下一位接手的人花時間猜答案。程式會執行，文件則讓人知道它為什麼這樣執行。

如果你也是剛開始學軟體開發

不用等到所有技術都學會才開始。那一天大概不會來，因為工具永遠會冒出新的版本。我比較建議挑一個自己真的看得懂的小問題，先把第一版做小，再一步步補齊。

可以先寫下一個使用情境，例如「使用者能建立工作項目，並看到到期日」。接著畫出操作流程，決定要保存哪些資料，再實作最小的一條成功路徑。它能動之後，故意輸入錯誤資料、重複操作，看看系統會不會露出問題。最後再請另一個人試用；你會很快發現，使用者總能走出一條你沒想過的路。

卡住也很正常。真正的差別往往不是「誰從來不會卡住」，而是卡住後能不能把問題縮小、找到證據，然後再試一次。這套習慣比背下某個框架的所有 API 更耐用。

完賽之後，回到下一次迭代

30 天的文章在這裡收尾，這一版 ProjectManagementWeb 也正式完成。接下來可以先實際使用，看看哪些操作還能更順手；如果想到新的功能，再重新整理需求、評估影響，接著修改規格、實作與驗收。軟體的日常比較像繞圈，但每繞一圈，都應該比上一圈多留下一點可追查的紀錄。

接下來，我會以這個完成的版本為起點，繼續想想還能加入哪些功能，或把哪些操作調整得更順手。同時，我也會繼續整理 AI 與軟體開發的實作筆記。至於這 30 天帶走的東西，我想不是某一段特別厲害的 Code，而是一套遇到問題時可以再走一次的方法：先弄清楚，再動手；做完要驗證，上線後繼續觀察。

第一天那顆按鈕已經不只是會動了。現在，我也比較知道它為什麼要動，以及動錯時該去哪裡找答案。