軟體開發中的YAGNI原則：您真的需要那個抽象或通用程式碼嗎？

在快速發展的軟體開發世界中，開發者常常致力於為未來做好準備。 但正如CodeOpinion.com的Derek Comartin在他發人深省的影片中警告的，"您是否真的需要那個抽象或通用程式碼？"，為了不確定的需求而構建往往會引入不必要的複雜性並浪費寶貴的資源。

本文將通過Derek對YAGNI原則的實用解釋，使用真實世界的例子和開發者的經驗，幫助您更好地理解和應用YAGNI在您的日常編碼中。 無論您專注於乾淨的程式碼、敏捷軟體開發，還是僅僅希望避免不必要的功能，Derek的評論都提供了一條穩健的前進之路。

什麼是YAGNI？ 不要構建您不需要的東西

這次討論的核心是YAGNI原則，即您用不到它—來自極限編程和精益軟體開發的一個關鍵概念。 正如Derek解釋的，YAGNI告訴開發者不要實施他們認為將來需要的功能，而要專注於當前的需求。

Derek增加了微妙的層次：雖然您應該避免撰寫推測性的程式碼，但您也不應該讓自己無法在之後做出調整。 挑戰在於避免花時間在可能有用的功能上，同時保持開放以便變更。 這是敏捷軟體和軟體工程中的一個常見困境。

他描述了YAGNI的兩種常見誤用：

1. 功能規劃 - 您預見未來的需求並開始構建。

2. 程式碼抽象 - 您過早對現有程式碼進行泛型化或抽象，猜測可能需要的其他功能。

在這兩種情況下，結果通常是浪費精力、增加複雜性和功能蠕變—恰好與良好實踐和KISS原則（維持簡單，愚蠢）所推崇的相反。

真實例子：發貨通知系統

為了說明，Derek使用了一個發貨管理系統的例子，該系統在使用者包裹送達後發送SMS。 系統使用Twilio，該功能通過處理發貨事件、獲取聯繫資訊並發送消息來實現。

這個簡單的程式碼開發過程滿足了當前的需求。 簡單，可測試並帶來價值。 但隨之而來的問題是：如果我們想要更換SMS服務提供商怎麼辦？

這是許多開發者錯誤應用YAGNI原則的地方。 他們假設因為將來可能會有另一種實現，所以現在需要抽象出SMS邏輯。 所以他們建立了一個像ISmsService的介面。

抽象：您是在為可能不存在的未來進行構建嗎？

Derek挑戰這個過早的抽象：如果您只有一個實現，且沒有需要更改供應商的當前需求，那為什麼要抽象？ 您是在為了讓未來的需求更輕鬆而新增不必要的複雜性，而這些需求可能永遠不會實現。

他進一步通過說明軟體工程的成本來表達。當您最終新增第二個提供商時，您會發現您的介面過於緊密地與Twilio的特定需求（例如其"自"電話號碼邏輯）耦合。 突然間，這個抽象成為一個負擔。 這就是建立在有限知識上的抽象常常引入的錯誤，並使重構複雜化的原因。

此處的關鍵要點是：您並不是在節省時間，而是由於上下文不足而建立了錯誤的東西。

過早地走向通用解決方案：開發者的陷阱

計算機科學項目中最常見的YAGNI違背之一是推動在需要之前通用化。 Derek通過另一個例子來探索這一點－將SMS和電子郵件通知分組到一個通用的通知系統中。

為此，開發者可能會定義一個NotificationType（SMS或電子郵件），一個通用地址字段，並建立一個處理兩者的服務。 但這個過度抽象的設計最終會使邏輯複雜化，並建立脆弱且難以維護的條件程式碼路徑。

這是典型的功能臃腫，並且忽略了精益軟體開發和堅固原則的標誌。 您正在撰寫不滿足當前使用者需求的推測程式碼－在任何敏捷軟體開發過程中都是紅旗。

偏好擴展而非修改

而不是過度設計，Derek建議選擇最簡單的解決方案：如果以後需要支持電子郵件通知，只需單獨實施該功能。

使用事件驅動的架構，每個事件可以觸發多個獨立的處理程式。 例如，一個處理SMS，另一個處理電子郵件。 以後您可以刪除一個而不影響另一個。 這種方法促進了簡單性，支持變更需求，並尊重職責分離—這些都符合敏捷和測試驅動開發的最佳實踐。

通過構建可擴展的而非過度設計的系統，您避免預測每個可能的未來仍保持靈活性。 這就是您避免不必要的複雜性並保持適應能力的方法。

違反YAGNI的真正成本

Derek強調構建不必要功能的真正成本：

• 花時間構建您從未使用過的東西

• 增加的複雜性未能提供即時價值

• 開發者現在需維護未使用或過度構建程式碼的更高擁有成本

• 由於過度設計導致的錯誤和失誤更多

這與另一個敏捷軟體開發的核心原則一致：專注於現在交付的價值，而不是可能後來的價值。

他指出，經驗豐富的開發者經常犯信任自己對未來需要的直覺的錯誤—並且錯了。 即使有經驗，預測您系統幾個月後的需求通常是一個失敗的遊戲。

最後的想法：上下文重要，簡單贏得勝利

Derek總結說明他並不反對設計原則或抽象。 事實上，他相信構建可演進的系統。 但錯誤在於在沒有當前理由的情況下實施事物—基本上違反了YAGNI。

他鼓勵開發者 "撰寫程式碼和實施現在有價值的功能"。 避免在犧牲當前使用者的基礎上追逐未來需求。 堅持乾淨程式碼的實踐，並偏好可支持變更而不讓您陷入推測結構的設計策略。

他還邀請開發者分享他們自己的YAGNI恐怖故事，這是他們為未來構建且從未需要過的—在許多專案中的常見故事。

結論：將YAGNI應用於您的開發過程中

YAGNI原則仍然是開發者工具箱中最有價值的工具之一。 這與敏捷、精益和KISS哲學對齊，提醒我們構建所需的—僅此而已。 Derek Comartin在他的影片中通過真實世界的程式碼和開發過程例子分解了這一想法，提供了如何有效應用YAGNI的明確指導。

因此，下一次當您受到誘惑，新增抽象層、一個通用類或一個額外功能時，停下來問問自己：

您是在解決當前的問題—還是只是猜測可能一天會出現的問題？

避免將時間花在想像的未來上。 專注於今天建造價值。 保持您的軟體簡單、易維護並響應真正的需求。

因為可能性是—您用不上它。