YAGNI原則

​

什麼是 YAGNI 原則？

YAGNI原則是一種設計準則，勸告不要在程式碼庫或使用者群明確需要之前實現功能或建構系統。YAGNI是「You Aren’t Gonna Need It」（你不會需要它）的首字母縮寫（有時是「You Aren’t Going to Need It」），捕捉到了該原則的核心資訊：抵制為假設的未來場景建構靈活性的誘惑。

「總是在真正需要時實現事物，而不是在你僅僅預見可能需要它們時。」 — 肯特·貝克，《極限編程解析》

該原則源於極限編程（XP）方法論，該方法論強調簡單性、回饋和勇氣作為核心價值。XP從業者觀察到，開發者經常花費大量時間建構「靈活」的系統來預測各種未來場景——這些場景往往永遠不會出現。當這些未來需求確實出現時，它們通常與預測足夠不同，以至於準備工作仍然是浪費。 YAGNI與「技術債務」概念密切相關。在需要之前編寫的每一行程式碼都是必須維護、理解和解錯的債務。當實際需求出現時，匆忙的抽象可能不太合適，需要重構，這比簡單地直接實現需要的功能花費更多時間。YAGNI主張更簡單的道路：實現你現在需要的，當需求變得清晰時再重構。

​

YAGNI 原則的三個層次

• 入門: 當想要新增「防未來」程式碼時停下來問：「我實際上會使用這個，還是只是在猜測？」如果是猜測，就跳過它。你總是在需要被證實後新增它。
• 實踐: 使用測試驅動開發來揭示實際需求。讓測試揭示真正需要什麼功能，而不是預先想像所有可能的用例。
• 進階: 平衡YAGNI與注意程式碼何時需要重構的「氣味」。有時需要足夠緊迫以證明準備工作是合理的——但區分真正的訊號和投机性的預測。

​

起源

YAGNI原則是在1990年代後期出現的極限編程（XP）方法論中闡述的。肯特·貝克創造了這個術語並領導了XP運動，他將YAGNI描述為區別於傳統軟體開發方法論的核心實踐之一。 該原則在馬丁·佛勒（Martin Fowler）有影響力的著作《重構》（1999年）中有重要討論，該書討論了YAGNI與重構過程的關係。佛勒認為，當需求緊迫時，透過重構新增靈活性是適當的，但過早的泛化會導致不必要的複雜程式碼。 YAGNI流行的時機正值網路泡沫時代，軟體專案經常面臨快速交付的巨大壓力。該原則為快速開發的混亂提供了一個務實的回應：抵制建構複雜系統的衝動，專注於滿足目前需求，並相信未來需求可以在到來時得到解決。這種方法在許多專案中證明是有效的，導致YAGNI在XP社群之外被主流軟體開發所採用。

​

核心要點

​

應用場景

​

經典案例

Stripe，這家線上支付處理公司，在其早期開發中著名地採用了YAGNI原則。Stripe沒有建構精細的欺詐檢測系統、國際化功能或進階分析工具來預測未來需求，而是專注於極其出色地做一件事：實現簡單、可靠的線上支付。隨著公司成長，需求變得清晰，他們逐步新增功能。這種方法使Stripe比那些花了數年建構綜合平台的競爭對手移動得更快。當Stripe確實新增新功能時，它們是由實際客戶需求驅動的，而不是投机性的未來需求，結果是產品更好地匹配市場需求。

​

邊界與失效場景

YAGNI原則雖然有价值，但可能被誤用。首先，有些需求是真正可預測的。建構支援預期規模或符合已知法規的基礎設施可能證明「準備」是合理的，而不是投机性的。 其次，YAGNI並不意味著忽略好的設計實踐。編寫可重構的乾淨程式碼與建構投机性功能不同。該原則警告不要新增額外的功能，而不是不要保持程式碼品質。 第三，在某些領域，某種程度的超前思考是必不可少的。安全系統需要預測攻擊向量；安全關鍵系統需要考慮故障模式。YAGNI在這些情況下應該深思熟慮地應用。

​

常見誤區

​

相關概念

​

一句話總結