在QCON大会上，Michael Nygard，以及 李伟专家都提到了一个概念，容错能力。

衡量软件架构最佳的一个很重要的因素就是看软件的容错能力。没有容错能力的软件，哪怕你QA都非常优秀，但一发生故障就出现集联失效，如同雪崩般，整个系统瘫痪，那么这样的一个系统也是个失败的架构。

那么如何做到能将错误降低到比较能接受的程度呢。其中有提到将各个服务components解耦合，这是个相当笼统的原则。那么作为一个开发者，在开发软件的过程中，怎么能做到更好的规避这方面的风险呢，设计模式就是用来解决这方面的问题，但系统的错误总是不可避免的，于是在与会者与Michael Nygard提问的过程中，引出另一个概念，那就是反模式。

上网查了下，反模式的概念在国外十年前就提出来了。在1998年出版的《反模式——危机中软件、架构和项目的重构》（AntiPatterns——Refactoring Software, Architectures, and Projects in Crisis）。一书中的作者这样定义反模式：

反模式是描述对产生绝对负面结果的问题的一种常用解决方案的字面形式。

由于我们在软件开发过程中，利用反模式可以帮我们总结一些经常犯的规律性错误，研究这些错误，能让我们规避风险。

《Bitter Java》里面提到对我们很有用的东西，关于反模式的步骤：

识别问题。在java编程中，问题可能是错误、性能问题、难于维护的类、不断增大的内存占用量。

建立模式。随着不断深入开发周期，修正一个错误的开销将成指数级上升。当你建立问题的模式时，你就给了自己在开发周期的更早阶段识别和修正更多问题的机会，你的获得也将数以倍计。使这个价值链向上移动的关键就在于建立模式，然后尽可能广泛地根据反模式操作。

重构代码。在这一步中，你将重构导致问题的代码。这一步是一个简单的错误修正，它适用于你迄今为止识别出所有问题实例。你应该花时间去做一个完整的修正，而不是仅仅打一个补丁了事。

宣传解决方案。你在这里确保碰到的问题的其他人懂得如何修正问题，并确保可能碰到陷阱的其他人知道要避开它。

修正过程。修正可以采用很多不同的方式。改进测试案例可以快速地识别衰退，修正每日过程或通信渠道可以在问题发生之前预防它们。补充编码标准几乎能够消除某些类型的编码错误，如关于放置花括号或注释的错误。

书中还这样总结：这些步骤采用的方法是从特定到一般。你找到错误，然后建立模式、修正错误，最后修正过程。将其中某些步骤与你的日常例行工作相结合可以使你成为更好的程序员。但是，请不要再这里停下来。请利用你的反模式知识来修正过程，继续使价值链向上移动，并让你整个公司的程序员都变得更棒，你还能可以发布反模式帮助你甚至不认识的程序员。

在这里，我还想补充下我自己的观点：

1.关于反模式的建立，是以经验为铺垫的。在经验不足的情况下，我们要做的是，能多善于总结我们开发所遇到的问题，形成自己的反模式。

2.前面提到的一个步骤建立模式，很有敏捷开发的味道。

3.反模式还传递给我们这样一个思想，简单设计，不为明天而设计的思想。

4.沟通也是反模式的一个旋律。敏捷开发的核心也是沟通。

5..反模式不仅仅是单纯为了解决问题，而是传递一种深入思考BUG，优化预防BUG渠道的思想。