在效率與可靠性之間掙扎：程式設計的取捨藝術

完成功能只是底線，面對真實世界需在效能、穩定、可維護、可擴展中尋找平衡。效率與可靠性往往相互衝突，需視情境抉擇。

案例一：SqlDataReader 讀取欄位值

// 方式 1：索引器 + ToString()，支援 NULL 值
string name = reader["UserName"].ToString();

// 方式 2：強型別 GetString，效率高但遇 NULL 會拋例外
string name = reader.GetString(1); // 若資料為 DBNull → InvalidOperationException

分析：方式 2 確實較快，但資料庫欄位允許 NULL 時會崩潰。策略：
— 欄位定義為 NOT NULL → 用方式 2 追求效能。
— 欄位可為 NULL → 用方式 1 或先判斷 reader.IsDBNull(1) 再用方式 2。

案例二：FileUpload 圖片上傳的偽成功陷阱

使用者選檔後手動竄改 TextBox 路徑指向不存在檔案，SaveAs 竟回傳「成功」且建立 0 bytes 檔案。

防禦性程式設計：

string path = upImage.PostedFile.FileName;
if (File.Exists(path)) {  // 先驗證來源檔案存在
    // 格式檢查、儲存邏輯...
} else {
    Response.Write("來源檔案不存在");
}

雙重檢查（格式 + 存在性）雖稍降效率，卻能阻擋異常輸入造成的資料汙染。

決策框架

1. 識別風險：哪些輸入、環境、資料狀態會導致失效？
2. 量化成本：防禦代碼的效能損失 vs 失效造成的業務損失。
3. 分層防護：資料庫層約束（NOT NULL、CHECK）、資料存取層參數化查詢、業務層驗證、UI 層輸入限制。
4. 可觀測性：關鍵路徑加入日誌、監控、告警，事後可追溯。

結語

優雅的程式不是零防禦，而是在正確的地方放置適當的防禦。為了那 1% 的意外情況寫 99% 的防禦代碼看似低效，卻是專業工程師對系統可靠性負責的表現。