鐵人檔案
當 AI 能快速產生程式碼，開發者的價值該如何重新理解？本系列用 30 天，從需求釐清、程式設計、資料與狀態，到測試、安全、部署及維護，透過實際情境，探討開發者仍需掌握的核心觀念。我們不只關心程式能不能執行，更要學會判斷問題是否解對、結果如何驗證，以及系統是否值得信任。工具與實作方式會改變，但軟體開發裡需要理解的問題、做出的取捨，以及承擔的責任，仍然存在。
在軟體開發中，我們已經能把規格文件、架構背景與既有程式碼餵給AI，讓它協助梳理設計、生成實作，甚至撰寫測試。但隨著AI產出程式碼的速度遠超以往，一個根本問題浮上...
使用者提出的功能，真的能解決他的困難嗎？ 假設我們維護一套接單系統。使用者送出訂單後，系統會呼叫庫存服務扣減可售數量，再更新訂單狀態。某天，營運人員提出需求...
需求已經確認，現有系統撐得住嗎？ 昨天透過訂單與庫存服務的例子，談到「重新處理」按鈕背後，其實是營運人員希望能查明異常結果，並自行接續處理。今天把這個例子往...
昨天談到批次重新處理訂單時，需要核對庫存服務的容量。假設團隊評估後，決定讓批次工作先排隊，再以受控的速率處理，營運人員稍後查看逐筆結果。 流程看起來很完整：勾選...
前幾天從「重新處理」按鈕，談到批次操作與排隊期間的狀態變化，需要照顧的地方越來越多。 今天先往回看：營運人員原本的困難，是訂單呼叫庫存服務逾時後，無法確認結果，...
昨天決定加入自動恢復。依照規則，背景工作查到庫存已扣減，就同步訂單狀態；仍在處理，就稍後再查；符合補送條件時，才沿用原識別重試。 規則很清楚，實作時可以先拆成三...
這一行取得庫存，下一行就拿來判斷能不能接單。這個判斷成立嗎？ 維護訂單系統時，可能會看到這一行： var stock = await inventory.G...
昨天談到，同樣叫做庫存，可能是在庫量，也可能是可售量。名稱提供了理解的起點，而我們如何命名，也會影響同事與AI接下來怎麼使用這份資料。 例如，要替既有訂單流程加...
一段修改狀態的程式，誰能改？什麼狀態能改？哪些入口可能繞過檢查直接改？ 假設公司的規則是：商品交付物流前可以取消，交付後不能取消，但符合條件時可以申請退貨。...
取消出貨的API回傳成功，客服畫面就可以顯示「已取消」嗎？要看這個成功，代表取消已完成，還是系統已經收到要求，準備稍後處理。這個差別會直接影響後面的程式。畫面要...
