反模式

如果我们认为模式代表一个最佳的实践，那么反模式将代表我们已经学到一个教训。受启发于Gof的《设计模式》，Andrew Koeing在1995年的11月的C++报告大会上首次提出反模式。在Koeing的报告中，反模式有着两种观念:

• 描述对于一个特殊的问题，提出了一个糟糕的解决方案，最终导致一个坏结果发生
• 描述如何摆脱上述解决方案并能提出一个好的解决方案

关于这个话题，Alexander写过要在好的设计结构和好的上下文中找到平衡是困难的:

这些笔记是关于设计的过程，这个过程发明显示一个新的物理顺序响应功能，组织形式，物质的东西......每一个设计问题开始于努力实现两个实体之间的形式：问题中的形式和它的上下文。此形式是解决问题的方法，而上下文定义了该问题。

虽然理解设计模式很重要，但对于理解反模式也是同等重要。我们有资格知道这背后的原因。当我们开发一个应用，这个工程的生命周期开始建设一直至项目完成，但一旦完成后，就进入维护阶段。判断一个解决方案的好坏要看这个团队在这个项目上投资的技术和花费的时间。这里被认为是好的和坏的情况下-如果应用在错误的情况下，一个“完美”的设计可能有资格作为一个反模式。

最大的挑战发生于应用进入生产和维护阶段。一个之前没有开发过这个应用的开发者来维护一个系统可能会引进糟糕的设计。如果说糟糕的设计是因为反模式，那么将允许开发者提前找到一种认识到时这样的手段，这样就能避免一些普通错误的发生，与此同时这也是设计模式给我们提供一种认识到普通技术也是有用的方式。

反模式是一个值得为此专门编写编写总结文档的糟糕设计。Javascript的反模式例子如下:

• 在全局上面文中定义大量污染全局命令空间的变量
• 在调用setTimeout和setInterval时传递字符串(会用eval来执行)而不是函数。
• 修改Object的原型 (这是最糟糕的反模式)
• 使用内联Javascript

在本应使用document.createElement的地方使用document.write。document.write被错误的用了相当多的年头，它有相当多的缺点，包括如果在页面加载后执行它可能会覆盖我们的页面。再有它不能工作在XHTML下，这也是另外一个我们使用像document.createElement这种对DOM友好方法的原因。

知道反模式对成功来说很关键。一旦我们能识别这些反模式，我们就能够重构我们的代码使项目的整体质量立马提升。