JavaScript 反模式

反模式

如果我們認(rèn)為模式代表一個最佳的實踐，那么反模式將代表我們已經(jīng)學(xué)到一個教訓(xùn)。受啟發(fā)于Gof的《設(shè)計模式》，Andrew Koeing在1995年的11月的C++報告大會上首次提出反模式。在Koeing的報告中，反模式有著兩種觀念:

• 描述對于一個特殊的問題，提出了一個糟糕的解決方案，最終導(dǎo)致一個壞結(jié)果發(fā)生
• 描述如何擺脫上述解決方案并能提出一個好的解決方案

關(guān)于這個話題，Alexander寫過要在好的設(shè)計結(jié)構(gòu)和好的上下文中找到平衡是困難的:

這些筆記是關(guān)于設(shè)計的過程，這個過程發(fā)明顯示一個新的物理順序響應(yīng)功能，組織形式，物質(zhì)的東西......每一個設(shè)計問題開始于努力實現(xiàn)兩個實體之間的形式：問題中的形式和它的上下文。此形式是解決問題的方法，而上下文定義了該問題。

雖然理解設(shè)計模式很重要，但對于理解反模式也是同等重要。我們有資格知道這背后的原因。當(dāng)我們開發(fā)一個應(yīng)用，這個工程的生命周期開始建設(shè)一直至項目完成，但一旦完成后，就進入維護階段。判斷一個解決方案的好壞要看這個團隊在這個項目上投資的技術(shù)和花費的時間。這里被認(rèn)為是好的和壞的情況下-如果應(yīng)用在錯誤的情況下，一個“完美”的設(shè)計可能有資格作為一個反模式。

最大的挑戰(zhàn)發(fā)生于應(yīng)用進入生產(chǎn)和維護階段。一個之前沒有開發(fā)過這個應(yīng)用的開發(fā)者來維護一個系統(tǒng)可能會引進糟糕的設(shè)計。如果說糟糕的設(shè)計是因為反模式，那么將允許開發(fā)者提前找到一種認(rèn)識到時這樣的手段，這樣就能避免一些普通錯誤的發(fā)生，與此同時這也是設(shè)計模式給我們提供一種認(rèn)識到普通技術(shù)也是有用的方式。

反模式是一個值得為此專門編寫編寫總結(jié)文檔的糟糕設(shè)計。Javascript的反模式例子如下:

• 在全局上面文中定義大量污染全局命令空間的變量
• 在調(diào)用setTimeout和setInterval時傳遞字符串(會用eval來執(zhí)行)而不是函數(shù)。
• 修改Object的原型 (這是最糟糕的反模式)
• 使用內(nèi)聯(lián)Javascript
• 在本應(yīng)使用document.createElement的地方使用document.write。document.write被錯誤的用了相當(dāng)多的年頭，它有相當(dāng)多的缺點，包括如果在頁面加載后執(zhí)行它可能會覆蓋我們的頁面。再有它不能工作在XHTML下，這也是另外一個我們使用像document.createElement這種對DOM友好方法的原因。

知道反模式對成功來說很關(guān)鍵。一旦我們能識別這些反模式，我們就能夠重構(gòu)我們的代碼使項目的整體質(zhì)量立馬提升。