YAGNI - 不能命名的敏捷實踐？

Question

隨着我越來越多地將敏捷思維融入工作方式，yagni（「你不會需要它」）似乎變得越來越重要。在我看來，這是最有效的規則之一，用於過濾出被誤導的優先事項，並決定接下來要處理的內容。

然而yagni似乎是一個在這裏幾乎沒有耳語的概念。我運行了強制性搜索，它只顯示在一個問題標題中 - 然後是次要角色。

這是爲什麼？我是否高估其重要性？

免責聲明。爲了搶先回應，我確信我會反對，讓我強調yagni是與快速和骯髒的相反。它鼓勵您將寶貴的時間和精力集中在獲得您需要的零件上。

這裏有一些可能會問的問題。

我的單元測試是根據用戶需求還是框架結構選擇的？

我是否安裝（以及測試和維護）單元測試，因爲它們脫離了框架而只出現在那裏？

我的框架生成的代碼有多少我從來沒有看過（但仍然可能咬我一天，即使yagni）？

我花了多少時間在我的工具上工作而不是用戶的問題？

當配對編程時，觀察者的角色值通常位於「yagni」中。

你使用CRUD工具嗎？它是否允許（不鼓勵）將它用作_RU_工具或C__D工具，或者當您只需要一兩個代碼時，您是否創建了四段代碼（另加四個單元測試）？

Answer 1

拓展署以某種方式包容了YAGNI。如果您正確執行TDD，即只編寫那些會導致所需功能的測試，然後開發最簡單的代碼以通過測試，那麼您默認遵循YAGNI原則。根據我的經驗，只有當我跳出TDD框並開始在測試之前編寫代碼，測試我並不真正需要的東西，或者測試的代碼不僅僅是通過測試的最簡單的方法，我違反了YAGNI 。

在我的經驗中，後者是我在做TDD時最常見的失禮 - 我傾向於跳躍前進，並開始編寫代碼以通過下一個測試。這通常會導致我通過基於我的代碼創建一個先入爲主的想法而不是需要測試的需求來影響剩餘的測試。

YMMV。

Answer 2

我看過很多關於SO引用過早優化的帖子，這是yagni的一種形式，或者至少是ydniy（你現在還不需要它）。

Answer 3

Yagni和KISS（保持簡單，愚蠢）基本上是相同的原理。不幸的是，我看到KISS經常提到我看到的「yagni」。

在我的荒野之地，項目延誤和失敗的最常見原因是不必要的部件執行不當，所以我同意你的基本觀點。

Answer 4

我沒有把YAGNI看作是快速和骯髒的反面，真的。它正在做所需要的，沒有更多，也沒有計劃像有人寫了50年的軟件。它可能會很少發生，至少在我的腦海裏並沒有太多的問題要問。類似於「不重複自己」和「保持簡單，愚蠢」的規則，這些規則變得很普遍，但不一定以101種方式進行解析和分析。有些東西很簡單，通常在做一些練習後很快就會得到。有些事情在幕後發展，如果你回頭看，你可能會注意到它們可能是另一種陳述事物的方式。

Answer 5

我發現的問題是，人們傾向於在YAGNI下使用DI容器（除非您已經擁有代碼庫中的代碼）編寫工廠。我同意JB King在那裏。對於我與YAGNI合作的許多人來說，似乎是削減角落/編寫草率代碼的許可證。

例如，我正在編寫一個PinPad API來抽象多個模型/製造商的PINPad。我發現，除非我有整體結構，否則我甚至不能寫單元測試。可能是我不是一個經驗豐富的TDD實踐者。我確信對於我所做的是否是YAGNI會有不同的意見。

Answer 6

自由改變驅動器YAGNI。在瀑布項目中，咒語是控制範圍。範圍是通過與客戶建立合同來控制的。因此，客戶可以在範圍文件中填寫他們所能想到的全部內容，因爲一旦合同簽署後，範圍變更將變得困難。因此，您最終得到的應用程序具有一系列功能，而不是一組具有價值的功能。

通過敏捷項目，產品所有者構建了優先級排序產品。開發團隊根據優先級（即，價值）構建功能。結果，最重要的東西首先被建成。您最終得到的是具有用戶重視功能的應用程序。不重要的東西從名單上掉下來或沒有完成。那是YAGNI。

儘管YAGNI不是一種實踐，但它是優先級積壓列表的結果。業務合作伙伴重視提供業務的靈活性，因爲他們可以將產品積壓從迭代轉換爲迭代，並重新設置優先級。這足以解釋YAGNI是我們在接受變革時所獲得的利益，即使在這個過程的最後階段也是如此。