The time spent is taken from adding, testing or improving necessary functionality.
The new features must be debugged, documented, and supported.
Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later.
Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work right, even if it eventually is needed.
It leads to code bloat; the software becomes larger and more complicated.
Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards creeping featurism.
即使在 Windows 应用程序上，应用程序越大、功能越多，开发成本就越高； 等到您知道需要什么、不需要什么时，您就会少得多地浪费金钱来开发那些根本不需要的东西。
此外，任何附加功能都可能带来错误。
在开发东西之前正确考虑需求是好事，但过度设计往往只是借麻烦。
Especially on an embedded device, size is money (larger Flash part, say, which costs more and has a longer programming time at manufacture; or more peripheral components).
Even on a Windows application, the larger your application and the more features it has, the more it costs to develop; wait until you know what's needed and what's not and you'll waste far less money developing stuff that turns out not to be what was needed at all.
Also, any additional functionality brings with it the potential for bugs.
It's good to think properly about the requirements before developing something, but over-designing is often just borrowing trouble.
Them: "We might use it somewhere else at some stage in the future."
Me: "Yes, we might. And we might not. And we can't know, now, in what ways we might want to. And if we do want it at some stage in the future - that's the time when we'll know the ways in which we want it. That's when we can write it with confidence. On the other hand, if we write it today, but never need it, we've wasted resources to develop something we didn't need. And we've added to our code bloat, so it's harder to find the pieces of our code base that are in use, because we've got all this (presently) unnecessary code crowding out the useful stuff."
In our team we just say "YAGNI". It reminds people why. There is MORE than enough stuff on the web about YAGNI if you think you need to collate it to provide a report.
Actually, having someone say "YAGNI" to you on our team cuts a little because it's like saying "C'mon; you know better than that", which always hurts a little. :)
这是一种平衡，通常我只在成本低廉的情况下才会过度设计。 例如，我不会编写一个接受 2 个参数并将它们相加的函数，而是编写一个接受 n 个参数并将它们相加的函数。 但是，我不编写一个采用 n 参数并使用汇编添加它们的函数。
It's a balance, as a rule I over design only where it's cheap to do so. For instance, I wouldn't write a function that takes in 2 parameters and adds them, instead I'd write a function that takes n-parameters and adds them. However, I don't write a function that takes n-parameters and adds them using assembly.
Overdesign (solving a problem in a way that is more generic than needed) a specific piece of architecture is acceptable only if you can afford it.
If you accept extraneous functionality (which is generally speaking different from overdesign) you need - again - to accept the costs that come with it (time ==> money) - if you can't afford those extra costs then you got your answer :)
There's a big difference in providing for future functionality and adding future functionality. A good design should have the "hooks" or whatever to provide for new features or modifications.
There are two ways that you can possibly handle this situation. The first way is that if they are contractors and providing the software to you. You can simply refuse to pay for all of the extra functionality and impose very strict deadlines for your required functionality. If they miss the deadline then you impose financial penalties for every day they are late.
The other way is if they actually work for you. If this is the case then you can get rid of them or downgrade them in their performance reviews.
发布评论
评论（8）
维基百科上有很多充分的理由。
http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It
另请参阅：http://en.wikipedia.org/wiki/KISS_principle
Plenty of good reasons on Wikipedia.
http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It
See also: http://en.wikipedia.org/wiki/KISS_principle
特别是在嵌入式设备上，尺寸就是金钱（例如，较大的闪存部件，其成本更高并且在制造时具有更长的编程时间；或者更多的外围组件）。
即使在 Windows 应用程序上，应用程序越大、功能越多，开发成本就越高； 等到您知道需要什么、不需要什么时，您就会少得多地浪费金钱来开发那些根本不需要的东西。
此外，任何附加功能都可能带来错误。
在开发东西之前正确考虑需求是好事，但过度设计往往只是借麻烦。
Especially on an embedded device, size is money (larger Flash part, say, which costs more and has a longer programming time at manufacture; or more peripheral components).
Even on a Windows application, the larger your application and the more features it has, the more it costs to develop; wait until you know what's needed and what's not and you'll waste far less money developing stuff that turns out not to be what was needed at all.
Also, any additional functionality brings with it the potential for bugs.
It's good to think properly about the requirements before developing something, but over-designing is often just borrowing trouble.
他们：“我们可能会在未来的某个阶段在其他地方使用它。”
我：“是的，我们可能会。也可能不会。而且我们现在不知道我们可能想要以什么方式。如果我们确实想要在未来的某个阶段 - 那时我们会知道我们想要它的方式，那时我们就可以自信地编写它，但如果我们今天编写它，但从来不需要它，我们就浪费了资源来开发我们不需要的东西。增加了我们的代码膨胀，因此很难找到正在使用的代码库片段，因为我们（目前）所有这些不必要的代码挤占了有用的东西。”
Them: "We might use it somewhere else at some stage in the future."
Me: "Yes, we might. And we might not. And we can't know, now, in what ways we might want to. And if we do want it at some stage in the future - that's the time when we'll know the ways in which we want it. That's when we can write it with confidence. On the other hand, if we write it today, but never need it, we've wasted resources to develop something we didn't need. And we've added to our code bloat, so it's harder to find the pieces of our code base that are in use, because we've got all this (presently) unnecessary code crowding out the useful stuff."
在我们的团队中，我们只说“YAGNI”。 它提醒人们为什么。 如果您认为需要整理以提供报告，那么网络上有足够多的有关 YAGNI 的信息。
事实上，让我们团队中有人对你说“YAGNI”会有点伤人，因为这就像在说“来吧，你知道的比这更好”，这总是有点伤人。 :)
In our team we just say "YAGNI". It reminds people why. There is MORE than enough stuff on the web about YAGNI if you think you need to collate it to provide a report.
Actually, having someone say "YAGNI" to you on our team cuts a little because it's like saying "C'mon; you know better than that", which always hurts a little. :)
这是一种平衡，通常我只在成本低廉的情况下才会过度设计。 例如，我不会编写一个接受 2 个参数并将它们相加的函数，而是编写一个接受 n 个参数并将它们相加的函数。 但是，我不编写一个采用 n 参数并使用汇编添加它们的函数。
It's a balance, as a rule I over design only where it's cheap to do so. For instance, I wouldn't write a function that takes in 2 parameters and adds them, instead I'd write a function that takes n-parameters and adds them. However, I don't write a function that takes n-parameters and adds them using assembly.
你说
我想有时人们会认为这条线是模糊的，对你来说“有意义”的东西可能对其他人来说是过度设计的。
You say
and I guess that sometimes people see this line as blurry something that "makes sense" to you may be over-design to someone else.
过度设计（以比需要更通用的方式解决问题）只有在您负担得起的情况下，特定的架构才是可接受的。
如果您接受无关的功能（通常来说，这与过度设计不同），您需要再次接受随之而来的成本（时间==>金钱）-如果您负担不起这些费用额外费用然后你就得到了答案:)
Overdesign (solving a problem in a way that is more generic than needed) a specific piece of architecture is acceptable only if you can afford it.
If you accept extraneous functionality (which is generally speaking different from overdesign) you need - again - to accept the costs that come with it (time ==> money) - if you can't afford those extra costs then you got your answer :)
提供未来功能和添加未来功能之间存在很大差异。 一个好的设计应该有“钩子”或任何提供新功能或修改的东西。
有两种方法可以处理这种情况。 第一种方法是，如果他们是承包商并向您提供软件。 您可以简单地拒绝支付所有额外功能的费用，并对所需功能施加非常严格的期限。 如果他们错过了最后期限，那么你会为他们迟到的每一天处以经济处罚。
另一种方式是他们是否真的为你工作。 如果是这种情况，那么您可以摆脱他们或在他们的绩效评估中降级他们。
There's a big difference in providing for future functionality and adding future functionality. A good design should have the "hooks" or whatever to provide for new features or modifications.
There are two ways that you can possibly handle this situation. The first way is that if they are contractors and providing the software to you. You can simply refuse to pay for all of the extra functionality and impose very strict deadlines for your required functionality. If they miss the deadline then you impose financial penalties for every day they are late.
The other way is if they actually work for you. If this is the case then you can get rid of them or downgrade them in their performance reviews.