> ## Documentation Index > Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt > Use this file to discover all available pages before exploring further. # YAGNI原則 > YAGNI原則（你不會需要它）建議不要在需要之前建構功能。了解其起源、應用場景以及YAGNI如何防止過度工程。 **類別**: 原則
**類型**: 軟體開發原則
**起源**: 極限編程，1999 / 重構，1999
**別名**: YAGNI、你不會需要它 **快速回答** — YAGNI原則（You Aren't Gonna Need It）是一個軟體開發指南，建議程式設計師不要在真正需要之前新增功能。YAGNI在1990年代後期由極限編程（XP）從業者推廣，作為應對常見趨勢的對策：預測未來需求並「以防萬一」建構複雜的系統。該原則認為，過早的泛化會增加複雜性，消耗開發時間，而且當實際需求與預測不符時，這些努力往往會被浪費。 ## 什麼是 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社群之外被主流軟體開發所採用。 ## 核心要點 「以防萬一」建構功能會產生不必要的複雜性。YAGNI透過將實現限制在目前需求來保持程式碼簡單。 在投机功能上花費的時間是沒有花在實際需求上的時間。YAGNI將開發工作重點放在最重要的地方。 未使用的程式碼成為必須維護的技術債務。YAGNI透過避免可能不需要的程式碼來最小化這種負擔。 當需求變得清晰時，從簡單的實現重構比從複雜的過度工程實現更容易。 ## 應用場景 只建立使用者或利益相關者明確要求的功能。避免新增目前不有用的配置選項、鉤子或擴展點。 根據目前需求設計API，而不是想像的未來用例。根據需求新增端點和參數，而不是預先猜測。 為目前需求建立資料庫結構。隨著應用程式的發展新增表格、欄位和關係，而不是試圖預測所有未來的需求。 根據目前專案需求選擇框架和函式庫。當更簡單的解決方案滿足目前需求時，避免新增複雜的框架「以防萬一」。 ## 經典案例 Stripe，這家線上支付處理公司，在其早期開發中著名地採用了YAGNI原則。Stripe沒有建構精細的欺詐檢測系統、國際化功能或進階分析工具來預測未來需求，而是專注於極其出色地做一件事：實現簡單、可靠的線上支付。隨著公司成長，需求變得清晰，他們逐步新增功能。這種方法使Stripe比那些花了數年建構綜合平台的競爭對手移動得更快。當Stripe確實新增新功能時，它們是由實際客戶需求驅動的，而不是投机性的未來需求，結果是產品更好地匹配市場需求。 ## 邊界與失效場景 YAGNI原則雖然有价值，但可能被誤用。首先，有些需求是真正可預測的。建構支援預期規模或符合已知法規的基礎設施可能證明「準備」是合理的，而不是投机性的。 其次，YAGNI並不意味著忽略好的設計實踐。編寫可重構的乾淨程式碼與建構投机性功能不同。該原則警告不要新增額外的功能，而不是不要保持程式碼品質。 第三，在某些領域，某種程度的超前思考是必不可少的。安全系統需要預測攻擊向量；安全關鍵系統需要考慮故障模式。YAGNI在這些情況下應該深思熟慮地應用。 ## 常見誤區 YAGNI不禁止考慮架構——它禁止建構不必要的功能。支援已知需求的好架構仍然是有價值的。 YAGNI是關於功能範圍，而不是程式碼品質。解決目前需求的乾淨、可維護的程式碼總是比不管YAGNI如何的混亂程式碼更好。 DRY和YAGNI協同工作。DRY在重複存在時提取重複；YAGNI在重複被證實之前防止建立抽象。它們以不同的方式簡化程式碼庫。 ## 相關概念 YAGNI和KISS都主張簡單性。YAGNI防止新增不必要的功能；KISS防止使這些功能複雜化。 DRY在重複存在時提取重複；YAGNI防止建立不必要的重複。它們相互補充，保持簡單的程式碼庫。 MVP透過只建立提供價值所需的功能來體現YAGNI。額外功能根據回饋新增。 YAGNI透過防止不必要的程式碼來幫助避免累積技術債務。每個未使用的功能都會增加維護負擔。 TDD自然支援YAGNI，因為它只驅動使測試通過所需的功能。 ## 一句話總結 你不會需要它——抵制為假設的未來需求建構功能；實現你現在需要的，當需求變得清晰時再重構。