天儿真好，
虽然在这里考虑了这个问题，overdesigning for possible future changes让我思考。
你可以向那些坚持吹灭设计的人提供什么理由，因为“他们可能希望在未来的某个阶段将其用于其他地方”？
同样地，当人们接受这些要求然后带着你没有要求的大量额外“花里胡哨”的臃肿设计回来时你会怎么做？
当您知道对现在或不久的将来存在的要求或可能的用途有意义时，我可以理解扩展设计。而且我并不主张只是轻率地接受一份要求清单并明确地实施，而不提供任何关于你认为可能缺失的反馈。
我在谈论当人们坚持添加或拥有无关功能时该做什么，以便“我们可能会在未来的某个阶段将其用于其他地方？”
答案 0 :(得分：5)
维基百科有很多好理由。
http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It
- 花费的时间来自添加，测试或改进必要的时间 功能。
- 必须调试，记录和支持新功能。
- 任何新功能都会对将来可以采取的措施施加限制 现在可能会阻止不必要的功能 实施必要的功能 后面。
- 在实际需要该功能之前，很难完全实现 定义它应该做什么和测试 它。如果新功能不正确 定义和测试，它可能无法正常工作 是的，即使它最终是 需要的。
- 导致代码臃肿;软件变得越来越大 复杂。
- 除非有规范和某种版本控制，否则 功能可能不为人所知 可以使用它的程序员。
- 添加新功能可能会提示其他新功能。如果这些新的 这个功能也实现了 可能会导致滚雪球效应 朝着匍匐的特征。
答案 1 :(得分：3)
特别是在嵌入式设备上，尺寸就是金钱（更大的Flash部分，比如说，制造成本更高，编程时间更长;或更多的外围元件）。
即使在Windows应用程序中，应用程序越大，功能越多，开发成本就越高;等到你知道需要什么，什么不需要，你会浪费更少的钱来开发那些根本不需要的东西。
此外，任何其他功能都会带来bug的可能性。
在开发之前适当考虑需求是很好的，但过度设计通常只是在借用麻烦。
答案 2 :(得分：3)
我：“是的，我们可能。我们可能不会。现在，我们无法知道我们可能想要的方式。如果我们确实希望它在未来的某个阶段 - 那时候就是我们会知道我们想要它的方式。那时我们可以自信地写它。另一方面，如果我们今天写它，但从不需要它，我们浪费了资源来开发我们不需要的东西我们已经添加了我们的代码膨胀，所以我们很难找到 正在使用的代码库，因为我们已经把所有这些（目前）不必要的代码排除在外东西“。
答案 3 :(得分：3)
在我们的团队中，我们只说“YAGNI”。它提醒人们为什么。如果您认为需要整理它以提供报告，网上有关于YAGNI的内容已经足够了。
实际上，有人在我们的团队中对你说“YAGNI”会削减一点，因为它就像是在说“来吧;你知道的比这更好”，这总是有点伤害。 ：）
答案 4 :(得分：1)
这是一个平衡，作为一项规则，我只是在设计它便宜的地方。例如，我不会编写一个接受2个参数并添加它们的函数，而是编写一个接受n参数并添加它们的函数。但是，我不编写一个带有n参数的函数，并使用汇编添加它们。
答案 5 :(得分：1)
你说
当您知道现在或不久的将来存在的需求或可能的用途时，我可以理解扩展设计。
我猜有时候人们会认为这条线条模糊不清，对你来说“有意义”可能会过度设计给别人。
答案 6 :(得分：1)
过度设计（以比所需更通用的方式解决问题）只有在您负担得起的情况下才能接受特定的架构。
如果您接受无关功能（通常与过度设计不同），您需要 - 再次 - 接受随附的费用（时间==＆gt;钱） - 如果可以的话得到那些额外的费用然后你得到了你的答案：）
答案 7 :(得分：1)
在提供未来功能和添加未来功能方面存在很大差异。一个好的设计应该有“钩子”或任何提供新功能或修改的东西。
有两种方法可以处理这种情况。第一种方式是，如果他们是承包商并为您提供软件。您可以简单地拒绝支付所有额外功能，并为您所需的功能施加非常严格的截止日期。如果他们错过了截止日期，那么你就会对他们迟到的每一天施加经济处罚。
另一种方式是，如果他们真的为你工作。如果是这种情况，那么您可以在绩效评估中摆脱它们或降级它们。