該如何學好 “寫程式” #4. 你的程式夠 “可靠” 嗎?
摘要提示
- 軟體工程師定位: 從把程式「寫對」進階為把程式「寫好」，善用資源與方法整合解決方案。
- 可靠性核心: 穩定、少錯、易讀，並具備面對未知狀況的防禦與診斷能力。
- DEBUG/RELEASE觀念: 以不同模式讓問題浮現，在不影響正式版效能與可讀性的前提下加強檢查。
- 經典參考: Steve Maguire《Writing Solid Code》的Trace/Assert理念至今仍適用。
- 實務案例: 線上測驗計分程式，透過多個答案卷測出「未作答仍計分」「負分」等缺陷。
- 防呆檢查的代價: 過多if/catch與訊息會讓程式難讀、效能差、開發時間增加。
- Trace與Assert: 在關鍵假設處加斷言與訊息，DEBUG可見、RELEASE可關，讓非正常狀態立即暴露。
- 假設明確化: 用Assert描述「應該為真」的前置條件/不變式/後置條件，降低隱性錯誤。
- 可維運性: 讓問題容易被發現與定位，比「等出錯再改」更專業有效。
- 與單元測試關係: Unit Test源自Trace/Assert思維，後續可延伸至系統化測試與品質工程。
全文重點
本文從「programmer」到「software engineer」的角色轉換談起：前者重視演算法與資料結構、把功能「寫對」，後者則需在系統層面整合資源、安排結構、強化可靠性、面對未知問題，進而把程式「寫好」。作者將「可靠性」視為軟體工程專業度的關鍵衡量：除了穩定與低錯誤率，更要在設計與開發期建立能讓問題早期浮現、易於診斷與修正的機制。
文章以線上測驗計分的C#範例為主軸。初版程式在理想答案下能正確計分，但當面對更貼近現實的輸入（如只答對一題、未作答、全錯）便暴露出多個缺陷：未作答仍計分、總分可為負數等。工程師以「補if判斷」修補，短期能解，但導致閱讀性、效能與開發成本惡化。作者指出此非專業長解，因為檢查應聚焦於「讓異常浮現」，而不應用大量流程碼淹沒正常邏輯。
作者引介《Writing Solid Code》之經典作法：在DEBUG/RELEASE兩種模式下，利用Trace與Assert建立「輕量、系統化」的防護與診斷。Assert用來聲明程式在某點的假設（如不可為null、數量需一致、分數界線），在DEBUG時違反即中止並提示，讓異常「立即被看見」；Trace則記錄關鍵訊息（如偵測到未作答），在開發與除錯時出現在IDE輸出視窗，而在RELEASE時可透過設定關閉，不影響效能與可讀性。這種做法把輸入驗證、邏輯不變式與邊界條件轉化為「可開關的診斷機制」，保留核心流程的清晰性，同時增強在非預期狀況下的免疫力。
文章最後強調，真正的專業不是「壞了再修」，而是用設計與工具降低錯誤發生機率、縮短定位時間、確保生產版不受診斷碼拖累。作者預告後續會延伸到更進階的Assert應用與單元測試，並點出Unit Test的精神其實源自Trace/Assert：以明確假設與可驗證行為，系統化地提升軟體品質與可靠度。
段落重點
從programmer到software engineer：專業度的轉換
作者將軟體工程師定位為能在系統層面整合解法與資源的資深角色：不僅挑演算法/資料結構，還要安排code與工具、理解OS與API、設計良好結構、維護擴充性、並具備面對未知問題與自學的能力。若programmer是把程式「寫對」，software engineer就是以專業方法把程式「寫好」。專業不僅在於產出功能，更在於可靠、易維護、能對未知情境防禦且便於調試的系統性能力。
程式要有足夠的可靠性
作者以Steve Maguire《Writing Solid Code》作為理論基礎，強調可靠性的多面向：穩定度、低BUG、可讀性、對未知狀況的免疫。並提醒不要把原則當口號，而要在實作中體現。本文採用重寫示例的方式，將經典觀念用C#表達，使其符合現代開發脈絡，並邀請讀者自省：現有程式中藏了多少未爆彈？
要讓問題浮現出來：善用DEBUG/RELEASE模式
專業與否看對BUG的態度：不是「出事再修」，而是主動降低BUG密度，讓問題早暴露、易定位。Visual Studio提供Debug/Release切換，但關鍵是理解其意義與策略。作者採線上測驗計分案例，展示一般在「理想輸入」下看似正確的程式，一旦以不同答案卷測試，便出現未作答仍計分、總分負值等缺陷，說明僅憑功能happy path測試不足以保證可靠性。
實例演進：從初版到多次修補的缺陷暴露
初版程式在完美答案卷下運作正常；改以只答對一題或未作答的答案卷測試，立刻現形：未作答情況被錯算加分。工程師補上「未作答視為放棄」的邏輯後，又被全錯情境揭露「總分可能為負」的問題，再以「總分下限0分」修補。此過程顯示：現實輸入多變，僅靠逐案補洞將陷入無止盡的防呆if，難以控管品質與成本。
檢查碼氾濫的代價與侷限
作者點出三大問題：1) 可讀性變差，正常流程被大量檢查碼覆蓋；2) 效能變差，許多檢查屬一次性輸入驗證或開發期需求，不應常駐；3) 時間成本高，寫檢查碼遠比功能碼耗時。雖然防呆重要，但若方式不對，將犧牲維護性與效能，且仍無法系統性預防未知問題。需要更聰明的機制，讓「診斷」與「正式行為」分離。
以Trace/Assert建立專業級的診斷與防護
承襲《Writing Solid Code》，作者在C#中使用System.Diagnostics的Trace與Assert：用Assert宣告關鍵假設（非null、數量一致、分數邊界等），一旦違反在DEBUG中斷並提示；用Trace在DEBUG輸出關鍵訊息（如偵測未作答），便於追蹤。同時在RELEASE可透過設定關閉，不影響效能與可讀性。示例將原本雜亂的if檢查改為精煉的Assert/Trace，核心計分流程因此清晰，且在異常輸入下能即時暴露問題與原因。此法把「假設」顯性化、可驗證化，是提升可靠性的關鍵。
小結與後續：從斷言走向單元測試與品質工程
作者總結：可靠性的本質在於設計期與開發期的預防與診斷能力，Assert猶如在系統各處設置警示，讓非正常狀態無所遁形；Trace則提供上下文訊息以輔助調試。這與單元測試一脈相承：皆源自對程式「可檢驗假設」的明確化。後續將進一步探討更進階的Assert應用與如何延伸到單元測試，逐步建立系統化的品質保障。
資訊整理
知識架構圖
- 前置知識：
- 基本程式設計能力與良好習慣（控制流程、函式、例外處理）
- 資料結構與演算法的基礎
- C#/.NET 基礎、Visual Studio 使用、XML/XPath 讀寫
- Debug/Release 概念、偵錯基本功（中斷點、觀察值、輸出視窗）
- 核心概念：
- 可靠性與防禦式設計：降低 Bug、處理未知狀況、讓問題在可控環境中浮現
- Debug 與 Release 的分工：開發期顯示問題、發佈期降低開銷
- Trace/Assert 機制：把「假設」轉為可驗證的斷言與診斷訊息
- 檢查與可讀性/效能的平衡：把檢查放在 Debug 可開關，避免污染主流程與成本
- 測試案例設計：以正常、放棄、全錯、邊界值等輸入逼出缺陷
- 技術依賴：
- .NET System.Diagnostics（Trace、Debug、Assert、Listeners）
- 應用程式組態控制追蹤/斷言開關（非僅依賴 Debug/Release）
- XML DOM/XPath 解析與驗證（結構匹配、欄位存在性）
- IDE 整合（VS Output 視窗、偵錯體驗）
- 應用場景：
- 計分/金額等對精確性敏感的業務（如線上測驗、金融計算）
- 函式庫/平台元件開發（明確界定呼叫前置條件）
- 團隊開發與維運（快速定位問題、降低回歸風險）
- 任何需要將「設計假設」具體化並可運行驗證的系統
學習路徑建議
- 入門者路徑：
- 熟悉 C#/.NET 與 Visual Studio 基本偵錯（中斷點、監看、Output）
- 在小專案中加上 Trace.WriteLine 與 Trace.Assert，體會問題浮現
- 練習以多種輸入情境（正確、未作答、全錯、結構不符）觀察程式行為
- 進階者路徑：
- 系統性地以斷言表達前置條件/不變式/後置條件（設計合約思維）
- 以組態控制追蹤與斷言，建立不同環境（Dev/Test/Prod）的診斷策略
- 將斷言輔以單元測試，擴充到自動化測試與邊界案例集合
- 改善程式結構：將正常流程與診斷/檢查分離，提升可讀性
- 實戰路徑：
- 在 CI/CD 中啟用偵錯建置與測試集，保留 Trace 以協助失敗定位
- 設定 Trace Listeners（文件、ETW、Console）與金絲雀/灰度發布觀測
- 針對核心邏輯（如計分、金額）建立失敗即警示的斷言與日誌告警
- 以真實與合成資料進行壓力與異常情境演練（Null、結構不符、邊界值）
關鍵要點清單
- 程式設計師 vs. 軟體工程師：前者把程式寫對、後者把程式寫好並用專業方法控風險（優先級: 高）
- 可靠性定義：穩定、少 Bug、可讀、能防未知狀況（優先級: 高）
- 問題早現原則：在開發環境讓錯誤盡量暴露，降低上線風險（優先級: 高）
- Trace/Assert 的角色：把設計假設具體化並可運行驗證（優先級: 高）
- Debug/Release 分工：Debug 強檢查與訊息、Release 輕量與效能（優先級: 高）
- 組態控制追蹤：.NET 以設定檔切換追蹤/斷言與輸出管道（優先級: 中）
- 邏輯與檢查分離：避免檢查碼淹沒主流程，維持可讀性（優先級: 中）
- 邊界與例外情境測試：未作答、全錯、負分上限、結構不符等案例（優先級: 高）
- 前置條件斷言：呼叫端必傳非空資料且結構匹配（優先級: 高）
- 後置條件斷言：結果在合理範圍（如總分不為負、題目分數上下限）（優先級: 高）
- 日誌策略：以 Trace.WriteLine 記錄診斷而非汙染商業邏輯（優先級: 中）
- 效能考量：將昂貴檢查放進可關閉的偵錯路徑（優先級: 中）
- 單元測試關聯：單元測試源於斷言/追蹤思想，兩者互補（優先級: 中）
- 輸入驗證責任界面：清楚界定輸入層與核心邏輯的驗證責任（優先級: 中）
- 專案治理：以規範要求斷言覆蓋率與關鍵路徑的診斷設置（優先級: 中）
