关于反模式（Antipattern），也许知道它的唯一作用就是在实际开发中尽量避免出现反模式。百度百科里的主要介绍如下：
软件开发中公认的反模式
项目管理上的反模式
水中望月（Smoke and mirrors）：向人演示还没有实现的功能看上去会是什么样的。英文缘自一项魔术手法：放出烟雾并趁机用镜子遮住一件物体，使它看起来像是消失了。
软件膨胀：随着版本的升级，软件越来越消耗系统资源。
不良管理︰在未对主题有足够认识的情况下管理一个专案。
一般设计上的反模式
反抽象：需要的功能并不暴露给用户，导致用户要在较高层次重新实现一些功能。
四不像：往往一个设计模型可以暴露不同的接口给用户，不同的接口表现了模型的不同方面。然而把不同方面的功能混在一起是常见的不良设计。
乱麻球：系统没有可辨认的结构，就像一团乱麻一样。
万应灵：一个对象了解的东西太多，或者要做太多的事情，就好像无所不能一样。
屠龙术：没有必要的复杂设计。
竞争危害(Race Hazard): 缺乏预见事件以不同顺序发生的后果。
面向对象设计上的反模式
万能类︰在一个类的设计中，聚集了太多的函数。
吵闹鬼︰建立某对象的目的只是为了传送讯息给其它的物件。
溜溜问题︰因结构（例如继承）极度破碎冗长，而必须花费极大力气来了解它。
编程上的反模式
硬编码(Hard Code)：或称写死。在实现某系统用途上设死该系统的运作环境。
紊乱代码︰几乎无法理解的结构，特别是因为代码结构的滥用。
超布尔逻辑︰不必要的比较，或是过于抽象的布尔计算。
无用的例外处理︰插入了条件去防止运行时异常，但确在条件为false时又throw(例如：if A not null then process (A) else throw null-exception endif).
方法上的反模式
剪贴编程(Copy-n-paste programming)：宁愿拷贝(并修改)现存代码而非创造通用的解决方案。
反重构: "移除功能性并以注解取代"的过程。
金锤子: 假设个人偏好的解决方案是世界通用。
掩耳盗铃: 假设一个已知的bug不会出现。
不成熟的优化: 根据不足信息优化。
重新造个轮子: 拒绝采纳现有的解决方案，重写一个。
造了个正方形的轮子: 当一个优秀的方案存在时，创造一个蹩脚解决方案。
结构管理上的反模式
相依性地狱：由于需要的产品版本不匹配造成的种种问题，特别是在UNIX/Linux。
DLL地狱：由于动态连接库的版本、存在与否、和重复所造成的种种问题，特别是在Microsoft Windows。
JAR地狱：源自于不同版本或位址的JAR档案所造成的问题，常造成加载模组的欠缺。
延伸冲突︰源自于Mac OS不同的延伸尝试修补相同的系统部分。
一些组织方面的反模式
分析麻痹症：项目分析过程已经长得不成比例，却听之任之。
摇钱树项目：或者叫吃老本，一件有利可图的产品让新产品固步自封。
永远革命：总是要不停地不计代价将现有系统移植到新的环境。
军队式管理。没有容忍异议的空间。
Scope creep: 允许专案范围增长而没有适当控制
维基百科（中文）关于反模式的介绍相当之丰富，亮点层出不穷，不摘录了，感兴趣的可以点击链接去观摩观摩。看到面向对象设计的反面模式有个叫“又TMD来一层”直接笑抽了（不过仔细一想我tmd好像也没少干这种事情啊），而那个上帝对象好像也很眼熟。整理编写这些wiki的人估计没少受反模式的折磨，已经有点气急败坏了。
参考：http://baike.baidu.com/view/2825154.htm
http://zh.wikipedia.org/wiki/%E5%8F%8D%E6%A8%A1%E5%BC%8F
附：四舍五入和银行家舍入
四舍五入的规则大家应该非常熟悉，它的规则相对很简单，当舍去位的数值小于5时直接舍去该位；当舍去位的数值大于等于5时，在舍去该位的同时向前位进一。熟记一句口诀保你诸事无虞：“四则舍，五则添”。
银行家舍入规则比较复杂一些，摘录一段百度百科的介绍如下：
所谓银行家舍入法，其实质是一种四舍六入五取偶（又称四舍六入五留双）法。其规则是：当舍去位的数值小于5时，直接舍去该位；当舍去位的数值大于等于6时，在舍去该位的同时向前位进一；当舍去位的数值等于5时，如果前位数值为奇，则在舍去该位的同时向前位进一，如果前位数值为偶，则直接舍去该位。
简单的说，就是：四舍六入五考虑，五后非零就进一，五后为零看奇偶，五前为偶应舍去，五前为奇要进一
上面斜体文字来源：http://baike.baidu.com/view/3058685.htm
1、C#中的四舍五入
开发中我们所熟知的Math.Round常用的一个重载方法默认实现的是银行家舍入法，验证代码如下：
Math.Round
对于负数的处理如下：
Math.Round
如何实现我们熟悉的那种四舍五入呢？
Math.Round有一个三个数的重置方法，其中第三个参数mode对应MidpointRounding枚举，该枚举如下：
MidpointRounding
下面的写法可以验证就是我们所期望的四舍五入：
Math.Round
PS：在Math类中还有两个经常用来处理小数取整的函数Floor和Ceiling。通常我们记住Floor（地板）和Ceiling（天花板）的含义就知道这两个函数的作用了。
2、Python中的四舍五入
python2.6及之前版本中的round默认进行的四舍五入处理比较奇怪：
round
而且上述写法可能还因Python2.6之前的版本不同而有差异。这里我们可以肯定的是Python2.6的round函数的四舍五入规则不是银行家舍入，也不是我们常见的四舍五入。有些文章里说Python的四舍五入可以通过字符串格式化的方式处理，结果虽然是出来了，可是总感觉没有从根本上解决问题，有点玩弄trick的意思。
好在Python2.7及之后版本已经修正了这个问题，直接使用round函数即可。
3、JavaScript中的四舍五入
同理，我们在javascript中处理四舍五入，也可通过Math.round函数，只不过这个函数的定义是“Round a number to the nearest integer”，而且没有第二个舍入的精度参数值：
Math.round(2.5); //3 Math.round(-2.50); //-2 Math.round(-2.51); //-3
看上去这个函数对于四舍五入成指定位数的小数，似乎无能为力了。我们完全可以自己写一个处理函数，和C#里的方法比较类似：
PowerRound
这个函数对于正负数都可以进行四舍五入处理：
PowerRoundOutput
总结：我们做的一些应用系统，涉及订单和财务数据之类处理的时候经常要和四舍五入打交道，而实际开发过程中，不论后台业务逻辑还是前台UI展现，总会有一些数据的处理并不理想，在你维护的项目中不断出现布满陷阱的Convert.ToXXX进行强制转换会不会让你也产生不好的情绪？也许只有在对账的时候才能理解小数点后面那几位处理的重要性了。
附：墨菲法则
在墨菲法则的计算机和技术分类里看到不少耳熟能详的句子，感觉似乎很久以前在哪里看过，相当有趣好玩，比如下面两条总结计算机软件开发的法则：
Program complexity grows until it exceeds the capability of the programmer who must maintain it.
程序的复杂性会一直增加，直到负责维护的程序员力不从心痛苦的无以复加不能继续为止。
注：我这里的翻译好像有点夸张，实际情况一点也不夸张，要不你也来维护几千行脚本试试？
Adding manpower to a late software project makes it later.
为一个赶不上进度的软件项目增加人手只能让其更加落后于进度。
在技术中的法则也相当经典，比如：
if it works in theory, it won't work in practice.if it works in practice it won't work in theory.
理论中可行，实践中不行；实践中可行，理论中不行。
还看到一句，在我看来和上面那句意思差不多：
In theory there is no difference between theory and practice, but in practice there is.
在理论上，理论和实践之间没有什么差别；在实践中，二者截然不同。
本文转自JeffWong博客园博客，原文链接：http://www.cnblogs.com/jeffwongishandsome/archive/2012/07/15/2592745.html，如需转载请自行联系原作者
