KISS My YAGNI

 

有两种东西我们知道可能会是需要的,。第一，实用工具。那些能简化我们的工作的工具。例如，ORM，它通常(但并不是总数)能简化我们的数据库访问。一个依赖反射注入框架，它能简化代码之间的交互。其次是子系统。某种形式上的消息队列服务系统，NoSQL数据库，ESB，这些都是子系统。它们并不属于我们的系统的原生部分，它们不是工具。它们会增加开发、配置、部署的复杂度。我们自己需要去评估使用它们给系统造成的影响，是否值得一用。

在“凡事自己动手”的错误做法和YAGNI开发原则之间其实有清楚的界限。这都是常识。这是我们的经验发挥作用的地方——判断什么是最好的工作辅助工具，什么只是很酷的“也许会有帮助”的工具。

假设我们需要一个应用服务。没错，缺少分布式事务管理系统是不行的。而且需要一个消息队列——用来实现系统低耦合。哦，我们的业务逻辑看起来有很多的业务规则，那就用规则引擎来管理吧。还需要一个ESB，没错，ESB——没有它如何能让我们分布式的多个模块相互独立不依赖？数据库？当然是Oracle。但 CouchDB 和 Cassandra 也是需要的，因为关系型数据库有时不善于做某些事，我们需要更高的性能。我们还需要一些额外的应用层。还需要一些facades。还有模块化——我们可不希望我们的应用是铁板一块，否则如何能复用我们的组件？你说对了，我们要使用OSGi，这个东西很适合我们。我忘了说Web Services吗？SOA很重要。并且ESB是少不了它的。

但不是在这种需求出现之前就做这些事情。因为系统会因为它们而变得复杂度陡增，很难迭代，尤其是当团队里并不是每个人都熟悉这些技术的情况下。

不。YAGNI(你不需要它们)。你开发的业务系统极有可能只有几百人同时在线，有可能只有一些业务逻辑，其余的都是大量的不报表和统计。为了实现一个可用的、而且简单好维护的软件应用，你不需要上面提到的那些技术架构。

　　

当有人对我说“让我们使用X来实现Y吧，”我会说：“不，我们要保持简单。我们现有的技术架构能处理它”。这样做的结果就是：更简单的软件。易于维护，易于让新手接手。而且不失功能性。

我是不是有些自相矛盾？因为之前我还坚持说frameworks are there for your good，能够降低软件的复杂度，但现在却宣称应该远离那些技术和框架。其实并不冲突。

如果后来证明你真的需要一个消息队列模块——那就增加，把同步调用代码替换成发送消息队列的代码。如果后来你的postgresql/mysql数据库不能很好的处理这样大的数据，那就换成Oracle。如果你的用户开始增加到百万级，那就考虑Cassandra。你只需要重写那些DAO类就行了。如果后来发现需要在系统里集成很多第三方的软件，那就研究一下ESB。如果你发现在很多项目间需要将一些代码拷来拷去，那就归纳提炼，做成可复用的组件。

这是在倡导在计划中走一步看一步吗？难到我们积累的经验不能让我们事先判断将会需要什么吗？是的，我们可以有预见，但那是在有足够的数据支持下。在项目的前期，我们几乎什么数据都没有。

即使没有架构师来设计，这些技术也会很自然的出现在架构设计中。每一样都看起来合情合理，无可厚非。

 

[英文原文：KISS My YAGNI ]

转自 /kiss-my-yagni/

我们都知道KISS (Keep It Simple, Stupid)和 YAGNI (You Ain’t Gonna Need It)软件开发原则，然而，过度复杂的软件仍然随处可见。