什么是反模式
如果我们认为一种模式代表一种最佳实践，那么一种反模式就代表我们已经学到的教训。反模式这个术语是1995年由安德鲁·凯尼格在当年的11月C++报告中创造的，是受“四人组”所著《设计模式》一书的启发。在凯尼格的报告中，他提出反模式的两个概念：
描述一种针对某个特定问题的不良解决方案，该方案会导致糟糕的情况发生；
描述如何摆脱前述的糟糕情况以及如何创造好的解决方案
反模式的由来
每一个设计问题都是以在两个实体之间实现平衡为开始的，即：问题的形式和它的上下文。形式是解决问题的方案；上下文定义该问题。
虽然设计模式很重要，但是理解反模式也同样重要。创建应用程序时，一个项目的声明周期就会以此为起点；一旦完成了初始版本，就需要进行维护。最终方案的质量好坏取决于技能水平和团队投入时间。
当然这里的好坏是在上下文中考虑的，如果一个“完美的”设计模式应用于错误的上下文中，那么它也可能是一个反模式。应用程序在进入生产环境并即将进入维护模式时会面临更大的挑战。之前没有研究过该应用程序的开发人员，在这样的系统上工作，可能会将不良设计意外地引入到项目中，如果说将不良实践创建为反模式，则能让开发人员有办法提前识别这些反模式，这样可以避免常见错误的发生。
总结
总的来说，反模式是一种值得记录的不良设计。Javascript中常见的反模式有很多，简单举几个例子：
- 在全局上下文中定义大量的变量污染全局命名空间。
- 向setTimeout或setInterval传递字符串，无意中触发eval( )的内部使用。
- 修改Object类的原型（这是一个特别不良的反模式）
- 以内联形式使用Javascript，它是不可改变的。
- 在使用document.createElement等原生DOM方法更适合的情况下使用document.write。多年来document.write一直都在被滥用，并有相当多的缺点，包括：如果在页面加载完成后执行document.write，它实际上会重写我们的页面，而documet.createElement则不会。
总之，了解反模式是成功的关键。一旦能够识别这种反模式，我们能重构代码来防止它们的出现，这样我们解决方案的总体质量就能立即得到改善。
