# 反模式 如果我們認為模式代表一個最佳的實踐，那么反模式將代表我們已經學到一個教訓。受啟發于Gof的《設計模式》，Andrew Koeing在1995年的11月的C++報告大會上首次提出反模式。在Koeing的報告中，反模式有著兩種觀念: * 描述對于一個特殊的問題，提出了一個*糟糕的*解決方案，最終導致一個壞結果發生 * 描述*如何*擺脫上述解決方案并能提出一個好的解決方案 關于這個話題，Alexander寫過要在好的設計結構和好的上下文中找到平衡是困難的: > *這些筆記是關于設計的過程，這個過程發明顯示一個新的物理順序響應功能，組織形式，物質的東西......每一個設計問題開始于努力實現兩個實體之間的形式：問題中的形式和它的上下文。此形式是解決問題的方法，而上下文定義了該問題。* 雖然理解設計模式很重要，但對于理解反模式也是同等重要。我們有資格知道這背后的原因。當我們開發一個應用，這個工程的生命周期開始建設一直至項目完成，但一旦完成后，就進入維護階段。判斷一個解決方案的好壞要看這個團隊在這個項目上投資的技術和花費的時間。這里被認為是*好的*和*壞的*情況下-如果應用在錯誤的情況下，一個“完美”的設計可能有資格作為一個反模式。 最大的挑戰發生于應用進入生產和維護階段。一個之前沒有開發過這個應用的開發者來維護一個系統可能會引進糟糕的設計。如果說糟糕的設計是因為反模式，那么將允許開發者提前找到一種認識到時這樣的手段，這樣就能避免一些普通錯誤的發生，與此同時這也是設計模式給我們提供一種認識到普通技術也是有用的方式。 反模式是一個值得為此專門編寫編寫總結文檔的糟糕設計。Javascript的反模式例子如下: * 在全局上面文中定義大量污染全局命令空間的變量 * 在調用setTimeout和setInterval時傳遞字符串(會用eval來執行)而不是函數。 * 修改Object的原型 (這是最糟糕的反模式) * 使用內聯Javascript * 在本應使用document.createElement的地方使用document.write。document.write被錯誤的用了相當多的年頭，它有相當多的缺點，包括如果在頁面加載后執行它可能會覆蓋我們的頁面。再有它不能工作在XHTML下，這也是另外一個我們使用像document.createElement這種對DOM友好方法的原因。 知道反模式對成功來說很關鍵。一旦我們能識別這些反模式，我們就能夠重構我們的代碼使項目的整體質量立馬提升。