牽著老婆滿街逛

嚴以律己,寬以待人. 三思而后行.
GMail/GTalk: yanglinbo#google.com;
MSN/Email: tx7do#yahoo.com.cn;
QQ: 3 0 3 3 9 6 9 2 0 .

統計

隨筆 - 1513
文章 - 45
評論 - 907
引用 - 0

公告

言論：
1.每日自省；
2.享受人生；
3.盡力而為；
4.堅持不懈；
5.切莫急躁；
6.慎言敏行；
7.動心忍性；
8.上善若水。

常用鏈接

留言簿(11)

隨筆分類(466)

隨筆檔案(1513)

文章分類(46)

文章檔案(45)

相冊

收藏夾(39)

搜索

積分與排名

積分 - 2535789
排名 - 2

閱讀排行榜

反面模式（Anti-pattern）

反面模式（Anti-pattern）
                            KornerHill{}gmail.com
                                  2008-5-1

原文：http://en.wikipedia.org/wiki/Anti-pattern
譯文：http://www.yeeyan.com/articles/view/27472/7244

[前言]

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

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

文中有些個別單詞沒有翻譯，一是如bug和bugfix這樣在計算機領域內已經廣泛使用的詞，
二是像Staralised這種在字典里都查不到詞，三是像perkele這種有文化背景的名字（
perkele是芬蘭神話里的雷神）。

有些地方即使翻譯過來，可能讀者還是不一定會明白，畢竟代碼的事情不是紙上談兵。例如
Circle-ellipse problem，涉及的概念較多，雖然能翻譯過來，但讀者若要理解，還是得到
wikipedia上再查。

翻譯這篇文章確實很不容易，既要英文好，又要有編程的背景，最好還要有西方生活的背景
，在下水平有限，很多地方翻譯不到位，請各們諒解。

================================================================================
= 以下是譯文部分
================================================================================

來自Wikipedia, 自由百科全書

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

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

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

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

原文：http://en.wikipedia.org/wiki/Anti-pattern
譯文：http://www.yeeyan.com/articles/view/27472/7244

[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）：把給開發團隊的功能或技術說明寫在尿布上（即是
說，不正式，又缺乏細節），和根本就沒有說明一樣
* 假需求（Phony requirements）：所有的需求都是通過網絡會議或是電話通知給開發團隊
的，沒有任何功能、技術上的說明或其它說明文檔
* 火箭說明（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文件不同版本或路徑帶來的問題，通常是由于不懂類加載模
    型導致的

posted on 2010-12-01 23:38 楊粼波閱讀(2548) 評論(0) 編輯收藏引用

只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

牽著老婆滿街逛

導航

統計

公告

常用鏈接

留言簿(11)

隨筆分類(466)

隨筆檔案(1513)

文章分類(46)

文章檔案(45)

相冊

收藏夾(39)

工具官網

技術網站

開源網站

其他窩點

收藏網站

銀行官網

友情鏈接

資源共享

搜索

積分與排名

最新評論

閱讀排行榜

反面模式（Anti-pattern）