最隐晦的程序设计指引(转)

转自:http://blog.csdn.net/nightmare/article/details/6629724

一、百家争鸣

    俗话说,程序员半年不学新东西,就变奥特曼(out man,过时之人)了。IT行业可以说是变化最快的行业,每年都有大量的新概念、新术语、新技术被创造出来,在多数人还在一头雾水时,“更好的”替代品又被创造出来。别的不说了,单说设计方法。

    想当年静态类型系统是王道,谁要是搞点运行时动态绑定、用点VB什么的,经常会被鄙视。而今动态类型语言大热,常有人高呼Python万岁,JavaScript身价百倍,C#也加入了动态类型支持。当年面向对象与过程式编程争吵不休,如今大家都在盯着函数式模式,C#和C++0x都加入了函数式语言特性。当我们学面向对象时,Gang of Four(据证实,这个书名确实是四人帮的英文翻译,故意调侃四位作者为坏家伙之意。)的设计模式流行起来了,当我们学Gang of Four时,其中一些模式被批为重复、过时、不宜的,一批表达新观点的书籍出版了(如Agile Modeling with Patterns)。当我们开始尝试敏捷方法时,模型驱动开发(Model Driven Development)遍布书刊封面和新闻头条,而当我们学用Rose、Visio画UML时,测试驱动开发(Test Driven Development)被提出来了。

    当然,历史的发展也常常会出人意料。人们曾经认为,动态的web必定需要Flash这样的新解决方案,而今HTML5+JavaScript不但可以取代Flash,还可以做3D应用。人们曾经认为,WebService需要一套新的行业标准,于是指定了SOAP等一系列协议,并历时数年时间开发了大量WebService平台和相关工具,而如今大家更喜欢基于基本的HTTP协议的REST方式和JavaScript本身的JSON数据协议,而且要简单高效得多。

    但究竟什么才是好的设计呢?如果静态类型系统才算好,那么大量优秀的动态类型语言程序算什么?如果面向对象才算好,那么大量优秀个过程式、函数式程序算什么?当年不知道匈牙利表示法的程序员就不是好coder,如今微软的态度是,别再提了。曾经OLE的程序员可以拿到高一倍的薪水,如今谁还会提OLE。Java阵营前些年喜欢嘲笑微软不懂Pattern,以致微软这些年有事没事地把Pattern挂在嘴边,但是如今被批评得一无是处的COM(1993)却是在Java诞生(1995)前就完美地实现了大多数的Java常用Pattern。既然COM被评价得这么烂,业界却搞出了一个和DCOM/COM+非常类似的CORBA。

    学过的人会说,低耦合、高内聚,如是等等。没错,这是一般原则,但也有情况下必须违背这些原则才是好的设计,典型的如性能优先的情况。再比如,一般原则有说状态查询和修改要分开,不要写在一个函数里,但是远程调用时却经常要合并,因为设计成网络往返通信两次不如一次解决。再比如,Java上有个著名的Spring Framework,可以利用反射功能,把程序中的动态选择性初始化问题转变成配置文件的设置,从而避免if语句(有个反if语句运动),Java程序员为此自豪。而同样的方法对主要用于桌面开发的.NET并不太适用,因为没有专业部署人员为桌面程序用户修改配置文件、填写正确的类名,而且桌面程序通常要做代码混淆(Obfuscation),会导致基于类名的反射失效。

    代码质量管理也是近些年的新热点,除了FxCop等传统检查分析工具外,计算复杂度的Cyclomatic Complexity方法和Test Coverage等量化分析得到了非常多的关注。这些工具对源码宏观分析提供了有效的手段。但分数高就代表代码质量一定高吗?尤其是对不懂技术的管理层,这些统计结果很容易成为财务报表一样的存在。

二、事有本末

    退一步想,当我们学自己的母语时,我们是先会说话还是先学语法呢?当我们学外语时,是先学说话还是先学语法呢?当我们读一首诗时,我们是先感觉到好还是先用各种规则去衡量它呢?当被要求说明哪里好时,是直接就说得出来还是要去借用各种规则来描述它的好?你是否隐约感觉到,有某种先于规则、方法存在的东西,但又难以言表,而必须用各种规则来间接地去描述它?

    有个春秋时期的故事,说齐桓公在堂上读书,工匠轮扁在堂下干活。轮扁问桓公说,敢问公读的什么书?桓公答,圣人之言。轮扁问,圣人还在吗?桓公答,已经死了。轮扁于是说,那么您读的就是古人的糟粕了。桓公大怒,说,寡人读书,轮得到你个车轮匠议论吗!说得出道理则罢,说不出就去死!轮扁答,用臣砍造车轮来说,慢了会甘滑而不牢固,快了会苦涩而难以敲入。唯有不快不慢,得于手而应于心。其中门道我也表达不出来,也无法传授给我儿子,所以如今七十岁了还在造轮子。圣人和他不可传的东西都已经消失了,那么您所读的,不就是剩下来的糟粕了吗?

    回到程序设计上,我们不断创造各种各样的方法、原则,到底是为了什么呢?当然是为了写出好程序。但到底什么是好?说不清。但可以肯定的是,都是为了好的性价比。性价比可以分成收益和代价。收益可以分成功能、性能、易用性、稳定性、安全性等等。代价可以分为开发时间成本、人力成本、可维护性等等。可维护性可以分为可读性、可扩展性、可复用性,如是等等,以指数级细化下去。然后有各种各样的方法,来解决各种具体的问题。如果开发时间不确定性大而却有严格的deadline,那么敏捷方法可以保证总是有个可用的发布版本,即使可能牺牲一些功能。如果代码只是短暂使用,或是被替代、重写的概率很大,那么可以完全不在乎可维护性,直接写抛弃型代码。如果代码面临高度频繁更改的可能性,那么用脚本语言吧。如果有个较大的开发团队,模型设计将有效提高交流沟通的效率。如果一个程序员在一个面向对象的系统中加入了一个处理算法,他的思路和实现都是过程式的,那么完全没必要把它改成面向对象的,因为那样只会增加额外的复杂度和理解困难,而且很难说日后算法修改后这个对象设计还能适用。如是等等。

    但是,因为这个精髓的东西难以说明,我们要么得在不断实践中慢慢领悟,要么学习别人总结出的方法来接近它。但是,人们经常纠结于方法本身。

    心都子讲过一个故事,说兄弟三人在齐鲁学儒术,学成回家,父亲问他们,仁义之道是什么?老大答,仁义使我爱身而后名。老二答,仁义使我杀身以成名。老三答,仁义使我身名并全。三个回答相反,却又同出于儒,谁是谁非?你纠结了吗?

    有句经常被引用的话:Any software problem can be solved by adding another layer of indirection. ——Steven M. Bellovin 其实原文后面还有半句:But that usually creates another problem.

    有个Java程序员写过一篇很有趣的blog。大意说,有个人要钉个钉子挂画框,于是去工具店买个锤子。店主说,No,我们已经不卖锤子了。锤子有很多种,大锤、拔钉锤、圆头锤等等,如果你买了一个,之后又发现你还需要另一个怎么办?多数人只想要一把锤子,所以我们推出了万能锤,可以当各种锤子使用。买者想想也是,那就买一把万能锤吧。店主说,No,万能锤已经被淘汰了。你想,万能锤虽然可以当各种锤子用,但它做什么活都没有专门用途的锤子好使。所以,我们开始卖锤子工厂,这样你可以随时制造最合适的锤子。买者说,但我并不想买个工厂……店主说,没错,所以它已经被淘汰了。我们研究发现,不是所有的用户都需要生产所有类型的锤子,所以我们开始卖锤子工厂设计图,这样用户可以根据自己的需要定制工厂。买者说,我猜这个也淘汰了吧?店主说,没错,我们研究发现,用户并不想自己建造一个工厂。于是我们推出了建造锤子工厂的工厂,来帮助用户建造锤子工厂……

三、殊途同归

    我们可以回想,在我们知道设计模式之前,难道我们就没有在用这些方法吗?之所以叫Pattern,就是因为它至少已经被重复运用三次以上,所以我们把它单独拿出来,赋予一个名字。所谓“新Pattern”就是一个悖论。Pattern的最大作用不是教人怎么做,因为面临同样问题时,大家多少会想出类似的解决方案;Pattern最大的作用,在于提供了一种共识、一套共通的术语,使开发人员间可以方便的交流一些复杂的系统概念。当然,有的人学了设计模式后会有眼前一亮的感觉,这是因为切身体验诸多问题的苦恼,突然得到解决之道,于是豁然开朗。而对有的人,没有体验过痛苦,只是听说Pattern是好的,于是就开始在代码里罗列Pattern。

    同理的,云计算是什么全新的东西吗?WebService是什么全新的东西吗?之前就没有类似的问题需要解决,就没有类似的解决方案吗?如果让你穿越到它们诞生前,从头解决这些分布式计算的问题,你会不会做出一个类似的解决方案?那么,又是什么使你能够发明这些新东西呢?是不是基本技能在特定问题下的一次应用呢?

    不管用哪种途径,用这套方法也好,那套方法也好,只靠自己琢磨也好,走对的话,都是通往同一条大道。不要把自己圈在一个小圈子里,圈子越小,越容易偏执。站得越高,看得越远,眼前的景色越壮丽,所谓的是非对错,不过是远处的一点而已。

    但是但是,现实中,不是所有的问题都是能由开发人员解决的,也不是所有的人都想要解决问题。流程、方法、思想、工具等,不管看起来再好,在不想解决问题的人面前,连个屁都不算。一个项目决定时的天时地利人和,已经八九成决定了项目的结局。当然,怨天尤人也没用,上天总是会给人几次机会的,机会到来时能不能抓得住,就看个人修为了。

posted @ 2011-07-27 15:13 你听海是不是在笑 阅读(...) 评论(...) 编辑 收藏