关闭。这个问题是opinion-based .它目前不接受答案。
想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.
3年前关闭。
Improve this question
随着我越来越多地将敏捷思维融入到我的工作方式中，yagni(“你不需要它”)似乎变得越来越重要。在我看来，这是过滤掉被误导的优先事项并决定下一步不工作的最有效规则之一。
然而，yagni 似乎是一个在 SO 上几乎没有人谈论过的概念。我运行了强制性搜索，它只出现在一个问题标题中 - 然后是次要角色。
为什么是这样？我是否高估了它的重要性？
免责声明。为了抢先我确定我会反对的回应，让我强调 yagni 是 与快速和肮脏相反 .它鼓励您将宝贵的时间和精力集中在获得正确的零件上。
以下是人们可能会问的一些现成的持续问题。
我的单元测试是根据用户需求还是框架结构选择的？
我是否正在安装(并测试和维护)单元测试，因为它们不属于框架？
我的框架生成的代码中有多少是我从未看过的(但总有一天会咬我，即使是 yagni)？
我花了多少时间在我的工具而不是用户的问题上？
结对编程时，观察者的角色值(value)往往在于“yagni”。
你使用 CRUD 工具吗？它是否允许(不，鼓励)您将其用作 _RU_ 工具或 C__D 工具，或者您是否在只需要一两个代码时创建了四段代码(加上四个单元测试)？
最佳答案
TDD 以某种方式包含了 YAGNI。如果你把TDD做的正确，也就是只写那些产生需要的功能的测试，然后开发最简单的代码通过测试，那么你就默认遵循了YAGNI原则。根据我的经验，只有当我跳出 TDD 框并开始在测试之前编写代码、测试我并不真正需要的东西或代码不是通过测试的最简单方法时，我才违反了 YAGNI .
根据我的经验，后者是我在进行 TDD 时最常见的失礼——我倾向于提前开始编写代码以通过下一个测试。这通常会导致我通过基于我的代码而不是需要测试的要求的先入为主的想法来妥协剩余的测试。
天啊。
关于unit-testing - YAGNI - 不得命名的敏捷实践？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/369897/