典型慘劇
覺得某些程式碼「應該沒用」，順手刪除幾行，重新編譯/執行 → 錯誤噴滿螢幕。截圖顯示的錯誤往往指向完全無關的行數，因為缺失的邏輯導致後續變數未初始化、物件為 null、流程跳轉錯誤。
為什麼會發生？
- 隱性相依：被刪代碼可能初始化關鍵物件、註冊事件、設定預設值、開啟連線等。
- 副作用：某方法雖「無回傳值」，但在建構子/屬性 setter 中執行了必要初始化。
- 條件編譯/反射：代碼可能透過反射、特性被動態調用，靜態分析掃描不到。
標準急救流程：二分法回溯
- 立即還原：Git/SVN/TFS `revert` 或 `checkout` 回刪除前版本，確認專案可正常建置。
- 小步提交：將「刪除代碼」拆分為多次微小提交，每次只刪一個邏輯塊（一個方法、一個屬性、一行註冊）。
- 每刪必建：每次刪除後執行 Build → Run Unit Tests → 手動冒煙測試**。
- 定位罪魁禍首：哪次提交導致建置失敗/測試紅燈，該塊代碼即為「必要代碼」。
- 重構而非刪除：若確認代碼確有冗余，應用「提煉方法」「移至基類」「標記 Obsolete」等重構手法，保留行為並清理結構。
工具輔助
- Git Bisect：自動二分查找引入錯誤的提交。
- Code Coverage：查看該代碼是否真無測試覆蓋（但小心反射調用）。
- ReSharper / Roslynator：靜態分析「未使用成員」，但需人工審核。
心法總結
「看不懂/覺得沒用」≠「可以刪除」。 專業開發者刪碼前必先寫測試、做影響分析、小步提交。遇到此類災情，先還原、再二分，是止血最快之道。
