反面模式（Anti-pattern）

[前言]

design pattern是設計模式，通常是前人在軟體開發過程中積累出來的解決一些問題
的現成套路，按它們來做可獲益無窮。anti-pattern也是一些現成的套路，但它們是現成的
錯誤套路，避免它們則亦可獲益無窮。本文譯者Korner Hill的更多其它翻譯和原創文章可
在blog上找到http://blog.csdn.net/KornerHill。

電腦領域內的很多詞彙都缺少公認的中文翻譯，anti-pattern也是如此，這裡譯為反面模
式，乃是因為它本身是作為反面教材使用的模式。其實直接用“反面教材”更通俗易懂，但
這裡為了保持它與設計模式之間的內在關聯，而使用了“反面模式”一詞。

 

來自Wikipedia, 自由百科全書

在軟體工程中，一個反面模式（anti-pattern或antipattern）指的是在實踐中明顯出現但
又低效或是有待最佳化的設計模式。

Andrew Koenig在1995年造了anti-pattern這個詞，靈感來自於GoF的《設計模式》一書。而
這本書則在軟體領域發明了“設計模式”（design pattern）一詞。三年後antipattern因
《AntiPatterns》這本書而獲得普及，而它的使用也從軟體設計領域擴充到了日常的社會互
動中。按《AntiPatterns》作者的說法，可以用至少兩個關鍵因素來把反面模式和不良習慣
、錯誤的實踐或糟糕的想法區分開來：

* 行動、過程和結構中的一些重複出現的乍一看是有益的，但最終得不償失的模式
* 在實踐中證明且可重複的清晰記錄的重構方案

很多反面模式只相當於是錯誤、咆哮、不可解的問題、或是可能可以避免的糟糕的實踐，它
們的名字通常都是一些用反話構成的詞語。有些時候陷阱（pitfalls）或黑色模式（dark
patterns）這些不正式的說法會被用來指代各類反覆出現的糟糕的解決方案。因此，一些有
爭議的候選的反面模式不會被正式承認。

[1. 已知的反面模式]

[1.1 組織圖的反面模式]

* 從天而降的責任（accidental ownership）：僱員們接手了一個與當前系統完全無關的系
  統，在沒有合適的訓練、學習或關心下就得維護它（在90年代的電話->網路系統管理員中很常
  見）
* 分析麻痹（Analysis paralysis）：在項目的分析階段付出的努力太少
* 引擎室裡的船長（Captain in the engine room）：團隊帶頭人把時間和精力全花在技術
  問題上，沒有人開船
* 搖錢樹（cash cow）：盈利的老產品通常會導致對新產品的自滿
* 持續退化（Continuous obsolescence）：不成比例地投入精力把系統移植到新環境下
* 經費轉移（Cost migration）：項目經費轉移到弱勢的部門或商業夥伴那裡
* 危機模式（Crisis mode）或救火模式（firefighting mode）：硬是等到火燒屁屁的時候
  才去解決問題，結果是每個問題都成了危機問題
* 委員會設計（Design by committee）：很多人同時進行設計，卻沒有統一的看法
* 委員會擴張（Escalation of commitment）：明知錯了還不能收回之前的決定
* 英雄模式（Hero-mode）：長期依賴成員的英雄式的努力來滿足不可能的任務期限，同時
  又忽視從一開始就沒有注重軟體品質帶來的損失
* 我早就說過（I told you so）：某人之前的警告沒得到重視，事後又被人發現是正確的
  ，並引起了關注
* 主觀管理（Management by hope）：認為平靜的表象就代表一切順利
* 通過忽視的管理（Management by neglect）：過多地委任
* 用數字管理（Management by numbers）：過於關注非本質而又不易取得的數字指標
* Perkele管理（Management by perkele）：用完全聽不進異議的獨裁作風進行管理
* 思考管理（Management by wondering）：希望一個團隊定義自己的目標，然後考慮他們
  要做什麼
* 精神危險（Moral hazard）：不讓做決定的人知道他的決定會帶來什麼結果
* 蘑菇管理（Mushroom management）：有事也不通知僱員或是錯誤地通知（像種蘑菇一樣
  放在黑地裡施肥）
* 不是這裡發明的（Not invented here）：拒絕使用組織外的主意或方案
* 精益求精（Polishing the polish）：把已經完成的項目交給下屬去做，禁止他們做其它
  的事，又報怨他們低效率
* 規模爬行（另外兩個類似的詞是複雜度陷阱和功能主義者）：不適當控制項目的規模的增
  加
* 煙囪（Stovepipe）：結構上支援資料主要在上下方面的流動，卻禁止平行的通訊
* 客戶套牢（Vendor lock-in）：使一個系統過於依賴外部提供的組件
* 小提琴弦組織（Violin string organization）：高度調整和裁減卻沒有靈活性的組織

[1.2 專案管理的反面模式]

* 死亡征途（Death march）：除了CEO，每個人都知道這個項目會完蛋。但是真相卻被隱瞞
  下來，直到大限來臨
* 拖後腿的無知（Heel dragging blindness）：專案經理的無知拖了後腿。出於某些動機
  ，員工趨向於減少努力來延長項目時限。例如，他們是按時間（而非結果）付費，又沒有
  能順利轉移過去的後續項目
* 煙和鏡（Smoke and mirros）：展示還沒完成的函數會是怎樣
* 軟體膨脹（Software bloat）：允許系統的後續版本使用更多的資源

[1.3 團隊管理的反面模式]

* 缺席的經理（Absentee manager）：經理長時間不出現的情況
* Cage match negotiator：經理用“不惜一切代價也要取勝”的方式來管理
* Doppelganger：某些經理或同事剛才還平易近人，過了一下就變得難於相處
* 無底洞（Fruitless hoops）：經理在做出決定前要求大量的（通常是無意義的）資料
* 黃金小孩（Golden child）：依據人情而不是實際的表現，特殊的責任、機會、認可、獎
  勵被給予團隊成員
* 無頭蒼蠅（Headless chicken）：經理總是處於恐慌中
* 領導而非經理（Leader not manager）：經理是一個好的領導，卻缺乏行政和管理能力
* 管理複製（Managerial cloning）：經理對所有人的僱傭和指導的方法都是一樣的：像他
  們的老闆
* 經理而非領導（Manager not leader）：經理能勝任行政和管理職責，卻缺乏領導能力
* 指標濫用（Metric abuse）：惡意或是不適當地使用指標
* 好好先生（Mr. nice guy）：經理想成為每個人的朋友
* 鴕鳥（Ostrich）：有些人員整天做些空洞的事情卻忽視那些需要在期限前被解決的
  事情還以為會沒事，通常更希望看起來很忙，但實際上會浪費和用盡時間
* 平民英雄（Proletariat hero）：口頭上稱讚普通員工技術如何如何之牛，實際上管理層
  只是把他們當成棋子，目的是有借口更多的攤派任務以及增加生產目標
* 得勢的暴發戶（Rising upstart）：指這樣一些潛在的新星，他們急不可耐地想要爬上去
  ，不願花費量些必要的時間去學習和成長
* 海鷗管理（Seagull management）：飛進來，弄得雞飛狗跳、一片兒狼藉，然後就拍拍屁
  股走人
* 懦弱的執行者（Spineless executive）：管理者沒有勇氣來面對當前形勢、來承擔責任
  、或是來保護自己的下屬
* 三個腦袋的騎士（Three-headed knight）：沒有決斷力的管理者
* 終極武器（Ultimate weapon）：有些人完全依賴自己的同事或是組織，好像他們自己只
  是一個導體，把問題全部傳給別人
* 熱身狀態（Warm bodies）：指有些員工幾乎不能達到工作的最低要求，因此不斷地從一
  個項目轉到另一個項目，或是從一個團隊換到另一個團隊。
* 只會說是的人（Yes man）：指一些管理者當面對CEO說的每句話都說是，CEO不在的情況
  下他可能說的又是另一回事

[1.4 分析方式的反面模式]

* 尿布說明（Napkin specification）：把給Team Dev的功能或技術說明寫在尿布上（即是
  說，不正式，又缺乏細節），和根本就沒有說明一樣
* 假需求（Phony requirements）：所有的需求都是通過網路會議或是電話通知給Team Dev
  的，沒有任何功能、技術上的說明或其它說明文檔
* 火箭說明（Retro-specification）：在項目已經啟動之後才開始寫技術、功能說明

[1.5 通常的設計反面模式]

* 抽象倒置（Abstraction inversion）：不把使用者需要的功能直接提供出來，導致他們要
  用更上層的函數來重複實現
* 用意不明（Ambiguous viewpoint）：給出一個模型（通常是OOAD，物件導向分析與設計
  ）卻沒有指出用意何在
* 大泥球（Big ball of mud）：系統的結構不清晰
* 斑點（Blob）：參考上帝對象（God object）
* 氣體工廠（Gas factory）：複雜到不必要的設計
* 輸入問題（Input kludge）：無法指出和實現對不正確的輸入的處理
* 介面膨脹（Interface bloat）：把一個介面做得過於強大以至於極其難以實現
* 魔力按鍵（Magic pushbutton）：直接在介面的代碼裡編寫實現，而不使用抽象
* 競爭危機（Race hazard）：無法知道事件在不同順序下發生時產生的結果
* 鐵軌方案（Railroaded solution）：由於沒有預見和在設計方面欠缺靈活性，提出的方
  案即使很爛，也成了唯一選擇
* 重複耦合（Re-coupling）：不必要的對象依賴
* 煙囪系統（Stovepipe system）：根本就不能維護的被病態的組合在一起的組件
* （Staralised schema）：指這樣的資料庫方案，包含了兩種用途的表，一是通用的，另
  一種是有針對性的

[1.5.1 物件導向設計的反面模式]

* 貧血的領域模型（Anemic Domain Model）：僅因為每個對象都要有屬性和方法，而在使用
  領域模型的時候沒有加入非OOP的商務邏輯
* （BaseBean）：繼承一個工具類，而不是代理它
* 調用父類（Call super）：需要子類調用父類被重載的方法
* 圓還是橢圓問題（Circle-ellipse problem）：基於變數的子類化關係進行子類化（原句
  是Subtyping variable-types on the basis of value-subtypes）
* 空子類的錯誤（Empty subclass failure）：建立不能通過“空子類測試”的類，因為它
  和直接從它繼承而來沒有做其它任何修改的子類表現得不同
* 上帝對象（God object）：在設計的單一部分（某個類）集中了過多的功能
* 對象糞池（Object cesspool）：複用那些不滿足複用條件的對象
* 不羈的對象（Object orgy）：沒有成功封裝對象，外部可以不受限制地訪問它的內部
* 幽靈（Poltergeists）：指這樣一些對象，它們唯一的作用就是把資訊傳給其它對象
* 順序耦合（Sequential coupling）：指這樣一些對象，它們的方法必須要按某種特定順
  序調用
* 單例愛好者（Singletonitis）：濫用單例（singleton）模式
* 又TMD來一層（Yet Another Fucking Layer）：向程式中添加不必要的階層、庫或是
  架構。自從第一本關於編程的模式的書出來之後這就變得很普遍。
* 唷唷問題（Yo-yo problem）：一個結構（例如繼承）因為過度分裂而變得難於理解

[1.6 編程方面的反面模式]

* 意外的複雜度（Accidental complexity）：向一個方案中引入不必要的複雜度
* 積累再開火（Accumulate and fire）：通過一系列全域變數設定函數的參數
* 在遠處行動（Action at distance）：意料之外的在系統分離的部分之間迭代
* 盲目信任（Blind faith）：缺乏對bugfix或子函數傳回值的正確性檢查
* 船錨（Boat anchor）：在系統中保留無用的部分
* bug磁鐵（Bug magnet）：指很少被調用以至於最容易引起錯誤的代碼，或是易出錯的構
  造或實踐
* 忙迴圈（Busy spin）：在等待的時候不斷佔用CUP，通常是因為採用了重複檢查而不是適
  當的訊息機制
* 緩衝失敗（Caching failure）：錯誤被修正後忘記把錯誤標誌複位
* 貨運崇拜編程（Cargo cult programming）：在不理解的情況下就使用模式和方法
* 檢查類型而不是介面（Checking type instead of interface）：僅是需要介面符合條件
  的情況下卻檢查對象是否為某個特定類型。可能導致空子類失敗
* 代碼動力（Code momentum）：過於限制系統的一些部分，因為在其它部分反覆對這部分
  的內容做出假設
* 靠異常編程（Coding by exception）：當有特例被發現時才添加新代碼去解決
* 隱藏錯誤（Error hiding）：在顯示給使用者之前捕捉到錯誤資訊，要麼什麼都不顯示，要
  麼顯示無意義的資訊
* 異常處理（Expection handling）：使用程式設計語言的錯誤處理系統實現平常的編程邏輯
* 寫入程式碼（Hard code）：在實現過程中對系統內容作假設
* 熔岩流（Lava flow）：保留不想要的（冗餘的或是低品質的）代碼，僅因為除去這些代
  碼的代價太高或是會帶來不可預期的結果
* loop-switch序列（Loop-switch sequence）使用迴圈結構來編寫連續步驟而不是switch
  語句
* 魔幻數字（Magic numbers）：在演算法裡直接使用數字，而不解釋含義
* 魔幻字串（Magic strings）：直接在代碼裡使用常量字串，例如用來比較，或是作
  為事件代碼
* 猴子工作（Monkey work）：指在一些代碼複用性或設計上很差的項目中的反覆出現的支
  持性的代碼。通常會被避免或是匆忙完成，因此易於出錯，有可能會很快變為bug磁鐵。
* Packratting：由於長時間不及時釋放動態分配的記憶體而消耗了過量的記憶體
* 類似保護（Parallel protectionism）：隨著代碼變得複雜和脆弱，很容易就複製出一個
  類似的的結構，而不是直接往現有的結構中添加一些瑣碎的屬性
* 巧合編程（Programming by accident）：嘗試用實驗或是出錯的方式解決問題，有時是
  因為很爛的文檔或是一開始就沒把東西搞清楚
* 餛飩代碼（Ravioli code）：系統中有許多個物件都是鬆散串連的
* 軟代碼（Soft code）：在設定檔裡儲存商務邏輯而不是在代碼中
* 麵條代碼（Spaghetti code）：指那些結構上完全不可理解的系統，尤其是因為誤用代碼
  結構
* 棉花裡放羊毛（Wrapping wool in cottom）：常見的情況是某些類的方法只有一行，就
  是調用架構的代碼，而沒有任何其它有用的抽象

[1.7 方法學上的反面模式]

* 拷貝粘貼編程（Copy and paste programming）：拷貝（然後修改）現有的代碼而不是假
  造通用的解決方案
* 拆除（De-factoring）：去掉功能，把它轉化成文檔的過程
* 黃金大鎚（Golden hammer）：認為自己最喜歡的解決方案是到處通用的（見：銀彈）
* 未必有之事（Improbability factor）：認為已知的錯誤不會出現
* 低處的果子（Low hanging fruit）：先處理更容易的問題而忽略更大更複雜的問題。這
  個問題有些類似於這種情況：科學、哲學和技術上的發現在早期都比較容易得到，一旦問
  題已經被人研究過了，再要有所創新就難了
* 不是這裡做的（Not built here）：見“重新發明輪子”、“不是這裡發明的”
* 不成熟的最佳化（Premature optimization）：在編碼的早期追求代碼的效率，犧牲了好的
  設計、可維護性、有時甚至是現實世界的效率
* 轉換編程法（Programming by permutation）：試圖通過連續修改代碼再看是否工作的方
  式來解決問題
* 重新發明方的輪子（Reinventing the square wheel）：已經有一個很好的方案了，又再
  搞一個爛方案來替代它
* 重新發明輪子（Reinventing the wheel）：無法採納現有的成熟的方案
* 銀彈（Silver bullet）：認為自己最喜歡的技術方案能解決一個更大的問題
* 測試人員驅動開發（Tester driven development）：軟體工程的需求來自bug報告

[1.8 測試反面模式]

* 敵意測試（hostile testing）：對抗實際的開發方案，使用過量的測試
* 自身測試（Meta-testing）：過度設計測試過程以至於它本身都需要測試，也被稱為“看
  門人的看門人”
* 移動標的（Moving target）：連續修改設計和實現從而逃避現現有的測試過程
* 奴隸測試（Slave testing）：通過發匿名電郵或賄賂的方式控制測試人員，從而達到股
  東的要求

[1.9 組態管理反面模式]

* 依賴的地獄（Dependency hell）：需要的產品的版本導致的問題
  * 路徑地獄（Classpath hell）：和特定庫有關的問題，例如依賴關係和要滿足程式運行
    所需的版本
  * 擴充衝突（Extension conflict）：蘋果系統在Mac OS X版本之前的不同擴充的問題
  * DLL地獄（DLL hell）：不同版本帶來的問題，DLL可見度和多版本問題，在微軟的
    Windows上尤為突出
  * JAR地獄（JAR hell）：JAR檔案不同版本或路徑帶來的問題，通常是由於不懂類載入模
    型導致的