我認爲，沒有反模式，只有模式不徹底。
“
某人說：“軟件都不是一個人能寫出來的，我們需要去整體控制。”
他快要走了，那個影響我太多的人。
”
1. Cremational Patterns火葬模式 Creational patterns創建模式
下面是五個cremational patterns.
（1）Abject Poverty一貧如洗 Abstract Factory抽象工廠
Abject Poverty模式能讓你的軟件相當難測試和維護，並且需要巨大的財政支出，預算已經完全赤字。
（2）Blinder眼罩模式 Builder建造模式
Blinder 模式是一個應急有效的解決方案，其不需要考慮需求在未來的變化。目前，我們還不太清楚我們爲什麼叫Blinder模式，一種說法是他們會在寫代碼的時候被設計人員戴上眼罩，另一種說法是他們希望在維護代碼的時候挖出雙眼。
（3）Fallacy Method錯誤方法 Factory method工廠方法
Fallacy方法主要是在於處理一些不明顯的案例。代碼邏輯看上去是正確的，當只要某想要去測試一下，或是某個不明顯的案例發生了，那些代碼中的錯誤也就出現了。
（4）ProtoTry嘗試模式 Prototype原型模式
ProtoTry模式一個快速而骯髒的軟件開發工作模型的嘗試。這個模式的原意本來是想在後面有時間總結一下教訓並改進或重寫這些代碼，但是可惜的是沒有時間。所以，這些代碼也就成了衆所周知的 legacy code –舊代碼。
（5）Simpleton傻瓜模式 Singleton單例模式
Simpleton 模式，是把一個終極複雜的模式用於那些最最沒有價值的工作上。這個模式精確地指出了人員的能力程度。
2.Destructural Patterns無結構模式 Structural patterns 結構模式
下面是七個經典的變性模式
（1）Adopter領養者模式 Adapter適配器模式
Adopter模式提供了一個給那些“孤兒函數”的家。這這些函數和整個大家族別的函數看上去一點也不一樣，他們和整個家族的唯一聯繫就是通過我們的Adopter。
（2）Brig監獄模式 Bridge橋接模式
Brig 模式也就是那些壞代碼的容器類。這就是衆所周知的軟件模塊。
（3）Compromise妥協模式 Composite合成模式
Compromise 模式主要用來平衡軟件開發的工期和質量。使用這個模式的結果是——劣質的軟件+延誤的工期。
（4）Detonator地雷模式 Decorator修飾模式
Detonator 模式是極其普通的，在程序中放置一些不易查覺的地雷。一個常見的經典示例是隻用兩位數來表示年份。這個炸彈已經暴露出來了，並在那等着爆炸！（陳皓注：作者這裏說的是千年蟲問題，本文寫在1997年）
（5）Fromage乾酪模式 Facade外觀模式
Fromage 模式讓軟件看上去滿是漏洞。 Fromage 模式讓我們的軟件像Cheesy（芝士，也有劣質的意思）一樣，有大量的奇淫巧技讓你的軟件沒有任何一點可移值性。這個模式和奶酪一樣，越是老越是香啊。
（6）Flypaper捕蠅紙模式 Flyweight享元模式
Flypaper 模式的意思是，代碼是由設計的人完成，而由另一個人維護。維護着這個模式的那個寫代碼的人發現自己被粘住了，而且很有可能在軟件失支控制前夭折。
（7）ePoxy瀝清模式 Proxy代理模式
ePoxy模式主旨把軟件的模式緊密地耦合在一起。隨着耦合模塊的增加，我們就可以看到沾粘它們的瀝清。
3.Misbehavioral Patterns 行爲不檢模式 Behavioral Patterns 行爲模式
下面是11個行爲不檢點模式
（1）Chain of Possibilities可能性鏈模式 Chain of responsibility責任鏈模式
Chain of Possibilities 模式主旨是創造肥大的，拙劣文檔的軟件模塊。沒有人知道其功能有多寬泛，其可能性永無止境。也就是我們所說的——無確定性。
（2）Commando突擊隊模式 Command命令模式
Commando 模式主旨是用來應付工作，讓事情快點完成。這個模式不管封裝，只圖快快把代碼寫完。反正不犯法。
（3）Intersperser散佈模式 Interpreter解釋器模式
Intersperser 模式把一個功能的代碼散佈在系統的各個地方，其可以讓功能無法被測試，修改，以及讓人讀懂。(陳皓注：這讓我想起了以前VB，PB和Delphi的開發，功能的邏輯代碼散步在各個組件的不同事件中)
（4）Instigator煽動模式 Iterator迭代器模式
Instigator 模式看上去是良性的，但是其卻大規模的以暴力的方式在破壞軟件系統。（陳皓注：作者沒有做過多的解釋，不過，我想到了Windows編程革命史，應該說的就是這個吧）
（5）Momentum衝擊模式 Memento備忘模式
Momentum模式讓軟件大小，內存，CPU，和複雜度成極數級成長。（陳皓注：作者對此沒做過多解釋，這個特性很像Windows操作系統，每個Windows 的新版本，無論是在尺寸，內存和CPU要求上，和複雜度上都會比上一版有極數級的提高）
（6）Medicator用藥模式 Mediator媒介模式
Medicator 模式是一個實時的屠夫一樣，其把其它的系統搞得就像被打過強力鎮靜劑一樣沒有反應。
（7）Absolver免責模式 Observer觀察者模式
Absolver模式表現於那些被以前員工開發的代碼的問題。對於現任員工，其可以因爲很多代碼裏歷史上的問題而免除被批評，其聲稱其對軟件中的任何問題都不負責。這也是我們從所周知的——“這不是我的代碼”。（參看：程序員的藉口）
（8）Stake利害關係模式 State狀態模式
Stake模式表現於那些被現已成爲經理的人寫的代碼中的各種問題。雖然這些問題很不爽，但是經理們在這個軟件裏的利害關係太高了，所以，不能讓任何人重寫，因爲這代表着我們經理的技術成就。
（9）Eulogy頌歌模式 Strategy策略模式
Eulogy模式存在於所有的項目中，也就是 Post-Mortem(事後總結分析會)。
（10）Tempest Method 暴風雨模式 Template Method模板方法
Tempest Method 主要用在軟件快要發佈的最後幾天。這個模式的物徵是，代碼中沒有註釋，並有使用了好幾個Detonator Pattern 地雷模式。
（11）Visitor From Hell地獄訪問者模式 Visitor訪問者模式
Visitor From Hell模式一般是在運行時沒有檢查數組越界的一個巧合。這樣一來，我們系統就可以實現Visitor From Hell 模式，因爲這樣可以造成重要數據的重寫。