反模式
维基百科，自由的百科全书
反模式（英文：Anti-patterns或pitfalls）, 是指用来解决问题的带有共同性的不良方法。它们已经经过研究并分类，以防止日后重蹈覆辙，并能在研发尚未投产的系统时辨认出来。
这个术语始自计算机科学的研究，似乎是受到了G4的《设计模式》一书的影响，该书主要内容是阐述一些良好的编程实践。其作者仿照建筑学中的设计模式一词，采用了“设计模式”这个术语来表示这些好方法。在Brown、Malveau、McCormick和Mowbray合著的这本书中描述了一些与“反模式”对应的设计模式，尽管原作并未提及这个术语。其中一些模式正是为了避免某些反模式而设计的。
很容易把这个概念推广到工程学以及工程以外需要人们付出努力去争取的领域。尽管在工程学以外很少用到这个术语，但其概念是通用的。
目录 |
[编辑] 软件开发中一些已被辨认的反模式=
更完整的列表，请参照Category:反模式
[编辑] 项目管理反模式
- 水中望月（Smoke and mirrors）：向人演示还没有实现的功能看上去会是什么样的。英文缘自一项魔术手法：放出烟雾并趁机用镜子遮住一件物体，使它看起来像是消失了。
- 软件膨胀：随着版本的升级，软件越来越消耗系统资源。
[编辑] 设计反模式
- 反抽象：需要的功能并不暴露给用户，导致用户要在较高层次重新实现一些功能。
- 四不像：往往一个设计模型可以暴露不同的接口给用户，不同的接口表现了模型的不同方面。然而把不同方面的功能混在一起是常见的不良设计。
- 乱麻球：系统没有可辨认的结构，就像一团乱麻一样。
- 万应灵：一个对象了解的东西太多，或者要做太多的东西，就好像无所不能一样。
- 屠龙术：没有必要的复杂设计。
- Input kludge: Failing to specify and implement handling of possibly invalid input
- Interface bloat: Making an interface so powerful that it is too hard to implement
- Magic pushbutton: Implementing the results of user actions in terms of an inappropriate (insufficiently abstract) interface
- Re-Coupling: Introducing unnecessary object dependency
- Stovepipe system: A barely maintainable assemblage of ill-related components
- 競爭危害(Race Hazard): 缺乏預見事件以不同順序發生的後果。
[编辑] 面向对象设计的反模式
- BaseBean: Inheriting functionality from a utility class rather than delegating to it
- Empty subclass failure: Creating a (Perl) class that fails the "Empty Subclass Test" by behaving differently from a class derived from it without modifications
- God object: Concentrating too many functions in a single part of the design (class)
- Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
- Poltergeists: Objects whose sole purpose is to pass information to another object
- Yo-yo problem: A structure (e.g. of inheritance) that is hard to understand due to excessive fragmentation
[编辑] 编程反模式
- Accidental complexity: Introducing unnecessary complexity into a solution
- Action at a distance: Unexpected interaction between widely separated parts of a system
- Accumulate and fire: Setting parameters for subroutines in a collection of global variables
- Arcanum: Using a cryptic naming scheme for functions and variables (usually based on abbreviatures) instead of self-descriptive names
- Blind faith: Lack of checking of (a) the correctness of a bug fix or (b) the result of a subroutine
- Boat anchor: Retaining a part of a system that no longer has any use
- Busy spin: Consuming CPU while waiting for something to happen, usually by repeated checking instead of proper messaging
- Caching failure: Forgetting to reset an error flag when an error has been corrected
- Checking type instead of interface: Checking that an object has a specific type when only a certain contract is required
- Code momentum: Over-constraining part of a system by repeatedly assuming things about it in other parts
- Coding by exception: Adding new code to handle each special case as it is recognised
- Double-checked locking: Checking, before locking, if this is necessary in a way which may fail with e.g. modern hardware or compilers.
- 硬編碼(Hard Code)：或稱寫死。在實現某系統用途上設死該系統的運作環境。
- Lava flow: Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences
- Magic numbers: Including unexplained numbers in algorithms
- Procedural code (when another paradigm is more appropriate)
- Spaghetti code: Systems whose structure is barely comprehensible, especially because of misuse of code structures
[编辑] 方法论反模式
- 剪貼編程(Copy-n-paste programming)：寧願拷貝(並修改)現存代碼而非創造通用的解決方案。
- De-Factoring: 「移除功能性並以註解取代」的過程。
- Golden hammer: 假設個人偏好的解決方案是世界通用。
- Improbability factor: Assuming that it is improbable that a known error becomes effective
- Premature optimization: 根據不足資訊優化
- Reinventing the wheel: 拒絕採納現有的解決方案，重寫一個。
- Reinventing the square wheel: 當一個優秀的方案存在時，創造一個蹩腳解決方案。
[编辑] 配置管理反模式
- 依赖性地狱：在UNIX/Linux里，由于需要的产品版本不匹配造成的种种问题。
- DLL地狱：在Microsoft Windows里面，由于动态连接库的版本、存在性、和重复造成的种种问题。
[编辑] 一些组织方面的反模式
- 分析麻痹症：项目分析过程已经长得不成比例，却听之任之。
- 摇钱树项目：或者叫吃老本，一件有利可图的产品让新产品固步自封。
- 永远革命：总是要不停地不计代价将现有系统移植到新的环境。
- Creeping featurism: Adding new features to the detriment of the quality of a system
- Design by committee: The result of having many contributors to a design, but no unifying vision
- Escalation of commitment: Failing to revoke a decision when it proves wrong
- I told you so: When the ignored warning of an expert proves justified
- Management by numbers: Paying excessive attention to quantitative management criteria, when these are inessential or cost too much to acquire
- Management by perkele: 軍隊式管理。沒有容忍異議的空間。
- Mushroom management: Keeping employees uninformed and abused
- Scope creep: 允許專案範圍增長而沒有適當控制
- Vendor lock-in: Making a system excessively dependent on an externally supplied component
- Warm body: A person whose contribution to a project is in doubt, especially if taken on in panic
- Single head of knowledge: SHOK applies when a single individual in the entire organization controls vital domain know-how or information on system internals.
- Knight in shining armor: KISA happens when an individual who can do no wrong shows up on the scene and tries to fix everything without communicating what changes he/she has/will make and why.
[编辑] 参见
- 代码味道
[编辑] 资料来源
- 英文维基条目
- Perl 设计模式 — 一部自由的在线图书。
- Brown, William J.; Raphael C. Malveau、Hays W. McCormick III及Thomas J. Mowbray (1998). 反模式：软件重构、架构及项目危机, John Wiley & Sons. ISBN 0471197130.
