你跟YAGNI走了多远？

Question

我正在为企业市场开发一个新的革命性Web应用程序.当然,很多人在我之前认为他们的网络应用程序将是革命性的,只是发现它不是.(或者它是,但无论如何业务都不好).

所以我在想,为了找出我的想法是否有最低成本的牵引力,遵循一个极端的YAGNI:

没有安全功能(即没有用户等).对于任何新客户,我安装了一个新的数据库实例和一个新的webapp实例.每个webapp实例都受http服务器密码(摘要或基本授权,可能通过https)保护.
没有国际化.只是嵌入在源代码中的英文字符串.
没有脱钩.只是与数据库通信的网页.
没有表演技巧.没有队列,缓存,计时器,后台作业,异步调用等.
没有可扩展性.没有数据库分区,没有分片,没有群集或复制.
另外,只要合适,就可以在微观层面使用YAGNI.

我只是想开始这个项目并尽可能快地达到一个点,我可以通过一个简单而引人入胜的用户界面来销售(或试图销售)我的创新功能.

如果计划失败,我会尽早知道.如果成功,我会看到客户想要的东西.他们想要法语版吗？或者他们是否想要组织内的用户和角色？

这是人们对YAGNI的意思,还是YAGNI的一个病态和夸张的例子？

Answer 1

我完全同意YAGNI原则,但你仍然想要成功的计划.如果一个应用程序突然有超过十个用户需要完全重写,那么它的YAGNI就太过分了.

你需要的一些东西.从我的角度来看,最重要的两点是:

不准备你的应用程序进行国际化,不要让自己陷入困境.如果您的申请有任何好处,那么国际化将在某一天出现在桌面上.此外,在2010年从头开始构建应用程序时,使用UTF-8处理外来字符的能力是绝对必要的.国际化对英语母语人士来说似乎并不重要,但相信我,这是必不可少的,国际化的痛苦以后的申请很可怕.
三思而后行无安全功能.那些想要与不同安全级别的用户一起使用您的应用的组织或团体怎么办？它可能是,这是一个功能,您可以真正做到不-我都内置了很多我的产品从未被用来充分发挥其潜力还没有的细粒度的安全系统.但要好好考虑一下你的具体应用是否可以做到,即使它是成功的.

我希望我能不止一次地投票.安全和国际化是从一开始就必须设计的两件事.它们实际上不可能在以后添加,因为你总会错过一些东西(特别是在安全方面,这可能非常严重). (5认同)

Answer 2

这就是他们所谓的"原型制作".去吧.

YAGNI与原型设计之间存在微妙之处.

你在这里拥有的大多数东西似乎都不是面向用户的镀金.我不会称之为 - 确切地说 - YAGNI.

如果他打算扔掉它,它只是原型.如果他计划保留它并继续使用新功能,那么它的设计就会很差:) (8认同)
原型通常永远存在 (5认同)
我在(2)中不同意.当你对自己说不,大部分时间也是YAGNI.也许你想要添加额外的方法"以防万一"或者在该类的未来用户需要的情况下重载其他方法. (4认同)
@Eric Petroelje:(1)原型设计不会*强制要求你扔掉它.许多增量开发方法都从一个简洁的解决方案开始并添加功能.(2)我怀疑他第一次发布的任何内容实际上是*可以*保留. (2认同)

Answer 3

YAGNI旨在提醒您注意您可以做什么以及您需要做些什么来满足您的要求.

例如,如果您的要求是"让人们创建帐户并登录",只需使用框架的默认身份验证方法,然后继续执行下一个要求.

您的Web应用程序可以支持OpenID,Active Directory,本地数据库,平面文件以及其他各种身份验证方法,但您可以通过实现最简单的方法来满足要求.(对我而言,YAGNI暗示DTSTTCPW).

"如果有足够的时间,我可以做任何事情"

- 我见过的每一位程序员

Answer 4

我自己并不是YAGNI原则的粉丝; 我认为在设计不佳的软件的合理性中经常使用它.过度设计的软件当然也是一个问题,但"YAGNI"并没有为实际影响分析留下太多空间.

事实证明,在软件世界中,许多您认为不需要的东西,实际上是您需要的.然后还有一些.Who'dathunkit.

我写了一两个应用程序,应该是一次性应用程序或两年后仍在生产中的保留.他们很难维持.

尤其是当它涉及到像安全-你可能是会需要它.