在軟體開發社群中，圍繞著程式設計最基本原則之一的 DRY（不要重複自己）展開了一場激烈的討論。雖然這一原則傳統上被視為良好軟體設計的基石，但近期的討論揭示了對程式碼重複及其在可維護軟體中作用的更深層次理解。
DRY 原則的演變
軟體開發社群正在經歷著對程式碼重複認知的重大轉變。曾經被視為重罪的做法，如今正在透過實踐經驗的視角被重新評估。許多開發者發現，機械地應用 DRY 原則可能導致不必要的複雜抽象，以及難以維護的緊耦合程式碼。
可控重複的理由
越來越多有經驗的開發者認為，相比過早抽象，某種程度的程式碼重複可能更可取。關鍵的見解是，看似相似的程式碼可能並不代表相同的底層概念，強行抽象可能會帶來比解決更多的問題。
應該始終保持一致的事物應該有一個共同的命名，而可能存在差異的事物應該有獨立的命名。這樣做能為開發者提供一個堅實的基礎，使得區域性更改不太可能破壞整個程式。
三次法則
社群討論揭示了關於三次法則的一個有趣模式——程式碼可以重複一次（產生兩個副本），但當出現第三個例項時就應該考慮抽象。然而，經驗豐富的開發者提醒說，這不應該被視為一個硬性規則。相反，是否抽象的決定應該基於對一個例項的未來更改是否必然要求其他例項做出相同更改。
關鍵社群見解：
- DRY （不要重複自己）與 WET （重複寫兩次）的方法對比
- 程式碼重複的"三次法則"
- 過早抽象對程式碼可維護性的影響
- 可測試性與實用設計之間的平衡
測試和設計理念
關於可測試性和良好設計之間的關係，出現了一個有趣的觀點。雖然有人認為難以測試的程式碼表明設計不佳，但也有人認為為了使程式碼可測試而增加不必要的複雜性。這引發了關於實用軟體開發和理論最佳實踐之間平衡的更廣泛討論。
對現代開發的影響
這場爭論的影響超出了個別編碼決策的範疇。團隊越來越認識到，嚴格遵守 DRY 等原則可能會導致所謂的抽象地獄——追求程式碼複用反而創造出複雜的依賴網路，使系統更難理解和維護。
總的來說，軟體開發社群正在向對程式碼重複的更細微理解發展。開發者們不再將 DRY 視為絕對規則，而是將其視為工具箱中的眾多工具之一，需要根據具體情況和未來維護影響來謹慎應用。