I wholeheartedly agree with the YAGNI principle, but you still want to plan for success. If an application needs a complete rewrite when it suddenly has more than ten users, then it's YAGNI taken too far.
Some things You Are Gonna Need. From my perspective, the two most important points:
Don't shoot yourself in the foot by not preparing your app for internationalization. If your application is any good, internationalization is going to be on the table one day. Also, the ability to handle foreign characters by using UTF-8 is an absolute requirement when building an application from scratch in 2010. Internationalization may seem not that important to an english native speaker, but believe me, it is essential and the pain of internationalizing an application later is horrible.
Think twice about the no security features thing. What about an organization or group that wants to work with your app with users on different security levels. It could be that this is a feature you can really do without - I have a fine-grained security system built into many of my products that has never been used to its full potential yet. But think well about whether your specific application can do without, even if it is successful.
When it's user-requested featuritis, and you say no, that's YAGNI.
When it's implementation (I18N, "decoupling"(?), queues, caches, timers, etc.) and you say no to yourself. That's not really YAGNI. That's prototyping.
Most of what you have here does not seem to be user-oriented gold-plating. I wouldn't call this -- precisely -- YAGNI.
YAGNI is about reminding you to see the difference between what you can do and what you need to do to satisfy your requirements.
For example,if your requirement says "let people create accounts and log in", just use your framework's default auth methods and move on to the next requirement.
Your web app can support OpenID, Active Directory, Local Database, Flat File, and a zillion other kinds of authentication methods, but you can satisfy the requirement by implementing the simplest one. (To me, YAGNI implies DTSTTCPW).
Not a fan of the YAGNI principle myself; I see it used far too often in the justification of poorly-designed software. Over-designed software is a problem too of course, but "YAGNI" doesn't really leave much room for actual impact analysis.
It turns out that in the world of software, many of the things that you think you aren't going to need, you actually are going to need. And then some. Who'dathunkit.
I've written one or two apps that were supposed to be throwaway apps or hold-overs that are still in production after two years. They are a pain to maintain.
Especially when it comes to something like security - you probably are going to need it.
YAGNI is a good principle but it is not the only design principle. Many of the above make sense to get a product in front of users quickly. But if, for example, the web pages that talk directly to the database begin to each have duplicated code you are going to find that slavish dependence on one principle (YAGNI) to the exclusion of others (in this case DRY) will limit your ability to respond to your hopefully growing number of users' feature requests.
If you are going to truly develop a revolutionary web application for the enterprise market I'm not really sure which of those things You Aint Gonna Need.
Also your examples are pretty specific. For instance when you say: "no security features"... I'd say that users is one thing you maybe can do without, but sanitizing your inputs is one you can't. Also "scalability" is not a matter of database sharding or replication, those are decisions you take after you realize your application does not scale well.
I'd rather be careful when using YAGNI as a high-level design guideline, It fit's best when you talk about odd product features or maybe software components extreme flexibility.
If you take "YAGNI" to that extreme (and I'll sidestep discussions on whether or not that's a good idea as well as discussions on whether or not that's really "YAGNI"), you should be prepared to mercilessly refactor your codebase to add in later what you leave out now without creating a Ball of Mud.
In my mind YAGNI is most commonly used in context with a developer thinking "oh it would be smart if we also added feature X. We might need it in the future." Never ever add features that isn't a requirement.
That being said your code should always be open for modifications if your customer thinks feature Y is absolutely necessary. A good architecture is a must!
Regarding to scalability, queues, caching: it depends. What is the requirement for the application? Is it an intranet site used by 10 concurrent users or is it a popular website with millions of users. It depends. Find the requirements and do that - nothing more. YAGNI. If your requirement change; change your application - it should be open for modifications.
YAGNI is good if there's a decent chance you'll never need it. If you don't need it now but you're almost sure you'll need it in the foreseeable future, then it's almost always easier to fit it in up front than later. When you justify not implementing things that you don't need this second but will almost certainly need in the near future by YAGNI, that's where problems begin.
The point that YAGNI is only one great principal among many is a good one to remember; sometimes YAGNI suggests one decision but there are equally good (or better) reasons to prefer another.
Here's one area where I feel some YAGNI proponents may go to far: if you're comfortable with OOD/polymorphism, it usually costs you very little to "bake in" some great extension points for future use, even in a prototype.
Here's an example...
You're creating a prototype webapp that includes the ability to display a print-friendly version of a report. You need to work quickly, but have a pretty good feeling the steakholders will ask for the ability to email the report as well down the line.
In your server-side Java code, hide the knowledge of the fact that the report is being prepared for the printer behind an interface. Create a concrete class that extends the interface to hold that responsibility. Don't actually go off and write an email version of the interface, because YAGNI. But if you ever do, you're set to add it without carnage to your existing features.
I would say that if you are starting out by throwing away all common sense and doing the whole project in the most expediant way possible, then what you will end up with is a big pile of fail... Which is by no means Revolutionary(tm).
If you truly want to know whether it is going to be useful, do some screen mock ups. Maybe even just regular old hard coded html. Take those to potential clients and see if you can get your foot in the door. If some of them start to bite, then bust your butt and build it.
It's going to take time to get a contract in place, get payment, and get someone on your clients staff to actually start using it. While that's going on, build it.
Most likely what is going to happen is that potential clients will see your app and, hopefully, tell you why it doesn't work for them. Change the mock ups and go back. Iterate as necessary until you have a front end design for your product that someone is willing to pay for.
1) Design it taking in consideration the right architectural decisions. Internationalization and Security are probably must haves in this case.
2) When developing, create the hooks for those principles to be implemented later. So when you have time and budget, you can implemente them without doing major remodeling.
3) Then you can concentrate on the features that would make your application fly and are more important to your potential clients.
So I think that in this case I would be using more of the KISS approach than "extreme YAGNI" as you suggested.
There are some exceptions, thought. For example, if you develop a 3rd party library, you do need to think at least a little bit ahead of time and anticipate some future users' needs. That is not to say that you have to give up on YAGNI completely, but you shouldn't follow it as strictly as with an in-house development.
I tend to agree with many of your considerations except the "no decoupling", because the "it" in YAGNI stands for functionality, not for thinking steps. Introducing a few abstractions (just those needed for decoupling) will pay off immediately in terms of errors not made or errors more quickly found and removed.
A nice (because it saves you thinking) way to introduce those abstractions would be to use a good web framework and simply follow its suggested application structuring style.
As a fringe benefit, it would then become much easier to add the security, internationalization, performance, and scaling stuff later and your YAGNI-behavior-now should become reasonably safe.
(Unfortunately, the argument applies only if you know the web framework already. Knowledge reigns supreme in YAGNI kingdom.)
发布评论
评论（14）
我完全同意 YAGNI 原则，但你仍然想为成功做好计划。如果一个应用程序在突然拥有十多个用户时需要完全重写，那么 YAGNI 就太过分了。
有些东西你会需要。从我的角度来看，最重要的两点是：
不要因为没有为应用程序国际化做好准备而搬起石头砸自己的脚。如果你的申请足够好，国际化总有一天会被提上台面。此外，在 2010 年从头开始构建应用程序时，使用 UTF-8 处理外来字符的能力是绝对要求。国际化对于英语母语人士来说似乎并不那么重要，但相信我，这是必不可少的，而且国际化的痛苦稍后的应用程序是可怕的。
对于没有安全功能的事情要三思而后行。如果组织或团体希望与不同安全级别的用户一起使用您的应用程序，该怎么办？ 可能这是一个你真的可以不需要的功能 - 我的许多产品中内置了一个细粒度的安全系统，但尚未充分发挥其潜力。但请仔细考虑您的特定应用程序是否可以不使用，即使它是成功的。
I wholeheartedly agree with the YAGNI principle, but you still want to plan for success. If an application needs a complete rewrite when it suddenly has more than ten users, then it's YAGNI taken too far.
Some things You Are Gonna Need. From my perspective, the two most important points:
Don't shoot yourself in the foot by not preparing your app for internationalization. If your application is any good, internationalization is going to be on the table one day. Also, the ability to handle foreign characters by using UTF-8 is an absolute requirement when building an application from scratch in 2010. Internationalization may seem not that important to an english native speaker, but believe me, it is essential and the pain of internationalizing an application later is horrible.
Think twice about the no security features thing. What about an organization or group that wants to work with your app with users on different security levels. It could be that this is a feature you can really do without - I have a fine-grained security system built into many of my products that has never been used to its full potential yet. But think well about whether your specific application can do without, even if it is successful.
这就是他们所说的“原型设计”。大胆试试吧。
YAGNI 和原型设计之间存在微妙之处。
当它是用户请求的功能，而你说不时，那就是 YAGNI。
当它实现时（国际化、“解耦”（？）、队列、缓存、定时器等），你对自己说不。那不是真正的雅尼。这就是原型设计。
你这里的大部分内容似乎都不是以用户为导向的镀金。我不会准确地称之为“YAGNI”。
This is what they call "prototyping". Go for it.
There's a subtlety between YAGNI and prototyping.
When it's user-requested featuritis, and you say no, that's YAGNI.
When it's implementation (I18N, "decoupling"(?), queues, caches, timers, etc.) and you say no to yourself. That's not really YAGNI. That's prototyping.
Most of what you have here does not seem to be user-oriented gold-plating. I wouldn't call this -- precisely -- YAGNI.
YAGNI 旨在提醒您了解您可以做什么和需要做什么来满足您的需求之间的区别。
例如，如果您的要求是“让人们创建帐户并登录”，则只需使用框架的默认身份验证方法并继续执行下一个要求。
您的网络应用可以支持OpenID、Active Directory、本地数据库、平面文件和无数其他类型的身份验证方法，但您可以通过实现最简单的一种来满足要求。 （对我来说，YAGNI 意味着DTSTTCPW）。
YAGNI is about reminding you to see the difference between what you can do and what you need to do to satisfy your requirements.
For example,if your requirement says "let people create accounts and log in", just use your framework's default auth methods and move on to the next requirement.
Your web app can support OpenID, Active Directory, Local Database, Flat File, and a zillion other kinds of authentication methods, but you can satisfy the requirement by implementing the simplest one. (To me, YAGNI implies DTSTTCPW).
我本人并不喜欢 YAGNI 原则；我发现它经常被用来为设计不良的软件辩护。当然，过度设计的软件也是一个问题，但“YAGNI”并没有为实际影响分析留下太多空间。
事实证明，在软件世界中，许多您认为不需要的东西实际上是需要的。然后是一些。谁是thunkkit。
我编写了一两个应用程序，这些应用程序应该是一次性应用程序或保留的应用程序，但两年后仍在生产中。维护它们很痛苦。
尤其是当涉及到安全性等问题时 - 您可能会需要它。
Not a fan of the YAGNI principle myself; I see it used far too often in the justification of poorly-designed software. Over-designed software is a problem too of course, but "YAGNI" doesn't really leave much room for actual impact analysis.
It turns out that in the world of software, many of the things that you think you aren't going to need, you actually are going to need. And then some. Who'dathunkit.
I've written one or two apps that were supposed to be throwaway apps or hold-overs that are still in production after two years. They are a pain to maintain.
Especially when it comes to something like security - you probably are going to need it.
YAGNI 是一个很好的原则，但它不是唯一的设计原则。为了将产品快速呈现在用户面前，上述许多措施都是有意义的。但是，例如，如果直接与数据库对话的网页开始都有重复的代码，您将发现对一种原则（YAGNI）的盲目依赖而排除其他原则（在本例中为 DRY）将限制您的能力响应您希望不断增长的用户的功能请求。
YAGNI is a good principle but it is not the only design principle. Many of the above make sense to get a product in front of users quickly. But if, for example, the web pages that talk directly to the database begin to each have duplicated code you are going to find that slavish dependence on one principle (YAGNI) to the exclusion of others (in this case DRY) will limit your ability to respond to your hopefully growing number of users' feature requests.
如果您要真正为企业市场开发一个革命性的 Web 应用程序，我不太确定您需要A中的哪一个G娜需要。
而且你的例子也很具体。例如，当您说：“没有安全功能”时......我想说用户是您可以做的一件事，但清理您的输入是您不能做的一件事。此外，“可扩展性”不是数据库分片或复制的问题，这些是您在意识到应用程序扩展性不佳后做出的决定。
在使用 YAGNI 作为高级设计指南时，我宁愿小心，当您谈论奇怪的产品功能或软件组件的极端灵活性时，它是最好的。
只是我的0.2
If you are going to truly develop a revolutionary web application for the enterprise market I'm not really sure which of those things You Aint Gonna Need.
Also your examples are pretty specific. For instance when you say: "no security features"... I'd say that users is one thing you maybe can do without, but sanitizing your inputs is one you can't. Also "scalability" is not a matter of database sharding or replication, those are decisions you take after you realize your application does not scale well.
I'd rather be careful when using YAGNI as a high-level design guideline, It fit's best when you talk about odd product features or maybe software components extreme flexibility.
Just my 0.2
如果你把“YAGNI”推向极端（我会回避关于这是否是一个好主意的讨论，以及关于这是否真的是“YAGNI”的讨论），你应该准备好无情地重构你的代码库以添加稍后将您现在遗漏的内容放入其中，而无需创建泥球。
If you take "YAGNI" to that extreme (and I'll sidestep discussions on whether or not that's a good idea as well as discussions on whether or not that's really "YAGNI"), you should be prepared to mercilessly refactor your codebase to add in later what you leave out now without creating a Ball of Mud.
在我看来，YAGNI 最常用于开发人员认为“哦，如果我们还添加功能 X，那就太聪明了。我们将来可能需要它”的情况。永远不要添加不是必需的功能。
话虽这么说，如果您的客户认为功能 Y 是绝对必要的，那么您的代码应该始终开放进行修改。一个好的架构是必须的！
关于可扩展性、队列、缓存：这取决于情况。申请有什么要求？它是一个由 10 个并发用户使用的 Intranet 站点，还是一个拥有数百万用户的流行网站。这取决于。找到需求并执行——仅此而已。亚格尼。如果您的要求发生变化；更改您的应用程序 - 它应该开放进行修改。
In my mind YAGNI is most commonly used in context with a developer thinking "oh it would be smart if we also added feature X. We might need it in the future." Never ever add features that isn't a requirement.
That being said your code should always be open for modifications if your customer thinks feature Y is absolutely necessary. A good architecture is a must!
Regarding to scalability, queues, caching: it depends. What is the requirement for the application? Is it an intranet site used by 10 concurrent users or is it a popular website with millions of users. It depends. Find the requirements and do that - nothing more. YAGNI. If your requirement change; change your application - it should be open for modifications.
如果您很有可能永远不需要它，那么 YAGNI 就很好。如果您现在不需要它，但您几乎确定在可预见的将来会需要它，那么提前安装它几乎总是比以后安装更容易。当你证明不实施这一秒你不需要但几乎肯定在不久的将来 YAGNI 需要的东西时，问题就开始了。
YAGNI is good if there's a decent chance you'll never need it. If you don't need it now but you're almost sure you'll need it in the foreseeable future, then it's almost always easier to fit it in up front than later. When you justify not implementing things that you don't need this second but will almost certainly need in the near future by YAGNI, that's where problems begin.
值得记住的是，亚格尼只是众多校长中的一位。有时，亚格尼会建议一个决定，但也有同样充分（或更好）的理由选择另一个决定。
我觉得一些 YAGNI 支持者可能会走得太远：如果您对 OOD/多态性感到满意，那么通常您只需花费很少的成本即可“烘焙”一些出色的扩展点以供将来使用，即使是在原型中也是如此。
这是一个示例...
您正在创建一个原型 Web 应用程序，其中包含显示报告的打印友好版本的功能。您需要快速工作，但有一种很好的感觉，牛排馆老板会要求能够通过电子邮件发送报告。
在服务器端 Java 代码中，隐藏正在为接口后面的打印机准备报告这一事实。创建一个扩展接口的具体类来承担该责任。实际上不要去编写界面的电子邮件版本，因为 YAGNI。但如果你这样做了，你就可以将其添加到现有的功能中，而不会造成任何破坏。
The point that YAGNI is only one great principal among many is a good one to remember; sometimes YAGNI suggests one decision but there are equally good (or better) reasons to prefer another.
Here's one area where I feel some YAGNI proponents may go to far: if you're comfortable with OOD/polymorphism, it usually costs you very little to "bake in" some great extension points for future use, even in a prototype.
Here's an example...
You're creating a prototype webapp that includes the ability to display a print-friendly version of a report. You need to work quickly, but have a pretty good feeling the steakholders will ask for the ability to email the report as well down the line.
In your server-side Java code, hide the knowledge of the fact that the report is being prepared for the printer behind an interface. Create a concrete class that extends the interface to hold that responsibility. Don't actually go off and write an email version of the interface, because YAGNI. But if you ever do, you're set to add it without carnage to your existing features.
我想说，如果你一开始就抛弃所有常识并以尽可能最便捷的方式完成整个项目，那么你最终会遇到一大堆失败......这绝不是革命性的（ TM）。
如果您确实想知道它是否有用，请做一些屏幕模型。甚至可能只是普通的旧硬编码 html。将这些信息带给潜在客户，看看您是否可以迈入这一步。如果其中一些开始咬人，那就拼命建造它。
签订合同、获得付款并让客户员工真正开始使用它需要时间。在此过程中，构建它。
最有可能发生的情况是，潜在客户会看到您的应用程序，并希望告诉您为什么它不适合他们。更改模型并返回。根据需要进行迭代，直到您的产品有了有人愿意付费的前端设计。
I would say that if you are starting out by throwing away all common sense and doing the whole project in the most expediant way possible, then what you will end up with is a big pile of fail... Which is by no means Revolutionary(tm).
If you truly want to know whether it is going to be useful, do some screen mock ups. Maybe even just regular old hard coded html. Take those to potential clients and see if you can get your foot in the door. If some of them start to bite, then bust your butt and build it.
It's going to take time to get a contract in place, get payment, and get someone on your clients staff to actually start using it. While that's going on, build it.
Most likely what is going to happen is that potential clients will see your app and, hopefully, tell you why it doesn't work for them. Change the mock ups and go back. Iterate as necessary until you have a front end design for your product that someone is willing to pay for.
我要做的是：
1）在设计时考虑正确的架构决策。在这种情况下，国际化和安全性可能是必须具备的。
2）开发时，为稍后要实现的这些原则创建钩子。因此，当您有时间和预算时，您可以实施它们，而无需进行重大改造。
3) 然后您可以专注于那些能让您的应用程序顺利运行并且对您的潜在客户更重要的功能。
所以我认为在这种情况下，我会更多地使用 KISS 方法，而不是您建议的“极端 YAGNI”。
What I would do is:
1) Design it taking in consideration the right architectural decisions. Internationalization and Security are probably must haves in this case.
2) When developing, create the hooks for those principles to be implemented later. So when you have time and budget, you can implemente them without doing major remodeling.
3) Then you can concentrate on the features that would make your application fly and are more important to your potential clients.
So I think that in this case I would be using more of the KISS approach than "extreme YAGNI" as you suggested.
在我看来，应该默认遵循 YAGNI，因为它可以极大地提高生产力。
我想，也有一些例外。例如，如果您开发一个第三方库，您确实需要至少提前一点思考并预测一些未来用户的需求。这并不是说您必须完全放弃 YAGNI，但您不应该像内部开发那样严格遵循它。
In my opinion, YAGNI should be followed by default as it allows for boosting productivity greatly.
There are some exceptions, thought. For example, if you develop a 3rd party library, you do need to think at least a little bit ahead of time and anticipate some future users' needs. That is not to say that you have to give up on YAGNI completely, but you shouldn't follow it as strictly as with an in-house development.
是的，但是......
我倾向于同意你的许多考虑除了“不脱钩”，
因为 YAGNI 中的“it”代表功能，而不是思考步骤。
引入一些抽象（只是解耦所需的抽象）将
立即获得回报，避免犯错误或更快发现错误
并删除。
引入这些抽象的好方法（因为它可以节省你的思考）
将使用一个好的网络框架并简单地遵循其建议的应用程序
结构风格。
作为一项附加福利，添加安全性将变得更加容易，
稍后进行国际化、性能和扩展
现在你的 YAGNI 行为应该变得相当安全。
（不幸的是，只有当你知道
已经有网络框架了。
在 YAGNI 王国，知识至高无上。）
Yes, BUT...
I tend to agree with many of your considerations except the "no decoupling",
because the "it" in YAGNI stands for functionality, not for thinking steps.
Introducing a few abstractions (just those needed for decoupling) will
pay off immediately in terms of errors not made or errors more quickly found
and removed.
A nice (because it saves you thinking) way to introduce those abstractions
would be to use a good web framework and simply follow its suggested application
structuring style.
As a fringe benefit, it would then become much easier to add the security,
internationalization, performance, and scaling stuff later
and your YAGNI-behavior-now should become reasonably safe.
(Unfortunately, the argument applies only if you know the
web framework already.
Knowledge reigns supreme in YAGNI kingdom.)