天，
在这里思考这个关于为可能的未来变化进行过度设计的问题时，我开始思考。
你能向那些坚持吹嘘设计的人提供什么反对理由，因为“他们可能想在未来某个阶段在其他地方使用它”？
同样，当人们接受了要求，然后返回一个臃肿的设计，其中包含许多你没有要求的额外“花里胡哨”的东西时，你会怎么做？
当您知道扩展设计对现在或不久的将来存在的需求或可能的用途有意义时，我可以理解。而且我并不是在提倡只是愉快地接受要求列表并明确实施，而不提供任何关于您认为可能缺少的内容的反馈。
我说的是当人们坚持添加或拥有无关功能时该怎么办，以便“我们可能在未来某个阶段在其他地方使用它？”
维基百科上有很多很好的理由。
http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It
- 花费的时间来自添加、测试或改进必要的功能。
- 必须调试、记录和支持新功能。
- 任何新功能都会对将来可以做什么施加限制，因此现在不必要的功能可能会阻止以后实现必要的功能。
- 在实际需要该功能之前，很难完全定义它应该做什么并对其进行测试。如果新功能没有正确定义和测试，即使最终需要它，它也可能无法正常工作。
- 它导致代码膨胀；软件变得更大更复杂。
- 除非有规范和某种版本控制，否则可以使用它的程序员可能不知道该功能。
- 添加新功能可能会建议其他新功能。如果这些新功能也被实施，这可能会导致滚雪球效应向爬行特征主义发展。
尤其是在嵌入式设备上，尺寸就是金钱（例如，更大的 Flash 部件成本更高，并且在制造时需要更长的编程时间；或者更多的外围组件）。
即使在 Windows 应用程序上，应用程序越大，功能越多，开发成本也越高；等到你知道什么是需要什么不是，你会浪费更少的钱来开发那些根本不需要的东西。
此外，任何附加功能都会带来潜在的错误。
在开发之前适当考虑需求是很好的，但过度设计通常只是借用麻烦。
他们：“我们可能会在未来某个阶段在其他地方使用它。”
我：“是的，我们可能会。我们可能不会。而且我们现在不知道我们可能想要以何种方式。如果我们在未来的某个阶段确实想要它——那就是我们将知道我们想要它的方式。那是我们可以自信地写它的时候。另一方面，如果我们今天写它，但从不需要它，我们就浪费了资源来开发我们不需要的东西。而且我们'已经增加了我们的代码膨胀，所以很难找到我们正在使用的代码库片段，因为我们已经得到了所有这些（目前）不必要的代码，挤掉了有用的东西。”
在我们的团队中，我们只说“YAGNI”。它提醒人们为什么。如果您认为需要整理它以提供报告，那么网络上关于 YAGNI 的资料就绰绰有余了。
实际上，在我们的团队中让某人对你说“YAGNI”会减少一点，因为这就像在说“来吧；你知道的比那更好”，这总是有点伤人。:)
这是一种平衡，通常我只会在成本低廉的情况下过度设计。例如，我不会编写一个接收 2 个参数并添加它们的函数，而是编写一个接收 n 个参数并添加它们的函数。但是，我没有编写一个采用 n 参数并使用汇编添加它们的函数。
你说
当您知道扩展设计对现在或不久的将来存在的需求或可能的用途有意义时，我可以理解。
我猜有时人们认为这条线很模糊，对你来说“有意义”的东西可能对其他人来说是过度设计的。
过度设计（以比需要更通用的方式解决问题）只有在您负担得起的情况下才能接受特定的架构。
如果您接受无关的功能（通常与过度设计不同），您需要 - 再次 - 接受随之而来的成本（时间 ==> 金钱） - 如果您负担不起这些额外成本，那么您得到了答案： )
在提供未来功能和添加未来功能方面存在很大差异。一个好的设计应该有“钩子”或任何提供新功能或修改的东西。
有两种方法可以处理这种情况。第一种方法是，如果他们是承包商并向您提供软件。您可以简单地拒绝为所有额外功能付费，并为您所需的功能设置非常严格的截止日期。如果他们错过了最后期限，那么您将对他们迟到的每一天施加经济处罚。
另一种方式是如果他们真的为你工作。如果是这种情况，那么您可以在他们的绩效评估中摆脱它们或降级它们。