軟體開發中的YAGNI原則:真的需要那個抽象或通用代碼嗎?
在快速變化的軟體開發世界中,開發人員常常努力通過為未來建設來使他們的應用程式具有未來適應性。 但正如來自CodeOpinion.com的Derek Comartin在他富有洞見的影片"您真的需要那種抽象或通用代碼嗎?"中所警告的,為推測的需求進行建設通常會引入不必要的複雜性並浪費寶貴的資源。
本文將引導您通過Derek對YAGNI原則的實用解釋,使用真實世界的示例和開發者的經驗來幫助您更好地理解和應用YAGNI於您的日常編碼中。 無論您是專注於清晰代碼、敏捷軟體開發,還是只想避免不必要的功能,Derek的評論都提供了一條穩健的前進道路。
什麼是YAGNI? 不要構建您不會需要的東西
這個討論的核心是YAGNI原則,代表您不會需要它——這是極限編程和精實軟體開發中一個關鍵概念。 正如Derek所解釋的,YAGNI告訴開發人員不要實施他們認為將來會需要的功能或功能,而要專注於當前的需求。
Derek補充了細微差別:雖然您應避免寫推測性的代碼,但也不要讓自己無法在以後進行調整。 挑戰在於避免花時間在可能有用的功能上,同時保持開放的態度以應對變化。 這是敏捷軟體和軟體工程中的一個常見困境。
他描述了兩個YAGNI的常見誤用:
-
功能規劃——您預期未來的需求並開始現在就構建。
- 代碼抽象——您提早對現有代碼進行泛化或抽象,猜測可能需要其他功能。
在這兩種情況下,結果通常是浪費的努力、增加的複雜性,以及功能蔓延——這正是好做法和KISS原則(保持簡單, 愚蠢)所反對的。
一個真實的例子:貨運通知系統
為了說明,Derek使用了一個當用戶的包裹被交付時發送SMS的貨運管理系統的例子。 該系統使用Twilio,特性通過處理交付事件、獲取聯繫資訊並發送消息來工作。
這個簡單的代碼開發過程解決了當前的需求。 它簡單、可測試且提供價值。 但隨之而來的問題是:如果我們將來想更換SMS供應商怎麼辦?
這是許多開發人員錯誤引用YAGNI原則的地方。 他們認為,由於以後可能會有其他實施,他們需要現在就抽象SMS邏輯。 因此他們創建了一個如ISmsService的介面。
抽象:您是否在為一個可能不存在的未來建設?
Derek質疑這種早期抽象:如果您只有一個實施,且沒有當前需要更換供應商的需求,那麼為什麼要抽象化? 您是在為一個可能永遠不會出現的未來需求增加不必要的複雜性。
他進一步通過說明軟體工程成本來解釋。當您最終增加第二個供應商時,您會發現您的界面過於緊密地耦合於Twilio的特定需求(如其"發自"電話號邏輯)。 突然間,抽象變成了一種責任。 這就是如何在有限知識的基礎上構建抽象經常會引入漏洞並使重構變得複雜。
這裡的關鍵收穫是:您不是在節省時間,而是由於缺乏充分背景構建了錯誤的東西。
過早變得通用:開發者陷阱
在計算機科學專案中最常見的YAGNI違規之一是,在需要之前過早地使事物通用。 Derek通過另一個例子來探究這個問題——將SMS和電子郵件通知分組為單一的通用通知系統。
為此,開發者可能會定義一個NotificationType(SMS或Email),一個通用地址欄位,並創建一個處理兩者的單一服務。 但這種過於抽象的設計最終複雜化了邏輯,並創造了脆弱且難以維護的條件代碼路徑。
這是典型的功能蔓延,也是忽視精簡軟體開發和堅實原則的標誌。 您正在編寫對當前用戶需求沒有任何意義的推測性代碼——這對於任何敏捷軟體開發過程來說都是一個紅旗。
優先擴展而不是修改
而不是過度設計,Derek建議使用最簡易的解決方案:如果您日後需要支持電子郵件通知,只需單獨實施該功能。
使用事件驅動架構,每個事件都可以觸發多個獨立處理器。 例如,一個處理器用於SMS,另一個用於電子郵件。 您後來可以移除一個而不影響另一個。 這種方法促進了簡單性,支持變更需求,並尊重關注點的分離——這些都與敏捷和測試驅動開發最佳實踐相符。
通過構建可擴展而不是過度設計的系統,您便於保留靈活性,而無需預測每一個可能的未來。 這就是如何避免不必要的複雜性並保持適應力。
違反YAGNI的真正成本
Derek強調了構建不必要功能的真正成本:
-
花時間建造您從未使用的東西
-
增加的複雜性不提供即時價值
-
增加的開發者維護未使用或過度構建代碼的成本
- 由於過度設計造成更多的漏洞和錯誤
這與敏捷軟體開發的另一個核心原則一致:專注於現在提供價值,而不是可能的將來。
他指出,即使經驗豐富的開發者也常常犯錯,信任他們對未來需求的直覺——但結果是錯誤的。 即使有經驗,預測系統在幾個月之後的需求通常是一場輸掉的遊戲。
最後想法:背景很重要,簡單性獲勝
Derek總結時澄清說,他並不反對設計原則或抽象。 事實上,他相信構建能夠演化的系統。 但錯誤在於無當前理由地實施內容——本質上違反了YAGNI。
他鼓勵開發人員"撰寫現在具有價值的代碼並實現有價值的功能"。避免以犧牲當前用戶為代價去追逐未來的需求。 堅持清晰的代碼實踐,並偏好支持變更而不將您鎖定在推測性結構中的設計策略。
他還邀請開發者分享他們自己的YAGNI恐怖故事,在這些故事中,他們為未來建設卻再也沒需要過——這在許多項目中都是一個常見的故事。
結論:將YAGNI應用於您的開發過程中
YAGNI 原則仍然是開發人員工具箱中最有價值的工具之一。 它與敏捷、精簡和KISS哲學相符,提醒我們只建構所需的內容——僅此而已。 Derek Comartin在他影片中對這一想法的剖析,通過真實世界的代碼和開發過程示例,提供了如何有效地應用YAGNI的明確指南。
因此,下次當您想增加一層抽象、通用類或額外功能時,暫停並問自己:
您是在解決一個現有問題,還是在解決一個您只是在猜測可能會出現的問題?
避免將時間浪費在假想的未來上。 專注於今天創造價值。 保持您的軟體簡單、可維護、並響應實際需求。
因為很有可能——您不會需要它。
