在不斷發展的軟體開發領域中，圍繞程式碼複雜性和可維護性的激烈爭論正在興起。雖然傳統觀點常常強調編寫可擴充套件的程式碼，但開發者社群最近的討論提出了一個反直覺的方法：優先考慮易於刪除的程式碼，而不是易於擴充套件的程式碼。
複雜性的代價
最近的社群討論突出了對過度工程化解決方案隱藏成本的日益關注。開發者們越來越發現，複雜的抽象雖然旨在使程式碼更加靈活，但往往會導致幾乎無法消除的技術債務。
正如一位開發者指出，糟糕的複製貼上程式碼會導致令人煩惱的技術債務修復下午。而糟糕的抽象程式碼則會導致數月的技術債務償還。這個觀察挑戰了關於程式碼重用和抽象的傳統觀點。
簡單性的案例
從社群討論中emerged出幾個關鍵原則：
- 從簡單開始，保持簡單
- 最初構建單體應用
- 在基礎設施上部署（如單個虛擬機器）
- 避免過早最佳化
- 僅在必要時擴充套件
- 三次法則
- 第一次：編寫它
- 第二次：複製它
- 第三次：考慮重構
- 第四次：一定要重構
- 模組化設計
- 將業務邏輯與實現分離
- 保持技術細節隔離
- 使元件可獨立替換
現實世界的例子
一個引人注目的例子來自 X11 和 Wayland 顯示伺服器的比較。社群注意到，儘管 Wayland 試圖實現現代化，但它變得比 X11 更復雜。像截圖或獲取視窗位置這樣的簡單操作需要透過多層抽象來導航，而 X11 的直接方法使這些任務更容易管理。
複雜性的權衡
討論中一個有趣的觀察是，軟體往往透過以下兩種方式之一變得最複雜：
- 透過固有的領域複雜性
- 透過開發者引入的人為複雜性
可維護程式碼的最佳實踐
基於社群見解，以下是關鍵建議：
- 專注於當前需求
- 解決實際問題，而不是假設性問題
- 避免構建框架，當使用現有框架就足夠時
- 保持抽象最小化且有目的性
- 為刪除而設計
- 使元件可獨立移除
- 避免系統間的深度整合
- 保持介面簡單明瞭
- 戰略性測試
- 編寫能識別可處理程式碼的測試
- 關注核心功能
- 確保可以安全地進行更改
程式碼維護的未來
隨著 AI 和 LLM 的出現，一些開發者對未來的維護能力持樂觀態度。儘管目前的結果仍然有限，但人們推測可以使用 LLM 來幫助清理程式碼庫、刪除未使用的程式碼並新增合理的文件。
社群共識似乎很明確：雖然編寫可擴充套件的程式碼本身沒有錯，但重點應該是編寫易於理解、範圍適當，並且在必要時易於刪除的程式碼。這種方法可能是我們對抗現代軟體開發中不可避免的技術債務積累的最佳防線。