吻我的YAGNI

我们都熟悉KISS（保持简单，愚蠢）和YAGNI（您不会需要）原理。 但是，到处都有过于复杂的软件。

让我们使用应用程序服务器。 绝对是 我们离不开分布式交易。 还有一个消息队列–为了脱钩。 哦，我们的业务逻辑可能包含很多业务规则，让我们来看看规则引擎。 还有一个ESB，绝对是ESB –在不使它们相互依赖的情况下，我们还将如何分配多个模块？ 数据库？ 甲骨文，当然。 还有CouchDB和Cassandra，因为关系数据库在某些方面不擅长，我们将需要非常高的性能。 我们还需要几个附加层。 到处都是一些外墙。 和模块–我们不应该只有一个整体的应用程序，否则我们将如何重用我们的组件？ 您知道，让我们尝试一下OSGi，它将适合我们。 我忘记了Web服务吗？ SOA非常重要。 而且ESB仍然需要它。

即使您没有指定的架构师，这也是发生的事情。 每件事都有一些看似合法的理由。

不，YAGNI。 您很可能正在构建将由不超过几百个用户同时使用的商业软件。 它可能将包括一些业务逻辑以及对报告和统计的许多要求。 而且，您不需要上述任何内容即可制作功能强大且易于维护的软件。

当我以前坚持认为框架对您有利并降低软件的复杂性时，我在说您应该忽略技术和框架时是否与myslef相矛盾？ 没有什么矛盾的。 原因如下：如果编写正确，则软件可以轻松更改。

如果发现确实确实需要消息队列，请添加它，然后通过发送消息替换代码中的同步调用。 如果您的postgresql / mysql在数据量方面表现不佳，请切换到Oracle。 如果您开始拥有数百万的用户，请考虑使用Cassandra。 然后，只需重写几个DAO类即可。 如果碰巧需要在同一系统中集成许多第三方软件，请研究ESB。 如果您意识到跨项目的复制粘贴功能，则将常见的片段提取到可重用的组件中。

但不是在需求出现之前。 因为这种体系结构的复杂性使得迭代变得越来越困难和缓慢，尤其是如果并非团队中的每个人都熟悉所有技术。

我是否提倡计划中的懒惰？ 我们以前的经验不足以让我们提前决定需要什么吗？ 是的，但仅提供了足够的数据。 在项目开始时，您几乎永远不会拥有它。

我们知道我们需要两种“事物”。 首先，公用事业。 简化我们将要完成的任务的工具。 例如，ORM可以（但并非总是）简化我们的数据访问。 依赖项注入框架可以简化我们的代码交互的方式。 其次，子系统。 消息队列，NoSQL数据库，ESB在某种程度上是子系统。 它们不是应用程序的固有部分，不是工具。 它们增加了开发，配置，部署的复杂性，我们的工作是评估它们是否真正有益，并且权衡是否值得。

在“全力以赴”框架否认态度与YAGNI原则之间存在细微的界限。 这是常识。 那就是我们的经验发挥作用的地方-确定什么是最适合工作的工具，而不是确定使用哪些工具很酷，或者“在某个时候可能会有所帮助”。

当有人来找我说“我们用X代表Y”时，我说：“不。 现在让我们保持简单。 我们现有的堆栈可以解决这个问题。” 结果是–更简单的软件。 易于维护，易于介绍新人。 而且功能正常。

参考：来自我们的JCG合作伙伴 Bozhidar Bozhanov的 KISS My YAGNI ，位于Bozho的技术博客博客中。

翻译自: https://www.javacodegeeks.com/2013/08/kiss-my-yagni.html