久久r热这里有精品视频,久久无码一区二区三区少妇,色欲久久久天天天综合网

反面模式（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是設(shè)計(jì)模式，通常是前人在軟件開發(fā)過程中積累出來的解決一些問題
的現(xiàn)成套路，按它們來做可獲益無窮。anti-pattern也是一些現(xiàn)成的套路，但它們是現(xiàn)成的
錯(cuò)誤套路，避免它們則亦可獲益無窮。本文譯者Korner Hill的更多其它翻譯和原創(chuàng)文章可
在blog上找到http://blog.csdn.net/KornerHill。

計(jì)算機(jī)領(lǐng)域內(nèi)的很多詞匯都缺少公認(rèn)的中文翻譯，anti-pattern也是如此，這里譯為反面模
式，乃是因?yàn)樗旧硎亲鳛榉疵娼滩氖褂玫哪Ｊ健Ｆ鋵?shí)直接用“反面教材”更通俗易懂，但
這里為了保持它與設(shè)計(jì)模式之間的內(nèi)在關(guān)聯(lián)，而使用了“反面模式”一詞。

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

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

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

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

來自Wikipedia, 自由百科全書

在軟件工程中，一個(gè)反面模式（anti-pattern或antipattern）指的是在實(shí)踐中明顯出現(xiàn)但
又低效或是有待優(yōu)化的設(shè)計(jì)模式。

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

* 行動(dòng)、過程和結(jié)構(gòu)中的一些重復(fù)出現(xiàn)的乍一看是有益的，但最終得不償失的模式
* 在實(shí)踐中證明且可重復(fù)的清晰記錄的重構(gòu)方案

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

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

[1. 已知的反面模式]

[1.1 組織結(jié)構(gòu)的反面模式]

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

[1.2 項(xiàng)目管理的反面模式]

* 死亡征途（Death march）：除了CEO，每個(gè)人都知道這個(gè)項(xiàng)目會完蛋。但是真相卻被隱瞞
下來，直到大限來臨
* 拖后腿的無知（Heel dragging blindness）：項(xiàng)目經(jīng)理的無知拖了后腿。出于某些動(dòng)機(jī)
，員工趨向于減少努力來延長項(xiàng)目時(shí)限。例如，他們是按時(shí)間（而非結(jié)果）付費(fèi)，又沒有
能順利轉(zhuǎn)移過去的后續(xù)項(xiàng)目
* 煙和鏡（Smoke and mirros）：展示還沒完成的函數(shù)會是怎樣
* 軟件膨脹（Software bloat）：允許系統(tǒng)的后續(xù)版本使用更多的資源

[1.3 團(tuán)隊(duì)管理的反面模式]

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

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

* 尿布說明（Napkin specification）：把給開發(fā)團(tuán)隊(duì)的功能或技術(shù)說明寫在尿布上（即是
說，不正式，又缺乏細(xì)節(jié)），和根本就沒有說明一樣
* 假需求（Phony requirements）：所有的需求都是通過網(wǎng)絡(luò)會議或是電話通知給開發(fā)團(tuán)隊(duì)
的，沒有任何功能、技術(shù)上的說明或其它說明文檔
* 火箭說明（Retro-specification）：在項(xiàng)目已經(jīng)啟動(dòng)之后才開始寫技術(shù)、功能說明

[1.5 通常的設(shè)計(jì)反面模式]

* 抽象倒置（Abstraction inversion）：不把用戶需要的功能直接提供出來，導(dǎo)致他們要
用更上層的函數(shù)來重復(fù)實(shí)現(xiàn)
* 用意不明（Ambiguous viewpoint）：給出一個(gè)模型（通常是OOAD，面向?qū)ο蠓治雠c設(shè)計(jì)
）卻沒有指出用意何在
* 大泥球（Big ball of mud）：系統(tǒng)的結(jié)構(gòu)不清晰
* 斑點(diǎn)（Blob）：參考上帝對象（God object）
* 氣體工廠（Gas factory）：復(fù)雜到不必要的設(shè)計(jì)
* 輸入問題（Input kludge）：無法指出和實(shí)現(xiàn)對不正確的輸入的處理
* 接口膨脹（Interface bloat）：把一個(gè)接口做得過于強(qiáng)大以至于極其難以實(shí)現(xiàn)
* 魔力按鍵（Magic pushbutton）：直接在接口的代碼里編寫實(shí)現(xiàn)，而不使用抽象
* 競爭危機(jī)（Race hazard）：無法知道事件在不同順序下發(fā)生時(shí)產(chǎn)生的結(jié)果
* 鐵軌方案（Railroaded solution）：由于沒有預(yù)見和在設(shè)計(jì)方面欠缺靈活性，提出的方
案即使很爛，也成了唯一選擇
* 重復(fù)耦合（Re-coupling）：不必要的對象依賴
* 煙囪系統(tǒng)（Stovepipe system）：根本就不能維護(hù)的被病態(tài)的組合在一起的組件
* （Staralised schema）：指這樣的數(shù)據(jù)庫方案，包含了兩種用途的表，一是通用的，另
一種是有針對性的

[1.5.1 面向?qū)ο笤O(shè)計(jì)的反面模式]

* 貧血的域模型（Anemic Domain Model）：僅因?yàn)槊總€(gè)對象都要有屬性和方法，而在使用
域模型的時(shí)候沒有加入非OOP的業(yè)務(wù)邏輯
* （BaseBean）：繼承一個(gè)工具類，而不是代理它
* 調(diào)用父類（Call super）：需要子類調(diào)用父類被重載的方法
* 圓還是橢圓問題（Circle-ellipse problem）：基于變量的子類化關(guān)系進(jìn)行子類化（原句
是Subtyping variable-types on the basis of value-subtypes）
* 空子類的錯(cuò)誤（Empty subclass failure）：創(chuàng)建不能通過“空子類測試”的類，因?yàn)樗?br> 和直接從它繼承而來沒有做其它任何修改的子類表現(xiàn)得不同
* 上帝對象（God object）：在設(shè)計(jì)的單一部分（某個(gè)類）集中了過多的功能
* 對象糞池（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）：一個(gè)結(jié)構(gòu)（例如繼承）因?yàn)檫^度分裂而變得難于理解

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

* 意外的復(fù)雜度（Accidental complexity）：向一個(gè)方案中引入不必要的復(fù)雜度
* 積累再開火（Accumulate and fire）：通過一系列全局變量設(shè)置函數(shù)的參數(shù)
* 在遠(yuǎn)處行動(dòng)（Action at distance）：意料之外的在系統(tǒng)分離的部分之間迭代
* 盲目信任（Blind faith）：缺乏對bugfix或子函數(shù)返回值的正確性檢查
* 船錨（Boat anchor）：在系統(tǒng)中保留無用的部分
* bug磁鐵（Bug magnet）：指很少被調(diào)用以至于最容易引起錯(cuò)誤的代碼，或是易出錯(cuò)的構(gòu)
造或?qū)嵺`
* 忙循環(huán)（Busy spin）：在等待的時(shí)候不斷占用CUP，通常是因?yàn)椴捎昧酥貜?fù)檢查而不是適
當(dāng)?shù)南C(jī)制
* 緩存失敗（Caching failure）：錯(cuò)誤被修正后忘記把錯(cuò)誤標(biāo)志復(fù)位
* 貨運(yùn)崇拜編程（Cargo cult programming）：在不理解的情況下就使用模式和方法
* 檢查類型而不是接口（Checking type instead of interface）：僅是需要接口符合條件
的情況下卻檢查對象是否為某個(gè)特定類型。可能導(dǎo)致空子類失敗
* 代碼動(dòng)力（Code momentum）：過于限制系統(tǒng)的一些部分，因?yàn)樵谄渌糠址磸?fù)對這部分
的內(nèi)容做出假設(shè)
* 靠異常編程（Coding by exception）：當(dāng)有特例被發(fā)現(xiàn)時(shí)才添加新代碼去解決
* 隱藏錯(cuò)誤（Error hiding）：在顯示給用戶之前捕捉到錯(cuò)誤信息，要么什么都不顯示，要
么顯示無意義的信息
* 異常處理（Expection handling）：使用編程語言的錯(cuò)誤處理系統(tǒng)實(shí)現(xiàn)平常的編程邏輯
* 硬編碼（Hard code）：在實(shí)現(xiàn)過程中對系統(tǒng)環(huán)境作假設(shè)
* 熔巖流（Lava flow）：保留不想要的（冗余的或是低質(zhì)量的）代碼，僅因?yàn)槌ミ@些代
碼的代價(jià)太高或是會帶來不可預(yù)期的結(jié)果
* loop-switch序列（Loop-switch sequence）使用循環(huán)結(jié)構(gòu)來編寫連續(xù)步驟而不是switch
語句
* 魔幻數(shù)字（Magic numbers）：在算法里直接使用數(shù)字，而不解釋含義
* 魔幻字符串（Magic strings）：直接在代碼里使用常量字符串，例如用來比較，或是作
為事件代碼
* 猴子工作（Monkey work）：指在一些代碼復(fù)用性或設(shè)計(jì)上很差的項(xiàng)目中的反復(fù)出現(xiàn)的支
持性的代碼。通常會被避免或是匆忙完成，因此易于出錯(cuò)，有可能會很快變?yōu)閎ug磁鐵。
* Packratting：由于長時(shí)間不及時(shí)釋放動(dòng)態(tài)分配的內(nèi)存而消耗了過量的內(nèi)存
* 類似保護(hù)（Parallel protectionism）：隨著代碼變得復(fù)雜和脆弱，很容易就克隆出一個(gè)
類似的的結(jié)構(gòu)，而不是直接往現(xiàn)有的結(jié)構(gòu)中添加一些瑣碎的屬性
* 巧合編程（Programming by accident）：嘗試用試驗(yàn)或是出錯(cuò)的方式解決問題，有時(shí)是
因?yàn)楹軤€的文檔或是一開始就沒把東西搞清楚
* 餛飩代碼（Ravioli code）：系統(tǒng)中有許多對象都是松散連接的
* 軟代碼（Soft code）：在配置文件里保存業(yè)務(wù)邏輯而不是在代碼中
* 面條代碼（Spaghetti code）：指那些結(jié)構(gòu)上完全不可理解的系統(tǒng)，尤其是因?yàn)檎`用代碼
結(jié)構(gòu)
* 棉花里放羊毛（Wrapping wool in cottom）：常見的情況是某些類的方法只有一行，就
是調(diào)用框架的代碼，而沒有任何其它有用的抽象

[1.7 方法學(xué)上的反面模式]

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

[1.8 測試反面模式]

* 敵意測試（hostile testing）：對抗實(shí)際的開發(fā)方案，使用過量的測試
* 自身測試（Meta-testing）：過度設(shè)計(jì)測試過程以至于它本身都需要測試，也被稱為“看
門人的看門人”
* 移動(dòng)標(biāo)的（Moving target）：連續(xù)修改設(shè)計(jì)和實(shí)現(xiàn)從而逃避現(xiàn)現(xiàn)有的測試過程
* 奴隸測試（Slave testing）：通過發(fā)匿名電郵或賄賂的方式控制測試人員，從而達(dá)到股
東的要求

[1.9 配置管理反面模式]

* 依賴的地獄（Dependency hell）：需要的產(chǎn)品的版本導(dǎo)致的問題
* 路徑地獄（Classpath hell）：和特定庫有關(guān)的問題，例如依賴關(guān)系和要滿足程序運(yùn)行
    所需的版本
* 擴(kuò)展沖突（Extension conflict）：蘋果系統(tǒng)在Mac OS X版本之前的不同擴(kuò)展的問題
* DLL地獄（DLL hell）：不同版本帶來的問題，DLL可見性和多版本問題，在微軟的
    Windows上尤為突出
* JAR地獄（JAR hell）：JAR文件不同版本或路徑帶來的問題，通常是由于不懂類加載模
    型導(dǎo)致的

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

只有注冊用戶登錄后才能發(fā)表評論。
【推薦】100%開源！大型工業(yè)跨平臺軟件C++源碼提供，建模，組態(tài)！



網(wǎng)站導(dǎo)航: 博客園 IT新聞 BlogJava 博問 Chat2DB 管理

牽著老婆滿街逛

導(dǎo)航

統(tǒng)計(jì)

公告

常用鏈接

留言簿(11)

隨筆分類(466)

隨筆檔案(1513)

文章分類(46)

文章檔案(45)

相冊

收藏夾(39)

工具官網(wǎng)

技術(shù)網(wǎng)站

開源網(wǎng)站

其他窩點(diǎn)

收藏網(wǎng)站

銀行官網(wǎng)

友情鏈接

資源共享

搜索

積分與排名

最新評論

閱讀排行榜

反面模式（Anti-pattern）