我是 PRUM 株式會社的 masa。
今天要談在開發現場非常重要、發生在程式設計前後的流程。內容僅為這些流程的一小部分，主要希望能擴展初學工程師或剛入門工程師們的一點見解。
-
【程式設計之前】「要做什麼」的共識是一切
工程師的工作從程式設計之前就開始了。如果這部分疏忽，再怎麼寫出漂亮的程式碼，也可能做出沒有人喜歡的東西。
不只看得見的功能，也要掌握不易看見的「品質」
在做「更新使用者資訊的按鈕」時，工程師新手常只想到「儲存資料的功能」這類的功能需求（功能要件）。當然這很重要，但實作不易看見的非功能需求（非功能要件）也同樣重要。
功能要件（系統能做什麼）
系統所提供的「功能」本身。
例：能登入、商品能加入購物車、能顯示搜尋結果。
也就是「看得見的動作」。
非功能要件
除了功能以外的「效能」或「可靠性」。
例：畫面在 1 秒內開啟（效能）、非維護期間不中斷（高可用性）、不會被駭客攻擊（安全性/資安）。
也就是支撐「理所當然」的品質。
用蓋房子的比喻來說…
- 功能要件：「要有廚房」「有兩間臥室」
- 非功能要件：「能抗震到震度7（耐震性）」「冬天也要暖和（隔熱）」
再華麗的廚房，如果冬天冷到受不了，也不想住那房子。系統也是一樣。
不注意非功能要件最終會導致返工
在系統開發中，最想避免的是「返工」。我自己也有過一次經驗：因為對規格的誤解，花了三天寫的程式，在 code review 被說「完全沒考慮錯誤情況，這樣不能發布」，結果整個被打回重寫。
程式設計只是「手段」。在把「機制具體化」之前，與領導者（如技術負責或產品負責人）把完成品的想像先對齊非常重要。
我所在的團隊在開始寫程式前，會先由 Scrum 團隊（開發團隊）聚在一起把需求釐清到位。
- 如果把這個功能實作拆解成邏輯，該怎麼做才成立？
- 這些資訊目前無法從 API 取得，這個開發週期（Sprint）能用替代資料嗎？
像這樣，程式設計師、Scrum Master（≒ 開發領導）、企劃會不斷討論。
一切都是為了在期限內完整實現需求，並產出高品質的成果。
-
【程式設計之後】「測試」是對自己程式的誠實
「在本機随便點點看起來有動作就結束開發」是業餘的思維。
工程師也要在「測試」上下功夫，確認系統不會壞掉。
測試主要需要兩個視角：
- 白箱測試：查看程式內部結構，偵測潛在問題。
- 黑箱測試：針對各種輸入檢查是否得到預期結果。
經由這些測試找出問題並修正，才能刷亮產品品質。
錯誤往往藏在資料的邊界值
除錯通常不是發生在預期內的資料，而是落在「資料的變化點（邊界值）」附近。
邊界值附近的錯誤範例
例如，在服飾電商有一雙 Nike 限量鞋做折扣，且有購買限制：每人最多能放入購物車的數量為「5 個以下」。
下面的程式碼，當使用者選擇 5 個並按下加入購物車時會發生錯誤，使用者會困惑不已。也就是說產品未能滿足功能要件。
// ❌ 錯誤的程式碼
// 本來應該允許「5 個」，但這樣只允許「小於 5」
if (inputQuantity < 5) {
processOrder(); // 輸入 5 時，會跳過這裡導致錯誤
}
// ✅ 正確的程式碼
// 應該包含「5 個」在內（以下）
if (inputQuantity <= 5) {
processOrder();
}
像這樣，當數值作為限制條件時，程式描述上前後差一個符號就可能造成 bug。
初學者應注意的測試心法
「不要盲信自己的程式碼」。嘗試各種輸入模式，確認是否得到預期結果。重複這個流程，才會漸漸有把握可以發布。
總結
重要的是持續做「把需求釐清、徹底測試」的基本功。先從意識到在你面前的程式碼背後的使用者開始。這種意識會帶來行動，例如「這個需求可能不需要了，要跟主管/客戶確認一下」「這個 bug 出了會影響使用者，這部分也要好好測試」，最終你就能產出高品質的成果。
PRUM 的工程師超過 95% 是從無經驗錄用的。
歡迎造訪公司網站。
▶ 公司網站
我們也經營一個整理對工程師有用文章的網站，如果有興趣歡迎看看。
▶ 對工程師有用的文章網站
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
