當 AI 能快速產生程式碼,開發者的價值該如何重新理解?本系列用 30 天,從需求釐清、程式設計、資料與狀態,到測試、安全、部署及維護,透過實際情境,探討開發者仍需掌握的核心觀念。我們不只關心程式能不能執行,更要學會判斷問題是否解對、結果如何驗證,以及系統是否值得信任。工具與實作方式會改變,但軟體開發裡需要理解的問題、做出的取捨,以及承擔的責任,仍然存在。
在軟體開發中,我們已經能把規格文件、架構背景與既有程式碼餵給AI,讓它協助梳理設計、生成實作,甚至撰寫測試。但隨著AI產出程式碼的速度遠超以往,一個根本問題浮上...
使用者提出的功能,真的能解決他的困難嗎? 接到需求文件時,我們通常會開始想:畫面怎麼做、API怎麼設計、資料要怎麼存。但在動手前,我會先弄清楚這個功能要改善...
從已確認的需求出發,理解限制、討論取捨,並驗證結果。 昨天透過訂單與庫存服務的例子,談到「重新處理」按鈕背後,其實是營運人員希望能查明異常結果,並自行接續處...
如何找出假設、限制與例外情況? 昨天延續營運後台的例子,談到批次重新處理訂單時,需要核對庫存服務的容量,確認正常訂單與批次作業能否一起滿足服務要求。 假設團...
如何比較效益、成本,以及不做的代價? 前幾天從「重新處理」按鈕,談到批次操作與排隊期間的狀態變化,需要照顧的地方越來越多。 今天先往回看:營運人員原本的困難...
如何把完整需求拆成自己能理解、實作與驗證的問題? 昨天談到自動恢復的效益與成本。決定要做之後,接下來就是把需求轉成實際的程式修改。 「完成自動恢復」是一個目...