KISS My YAGNI

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

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

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

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

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

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

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

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

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

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

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

[英文原文:KISS My YAGNI ]

引自:外刊IT评论网 http://www.aqee.net/kiss-my-yagni/