关于反模式(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.
在理论上,理论和实践之间没有什么差别;在实践中,二者截然不同。
参考:
http://www.murphys-laws.com/murphy/murphy-computer.html