[前言]
design pattern是設(shè)計模式，通常是前人在軟件開發(fā)過程中積累出來的解決一些問題
的現(xiàn)成套路，按它們來做可獲益無窮。anti-pattern也是一些現(xiàn)成的套路，但它們是現(xiàn)成的
錯誤套路，避免它們則亦可獲益無窮。本文譯者Korner Hill的更多其它翻譯和原創(chuàng)文章可
在blog上找到http://blog.csdn.net/KornerHill。
計算機領(lǐng)域內(nèi)的很多詞匯都缺少公認的中文翻譯，anti-pattern也是如此，這里譯為反面模
式，乃是因為它本身是作為反面教材使用的模式。其實直接用“反面教材”更通俗易懂，但
這里為了保持它與設(shè)計模式之間的內(nèi)在關(guān)聯(lián)，而使用了“反面模式”一詞。
來自Wikipedia, 自由百科全書
在軟件工程中，一個反面模式（anti-pattern或antipattern）指的是在實踐中明顯出現(xiàn)但
又低效或是有待優(yōu)化的設(shè)計模式。
Andrew Koenig在1995年造了anti-pattern這個詞，靈感來自于GoF的《設(shè)計模式》一書。而
這本書則在軟件領(lǐng)域發(fā)明了“設(shè)計模式”（design pattern）一詞。三年后antipattern因
《AntiPatterns》這本書而獲得普及，而它的使用也從軟件設(shè)計領(lǐng)域擴展到了日常的社會互
動中。按《AntiPatterns》作者的說法，可以用至少兩個關(guān)鍵因素來把反面模式和不良習慣
、錯誤的實踐或糟糕的想法區(qū)分開來：
* 行動、過程和結(jié)構(gòu)中的一些重復(fù)出現(xiàn)的乍一看是有益的，但最終得不償失的模式
* 在實踐中證明且可重復(fù)的清晰記錄的重構(gòu)方案
很多反面模式只相當于是錯誤、咆哮、不可解的問題、或是可能可以避免的糟糕的實踐，它
們的名字通常都是一些用反話構(gòu)成的詞語。有些時候陷阱（pitfalls）或黑色模式（dark
patterns）這些不正式的說法會被用來指代各類反復(fù)出現(xiàn)的糟糕的解決方法。因此，一些有
爭議的候選的反面模式不會被正式承認。
[1. 已知的反面模式]
[1.1 組織結(jié)構(gòu)的反面模式]
* 從天而降的責任（accidental ownership）：雇員們接手了一個與當前系統(tǒng)完全無關(guān)的系
統(tǒng)，在沒有合適的訓(xùn)練、學(xué)習或關(guān)心下就得維護它（在90年代的電話->網(wǎng)絡(luò)管理員中很常
見）
* 分析麻痹（Analysis paralysis）：在項目的分析階段付出的努力太少
* 引擎室里的船長（Captain in the engine room）：團隊帶頭人把時間和精力全花在技術(shù)
問題上，沒有人開船
* 搖錢樹（cash cow）：盈利的老產(chǎn)品通常會導(dǎo)致對新產(chǎn)品的自滿
* 持續(xù)退化（Continuous obsolescence）：不成比例地投入精力把系統(tǒng)移植到新環(huán)境下
* 經(jīng)費轉(zhuǎn)移（Cost migration）：項目經(jīng)費轉(zhuǎn)移到弱勢的部門或商業(yè)伙伴那里
* 危機模式（Crisis mode）或救火模式（firefighting mode）：硬是等到火燒屁屁的時候
才去解決問題，結(jié)果是每個問題都成了危機問題
* 委員會設(shè)計（Design by committee）：很多人同時進行設(shè)計，卻沒有統(tǒng)一的看法
* 委員會擴張（Escalation of commitment）：明知錯了還不能收回之前的決定
* 英雄模式（Hero-mode）：長期依賴成員的英雄式的努力來滿足不可能的任務(wù)期限，同時
又忽視從一開始就沒有注重軟件品質(zhì)帶來的損失
* 我早就說過（I told you so）：某人之前的警告沒得到重視，事后又被人發(fā)現(xiàn)是正確的
，并引起了關(guān)注
* 主觀管理（Management by hope）：認為平靜的表象就代表一切順利
* 通過忽視的管理（Management by neglect）：過多地委任
* 用數(shù)字管理（Management by numbers）：過于關(guān)注非本質(zhì)而又不易取得的數(shù)字指標
* Perkele管理（Management by perkele）：用完全聽不進異議的獨裁作風進行管理
* 思考管理（Management by wondering）：希望一個團隊定義自己的目標，然后考慮他們
要做什么
* 精神危險（Moral hazard）：不讓做決定的人知道他的決定會帶來什么結(jié)果
* 蘑菇管理（Mushroom management）：有事也不通知雇員或是錯誤地通知（像種蘑菇一樣
放在黑地里施肥）
* 不是這里發(fā)明的（Not invented here）：拒絕使用組織外的主意或方案
* 精益求精（Polishing the polish）：把已經(jīng)完成的項目交給下屬去做，禁止他們做其它
的事，又報怨他們低效率
* 規(guī)模爬行（另外兩個類似的詞是復(fù)雜度陷阱和功能主義者）：不適當控制項目的規(guī)模的增
加
* 煙囪（Stovepipe）：結(jié)構(gòu)上支持數(shù)據(jù)主要在上下方面的流動，卻禁止平行的通信
* 客戶套牢（Vendor lock-in）：使一個系統(tǒng)過于依賴外部提供的部件
* 小提琴弦組織（Violin string organization）：高度調(diào)整和裁減卻沒有靈活性的組織
[1.2 項目管理的反面模式]
* 死亡征途（Death march）：除了CEO，每個人都知道這個項目會完蛋。但是真相卻被隱瞞
下來，直到大限來臨
* 拖后腿的無知（Heel dragging blindness）：項目經(jīng)理的無知拖了后腿。出于某些動機
，員工趨向于減少努力來延長項目時限。例如，他們是按時間（而非結(jié)果）付費，又沒有
能順利轉(zhuǎn)移過去的后續(xù)項目
* 煙和鏡（Smoke and mirros）：展示還沒完成的函數(shù)會是怎樣
* 軟件膨脹（Software bloat）：允許系統(tǒng)的后續(xù)版本使用更多的資源
[1.3 團隊管理的反面模式]
* 缺席的經(jīng)理（Absentee manager）：經(jīng)理長時間不出現(xiàn)的情況
* Cage match negotiator：經(jīng)理用“不惜一切代價也要取勝”的方式來管理
* Doppelganger：某些經(jīng)理或同事剛才還平易近人，過了一下就變得難于相處
* 無底洞（Fruitless hoops）：經(jīng)理在做出決定前要求大量的（通常是無意義的）數(shù)據(jù)
* 黃金小孩（Golden child）：依據(jù)人情而不是實際的表現(xiàn)，特殊的責任、機會、認可、獎
勵被給予團隊成員
* 無頭蒼蠅（Headless chicken）：經(jīng)理總是處于恐慌中
* 領(lǐng)導(dǎo)而非經(jīng)理（Leader not manager）：經(jīng)理是一個好的領(lǐng)導(dǎo)，卻缺乏行政和管理能力
* 管理克隆（Managerial cloning）：經(jīng)理對所有人的雇傭和指導(dǎo)的方法都是一樣的：像他
們的老板
* 經(jīng)理而非領(lǐng)導(dǎo)（Manager not leader）：經(jīng)理能勝任行政和管理職責，卻缺乏領(lǐng)導(dǎo)能力
* 指標濫用（Metric abuse）：惡意或是不適當?shù)厥褂弥笜?/p>
* 好好先生（Mr. nice guy）：經(jīng)理想成為每個人的朋友
* 鴕鳥（Ostrich）：有些人員整天做些空洞的事情卻忽視那些需要在最后期限前被解決的
事情還以為會沒事，通常更希望看起來很忙，但實際上會浪費和用盡時間
* 平民英雄（Proletariat hero）：口頭上稱贊普通員工技術(shù)如何如何之牛，實際上管理層
只是把他們當成棋子，目的是有借口更多的攤派任務(wù)以及增加生產(chǎn)目標
* 得勢的暴發(fā)戶（Rising upstart）：指這樣一些潛在的新星，他們急不可耐地想要爬上去
，不愿花費量些必要的時間去學(xué)習和成長
* 海鷗管理（Seagull management）：飛進來，弄得雞飛狗跳、一片兒狼藉，然后就拍拍屁
股走人
* 懦弱的執(zhí)行者（Spineless executive）：管理者沒有勇氣來面對當前形勢、來承擔責任
、或是來保護自己的下屬
* 三個腦袋的騎士（Three-headed knight）：沒有決斷力的管理者
* 終極武器（Ultimate weapon）：有些人完全依賴自己的同事或是組織，好像他們自己只
是一個導(dǎo)體，把問題全部傳給別人
* 熱身狀態(tài)（Warm bodies）：指有些員工幾乎不能達到工作的最低要求，因此不斷地從一
個項目轉(zhuǎn)到另一個項目，或是從一個團隊換到另一個團隊。
* 只會說是的人（Yes man）：指一些管理者當面對CEO說的每句話都說是，CEO不在的情況
下他可能說的又是另一回事
[1.4 分析方式的反面模式]
* 尿布說明（Napkin specification）：把給開發(fā)團隊的功能或技術(shù)說明寫在尿布上（即是
說，不正式，又缺乏細節(jié)），和根本就沒有說明一樣
* 假需求（Phony requirements）：所有的需求都是通過網(wǎng)絡(luò)會議或是電話通知給開發(fā)團隊
的，沒有任何功能、技術(shù)上的說明或其它說明文檔
* 火箭說明（Retro-specification）：在項目已經(jīng)啟動之后才開始寫技術(shù)、功能說明
[1.5 通常的設(shè)計反面模式]
* 抽象倒置（Abstraction inversion）：不把用戶需要的功能直接提供出來，導(dǎo)致他們要
用更上層的函數(shù)來重復(fù)實現(xiàn)
* 用意不明（Ambiguous viewpoint）：給出一個模型（通常是OOAD，面向?qū)ο蠓治雠c設(shè)計
）卻沒有指出用意何在
* 大泥球（Big ball of mud）：系統(tǒng)的結(jié)構(gòu)不清晰
* 斑點（Blob）：參考上帝對象（God object）
* 氣體工廠（Gas factory）：復(fù)雜到不必要的設(shè)計
* 輸入問題（Input kludge）：無法指出和實現(xiàn)對不正確的輸入的處理
* 接口膨脹（Interface bloat）：把一個接口做得過于強大以至于極其難以實現(xiàn)
* 魔力按鍵（Magic pushbutton）：直接在接口的代碼里編寫實現(xiàn)，而不使用抽象
* 競爭危機（Race hazard）：無法知道事件在不同順序下發(fā)生時產(chǎn)生的結(jié)果
* 鐵軌方案（Railroaded solution）：由于沒有預(yù)見和在設(shè)計方面欠缺靈活性，提出的方
案即使很爛，也成了唯一選擇
* 重復(fù)耦合（Re-coupling）：不必要的對象依賴
* 煙囪系統(tǒng)（Stovepipe system）：根本就不能維護的被病態(tài)的組合在一起的組件
* （Staralised schema）：指這樣的數(shù)據(jù)庫方案，包含了兩種用途的表，一是通用的，另
一種是有針對性的
[1.5.1 面向?qū)ο笤O(shè)計的反面模式]
* 貧血的域模型（Anemic Domain Model）：僅因為每個對象都要有屬性和方法，而在使用
域模型的時候沒有加入非OOP的業(yè)務(wù)邏輯
* （BaseBean）：繼承一個工具類，而不是代理它
* 調(diào)用父類（Call super）：需要子類調(diào)用父類被重載的方法
* 圓還是橢圓問題（Circle-ellipse problem）：基于變量的子類化關(guān)系進行子類化（原句
是Subtyping variable-types on the basis of value-subtypes）
* 空子類的錯誤（Empty subclass failure）：創(chuàng)建不能通過“空子類測試”的類，因為它
和直接從它繼承而來沒有做其它任何修改的子類表現(xiàn)得不同
* 上帝對象（God object）：在設(shè)計的單一部分（某個類）集中了過多的功能
* 對象糞池（Object cesspool）：復(fù)用那些不滿足復(fù)用條件的對象
* 不羈的對象（Object orgy）：沒有成功封裝對象，外部可以不受限制地訪問它的內(nèi)部
* 幽靈（Poltergeists）：指這樣一些對象，它們唯一的作用就是把信息傳給其它對象
* 順序耦合（Sequential coupling）：指這樣一些對象，它們的方法必須要按某種特定順
序調(diào)用
* 單例愛好者（Singletonitis）：濫用單例（singleton）模式
* 又TMD來一層（Yet Another Fucking Layer）：向程序中添加不必要的層次結(jié)構(gòu)、庫或是
框架。自從第一本關(guān)于編程的模式的書出來之后這就變得很普遍。
* 唷唷問題（Yo-yo problem）：一個結(jié)構(gòu)（例如繼承）因為過度分裂而變得難于理解
[1.6 編程方面的反面模式]
* 意外的復(fù)雜度（Accidental complexity）：向一個方案中引入不必要的復(fù)雜度
* 積累再開火（Accumulate and fire）：通過一系列全局變量設(shè)置函數(shù)的參數(shù)
* 在遠處行動（Action at distance）：意料之外的在系統(tǒng)分離的部分之間迭代
* 盲目信任（Blind faith）：缺乏對bugfix或子函數(shù)返回值的正確性檢查
* 船錨（Boat anchor）：在系統(tǒng)中保留無用的部分
* bug磁鐵（Bug magnet）：指很少被調(diào)用以至于最容易引起錯誤的代碼，或是易出錯的構(gòu)
造或?qū)嵺`
* 忙循環(huán)（Busy spin）：在等待的時候不斷占用CUP，通常是因為采用了重復(fù)檢查而不是適
當?shù)南C制
* 緩存失敗（Caching failure）：錯誤被修正后忘記把錯誤標志復(fù)位
* 貨運崇拜編程（Cargo cult programming）：在不理解的情況下就使用模式和方法
* 檢查類型而不是接口（Checking type instead of interface）：僅是需要接口符合條件
的情況下卻檢查對象是否為某個特定類型。可能導(dǎo)致空子類失敗
* 代碼動力（Code momentum）：過于限制系統(tǒng)的一些部分，因為在其它部分反復(fù)對這部分
的內(nèi)容做出假設(shè)
* 靠異常編程（Coding by exception）：當有特例被發(fā)現(xiàn)時才添加新代碼去解決
* 隱藏錯誤（Error hiding）：在顯示給用戶之前捕捉到錯誤信息，要么什么都不顯示，要
么顯示無意義的信息
* 異常處理（Expection handling）：使用編程語言的錯誤處理系統(tǒng)實現(xiàn)平常的編程邏輯
* 硬編碼（Hard code）：在實現(xiàn)過程中對系統(tǒng)環(huán)境作假設(shè)
* 熔巖流（Lava flow）：保留不想要的（冗余的或是低質(zhì)量的）代碼，僅因為除去這些代
碼的代價太高或是會帶來不可預(yù)期的結(jié)果
* loop-switch序列（Loop-switch sequence）使用循環(huán)結(jié)構(gòu)來編寫連續(xù)步驟而不是switch
語句
* 魔幻數(shù)字（Magic numbers）：在算法里直接使用數(shù)字，而不解釋含義
* 魔幻字符串（Magic strings）：直接在代碼里使用常量字符串，例如用來比較，或是作
為事件代碼
* 猴子工作（Monkey work）：指在一些代碼復(fù)用性或設(shè)計上很差的項目中的反復(fù)出現(xiàn)的支
持性的代碼。通常會被避免或是匆忙完成，因此易于出錯，有可能會很快變?yōu)閎ug磁鐵。
* Packratting：由于長時間不及時釋放動態(tài)分配的內(nèi)存而消耗了過量的內(nèi)存
* 類似保護（Parallel protectionism）：隨著代碼變得復(fù)雜和脆弱，很容易就克隆出一個
類似的的結(jié)構(gòu)，而不是直接往現(xiàn)有的結(jié)構(gòu)中添加一些瑣碎的屬性
* 巧合編程（Programming by accident）：嘗試用試驗或是出錯的方式解決問題，有時是
因為很爛的文檔或是一開始就沒把東西搞清楚
* 餛飩代碼（Ravioli code）：系統(tǒng)中有許多對象都是松散連接的
* 軟代碼（Soft code）：在配置文件里保存業(yè)務(wù)邏輯而不是在代碼中
* 面條代碼（Spaghetti code）：指那些結(jié)構(gòu)上完全不可理解的系統(tǒng)，尤其是因為誤用代碼
結(jié)構(gòu)
* 棉花里放羊毛（Wrapping wool in cottom）：常見的情況是某些類的方法只有一行，就
是調(diào)用框架的代碼，而沒有任何其它有用的抽象
[1.7 方法學(xué)上的反面模式]
* 拷貝粘貼編程（Copy and paste programming）：拷貝（然后修改）現(xiàn)有的代碼而不是假
造通用的解決方案
* 拆除（De-factoring）：去掉功能，把它轉(zhuǎn)化成文檔的過程
* 黃金大錘（Golden hammer）：認為自己最喜歡的解決方案是到處通用的（見：銀彈）
* 未必有之事（Improbability factor）：認為已知的錯誤不會出現(xiàn)
* 低處的果子（Low hanging fruit）：先處理更容易的問題而忽略更大更復(fù)雜的問題。這
個問題有些類似于這種情況：科學(xué)、哲學(xué)和技術(shù)上的發(fā)現(xiàn)在早期都比較容易得到，一旦問
題已經(jīng)被人研究過了，再要有所創(chuàng)新就難了
* 不是這里做的（Not built here）：見“重新發(fā)明輪子”、“不是這里發(fā)明的”
* 不成熟的優(yōu)化（Premature optimization）：在編碼的早期追求代碼的效率，犧牲了好的
設(shè)計、可維護性、有時甚至是現(xiàn)實世界的效率
* 轉(zhuǎn)換編程法（Programming by permutation）：試圖通過連續(xù)修改代碼再看是否工作的方
式來解決問題
* 重新發(fā)明方的輪子（Reinventing the square wheel）：已經(jīng)有一個很好的方案了，又再
搞一個爛方案來替代它
* 重新發(fā)明輪子（Reinventing the wheel）：無法采納現(xiàn)有的成熟的方案
* 銀彈（Silver bullet）：認為自己最喜歡的技術(shù)方案能解決一個更大的問題
* 測試人員驅(qū)動開發(fā)（Tester driven development）：軟件工程的需求來自bug報告
[1.8 測試反面模式]
* 敵意測試（hostile testing）：對抗實際的開發(fā)方案，使用過量的測試
* 自身測試（Meta-testing）：過度設(shè)計測試過程以至于它本身都需要測試，也被稱為“看
門人的看門人”
* 移動標的（Moving target）：連續(xù)修改設(shè)計和實現(xiàn)從而逃避現(xiàn)現(xiàn)有的測試過程
* 奴隸測試（Slave testing）：通過發(fā)匿名電郵或賄賂的方式控制測試人員，從而達到股
東的要求
[1.9 配置管理反面模式]
* 依賴的地獄（Dependency hell）：需要的產(chǎn)品的版本導(dǎo)致的問題
* 路徑地獄（Classpath hell）：和特定庫有關(guān)的問題，例如依賴關(guān)系和要滿足程序運行
所需的版本
* 擴展沖突（Extension conflict）：蘋果系統(tǒng)在Mac OS X版本之前的不同擴展的問題
* DLL地獄（DLL hell）：不同版本帶來的問題，DLL可見性和多版本問題，在微軟的
Windows上尤為突出
* JAR地獄（JAR hell）：JAR文件不同版本或路徑帶來的問題，通常是由于不懂類加載模
型導(dǎo)致的
