BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

动态语言企业应用优缺点浅析

| 作者 李明(nasi) 关注 0 他的粉丝 发布于 2010年7月6日. 估计阅读时间: 14 分钟 | QCon北京2018全面起航:开启与Netflix、微软、ThoughtWorks等公司的技术创新之路!

亲爱的读者:我们最近添加了一些个人消息定制功能,您只需选择感兴趣的技术主题,即可获取重要资讯的邮件和网页通知

动态语言的兴起已经有些年头了。现在,人们早已不再去争论动态语言是否能够取代静态语言,因为这种争论毫无意义。越来越多的开发者开始在动态语言更为擅长的领域应用它们。比如,DjangoRuby on Rails等开发框架的盛行使得像Python和Ruby这样的动态语言可以在Web开发领域大放异彩,PHP和JavaScript也早已在Web开发领域占有一席之地。

不过目前动态语言在企业开发中的应用还不够广泛,很多企业只是用它来做一些粘合系统的工作,并没有承担起主力开发语言的重任。尤其是在底层系统开发方面,动态语言远没有在Web开发方面那么风光。在运行时效率和虚拟机稳定性方面的不足,使得动态语言注定无法与编译型语言竞争,并取代它们在高性能领域的地位。然而,动态语言也有自己的优势所在。如何克服自己的劣势,将优势发扬光大,便是每一位动态语言开发者所面临的机遇和挑战。

我所在的团队用了近两年的时间,将一个电信领域的公司绝大部分的生产系统用动态语言(主要是Python)重写。包括短/彩信消息网关、业务订阅服务、座席查询系统、销售支撑系统,乃至搜索引擎等多个核心系统,都在重写之列。重写的理由很多,一方面原有系统无论是从性能上,还是从应对需求变化的能力上,都已经不能满足业务发展的需要;另外一方面,动态语言的诸多优势,也是我们重写的动力。这里仅以开发这些系统时获得的经验,来谈谈动态语言在应用时的优缺点。

动态语言的优势

动态语言的优势有很多,归纳起来主要有以下几个方面:

1. 生产力。动态语言在开发效率方面有着无与伦比的优势,这也与动态语言“优化人的时间而不是机器的时间”这个理念相吻合。利用传统的静态语言要开发几周的功能和特性,使用动态语言也许几天甚至几个小时就可以实现。不仅如此,动态语言在开发原型系统和常用工具方面的开发效率也非常高,尤其值得一提的是原型系统。更快地让原型系统运转起来,不仅可以尽早验证一些假设,也能够更好地与迭代开发相结合,更及时地与需求方进行沟通,帮助需求方挖掘和了解自己真正的需求。开发效率可以说是动态语言最为吸引人的地方,这也被认为是将来开发语言的前进方向。这些年随着敏捷开发的盛行,越来越多的开发者意识到,原来动态语言的特性和敏捷开发的价值观也相当契合:缩短反馈时间,对变化的响应能力更强。所以许多动态语言团队选择了敏捷开发的实践来组织团队。我们在实际开发的过程中,以两周为一个迭代周期,基本上1-2个迭代就可以完成一个系统的开发和上线,而原型系统的开发通常能在1-3天内完成。

2. 代码量。曾有报道说,用Ruby on Rails写同样的项目,代码量大概只有Java的1/10。且先不说这个说法是否有夸张的成分,但就实际来看,动态语言的确从代码量上来说,要比 Java/C/C++等传统静态编译型语言要少的多(当然语言的表达能力与动态静态关系并不大,静态函数式语言的表达能力也很强),可能几千行的项目就算得上是个大项目。例如,我们开发的系统中较为复杂的消息网关,生产代码行数大概在7000行左右;而订阅服务系统的生产代码行数不到3000行;借助于Xapian的 Python-bindings,我们的搜索引擎系统代码行数只有800行左右。代码量少的好处非常多:首先,这意味着将来需要花在维护上的代价更低;其次,因为代码少了,犯错误的机会也就少了,因此代码量少还意味着BUG的减少;再次,代码量的减少也有助于优化系统,有句话说的好,“There is no code faster than no code”。开源项目Nebula Device有一个设计哲学,就是“每一次Release要比前一次代码量更少”,窃以为高论也。

3. 测试。因为动态语言很容易实现反射等动态特性(JUnit也是等到Java支持了反射以后才出现的),因此测试也更为容易实现。Python和Ruby的标准库中都带有unittest的框架,这几乎可以让你无成本地使用单元测试来加固代码。因为动态语言本身不具有编译过程,因此犯下某些低级错误的几率大大增加,也为重构带来了重重困难。没有单元测试的重构如同梦魇一般,动态语言尤甚。因此,在开发语言以动态语言为主的开源项目中,单元测试总是占有相当大的比重。还有建议称测试代码与生产代码的比率(Unit Test To Code Ratio)要达到2:1以上。另外,动态语言的测试环境更容易搭建,实现Mock也更为简单。

4. 原生数据结构。现在主流的动态语言多为脚本语言发展而来,而在这些语言中,集合、列表和词典这样的数据结构都是原生的,而静态语言的数据结构往往是通过程序类库来实现的。比如Python就提供了set、tuple、list和dict等原生数据结构,同时还提供了大量操作(如数组分片等),让这些数据结构使用起来非常方便。原生数据结构使得对数据的操控融入到了语言的语法当中,让程序更为易读,这也让基于代码的沟通更为顺畅。

5. 简单易学。动态语言的语法相对简单,学习成本看似也比较低。有人举例说,Python和Ruby写个Hello World只需要一行即可,这是很多静态语言所达不到的(把多行代码写成一行的不算)。当然你可以认为这只不过是句玩笑话,不过单就语法而言,动态语言的学习门槛要比很多静态语言要低的多。可是,开发不仅仅只是语法而已。很多动态语言的初学者,能够用动态语言写一些简单的小程序小工具,却很难构建起庞大复杂的商业系统,究其原因,主要是还是因为系统设计和面向对象的功底欠缺所导致的。如何设计,如何抽象,如何重构,这些能力与语言无关,而是个人的修为。正如陆游所言,“功夫在诗外”,这些能力也不是一朝一夕、通过学学语言就能够轻易练就的。当然,动态语言的各种特性(如Duck Typing)也使得在静态语言中不得不使用的设计模式可以很自然地表达,这些差异也增加了动态语言学习的隐性成本。

不足之处

任何事物都具有两面性,动态语言也不例外,虽然优势显而易见,动态语言的不足之处也有很多。这里列举一些我们在开发过程中所遇到的问题,以及一些初步的解决方案,来供大家参考。

1. 运行效率。运行效率低下使得动态语言饱受诟病。“跑得太慢”这顶帽子已经在动态语言的头上扣了许多年。甚至有Benchmark表明,在某些应用场景下,动态语言的运行效率和C/C++、Java等成熟的静态语言相比,相差数十倍甚至上百倍,这也为动态语言的普及埋下阴影。不少开发者因为运行效率的问题,纷纷表示 “对动态语言很失望”。其实我倒是觉得大可不必纠结在这个问题上,原因有两点。第一,很多动态语言的应用场景使得运行效率的重要程度大大降低。就拿 Ruby on Rails来说,在Web开发这个应用场景里,数据库的响应时间无疑是最大时延,与之相比代码运行时间就微不足道了。而且通过Cache和优化,基本上可以消除代码运行效率低对项目的影响。又如我们的消息网关系统,最耗时的部分就是网络通信和文件I/O,而这两部分动态语言和静态语言相比并无明显劣势,运行效率的问题可以完全忽略。第二,如果遇到很耗CPU或者很耗内存的运算,完全可以通过C/C++实现的扩展来解决。无论是Python还是Ruby,都支持采用C/C++编写扩展。通过这些扩展,可以极大地提高运行效率,从而弥补动态语言在运行效率上的不足。

2. BUG难于发现。动态语言由于没有构建的过程,因此很多错误只有等到运行时才会发现。而这些错误很可能是些低级错误,比如拼写错误、没有import相关的类库,或者括号不匹配等等。如果每次修复这样的BUG都要通过去测试环境中部署来验证的话,则会浪费了大量时间。因此动态语言往往需要充分的自动化测试套件,才能够确保代码基本可用。另外,使用动态语言的时候,一个良好的代码静态检查工具也是很有必要的。它不但可以纠正一些低级错误,而且还可以帮助你发现代码中的Bad Smells,大大提高开发效率。对于Python来说,PyflakesPylint都是不错的选择;而Ruby也有众多工具可供使用。测试充分的代码也更容易重构,在重构动态语言项目时要万分小心,因为动态语言极容易犯错,稍不留意就会引入新的BUG。保持小步前进的步伐,每次修改后都执行测试,最好再通过持续集成环境来帮助发现测试失败的情况,这样重构起来才能得心应手。

3. 专业人员少。不少使用动态语言的公司都会遭遇一个问题,那就是使用动态语言的资深开发人员很少,不但很难招聘到靠谱的员工,核心人员的离队也会对公司造成很大的损失。这是因为完全使用动态语言进行开发的公司少的可怜,只有极少数的开发者能够参与其中并获得相关的开发经验。绝大多数的动态语言使用者还处在爱好者阶段,跟着Tutorials写写Demo,或者随手写个Utils等等。因为高水平的动态语言开发者的确是可遇不可求,因此寻找有经验的开发者也许要花上不少的时间和成本。当团队有了较为有经验的开发者以后,就需要通过内部培训、结对编程等手段,帮助公司里没有经验的开发者迅速积累经验,逐渐成为动态语言方面的靠谱人才。其实,对于动态语言的圈子,还有一个有趣的说法:因为学习动态语言的人往往都是在其他领域有了很深的积累后,在有余力的情况下才接触动态语言的,因此往往相对都比较靠谱,动态语言的圈子反而能够帮助雇主们甄选出一批高素质的开发者。

4. 不够成熟。动态语言的发展历史虽然不比静态语言差到哪里(比如Ruby和Java就同为1995年始创),然而由于其较为小众,因此无论是虚拟机的实现上,语言本身的机制上,还是相关的配套工具上都算不得十分成熟。例如,Ruby虽然以其优美灵活的语法为人所称道,但也因为其虚拟机效率低下和内存泄露问题所为人诟病,使用 Ruby on Rails的网站往往需要加配监控程序,一旦发现某个VM内存超标立刻重启;Python的虚拟机虽然还算稳定,但长久以来一直受GIL(Global Interpreter Lock)问题所困扰,完全无法发挥多核的优势,这在家用PC都早已多核的今天的确是个不小的问题(事实上Ruby也存在GIL问题)。不过,虽然官方实现不够成熟,现在已经有很多逐渐成熟的其他选择可供使用。比如JRuby就充分利用了Java成熟的虚拟机和Ruby优良的语法特性,还可以允许开发者使用Java背后庞大的类库。通过multiprocessingStackless Python,甚至手工将任务切成多份,分发给多个进程运行,都可以规避掉GIL的问题,更充分地利用系统性能。当然,随着时间的推移,动态语言的实现将会越来越成熟,不但MRI逐渐完善,MagLevRubinius等一系列优秀的Ruby虚拟机也开始登上舞台;Python 3000甚至打破了向后兼容性,试图将Python以前的设计错误全面改写。回头去看Java等一批成熟开发语言的发展路线,有谁没有经历过不成熟的青春期呢?

小结

通过实践我们发现,动态语言既不是什么洪水猛兽,也不是什么奇巧玩物,它们已经逐渐成长为称手的兵器,帮助开发者们快速完成项目,进而达成商业目标。使用动态语言,已经让我们切切实实感受到了它的开发效率为我们所带来的好处。在商业机会瞬息万变的今天,谁能以最快的速度实现自己的想法,谁能尽快应对市场带来的变化,谁就能离成功更进一步。

诚然,动态语言目前还存在很多问题。但瑕不掩瑜,如果在使用时可以意识到这些问题,并善加处理的话,动态语言也可以成为复杂商业系统的主角,在企业开发中占据自己的地位。而且随着开源社区的努力,很多问题正逐一被解决。我们有理由相信,在不远的未来,动态语言一定会有一片更为广阔的天空。

感谢田乐(Tin)和赖翥翔(Jason Lai)对本文提出了大量的反馈意见,感谢霍泰稳为本文找到如此贴切的标题。


给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家加入到InfoQ中文站用户讨论组中与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

有些地方不是很同意 by Jeffrey Zhao

1和2其实不是动态语言特有的优势吧,文章里虽然有提到,但是我认为说的不确切:静态函数式语言表达能力强,那么,动态命令式语言表达力强吗?其实表达能力很大程度就是看这个语言是否Declarative,而函数式语言这方面领先于命令式的。所以Python或是其他语言表达能力强,说实话也是沾了函数式的光。试想,早期的PHP没有闭包,没有匿名函数,它的生产力和表达能力如何呢?虽然它的确是动态语言。

说实话,静态语言的低生产力云云,是因为Java等语言过于光芒四射了,导致大家认为Java的优点就是静态语言的优点,Java的缺点也是静态语言的缺点。殊不知,静态语言也可以有闭包,也可以函数式编程。有了类型推断之后,绝大部分的类型信息是不需要的,Structural Typing也就类似于“类型安全”的Duck Typing,等等。事实上,很多情况下大部分的Python代码可以“一行一行”地改写成某些语言的静态代码。

当然,动态语言还是有不少优势的,比如要比元编程能力,还是动态语言强大很多。

Re: 有些地方不是很同意 by anemuko baka

骂够了Java,来骂Python和Ruby了?

Re: 有些地方不是很同意 by jia yong

请举证,"骂"是怎么体现的,无论是对java还是paython。

Re: 有些地方不是很同意 by Jeffrey Zhao

我骂过Python和Ruby了吗?再者Java是骂不够的啊,除非Scala抢下它30%的占有率,呵呵。

Re: 有些地方不是很同意 by anemuko baka

「坐議立談,無人能及,隨機應變,百無一能」

关于运行效率的一点考虑 by wang boris

我对于你关于运行效率的考虑有点想法,到底什么是运行效率?网络/数据库操作按你的说法,动态语言不是瓶颈,但你有没有考虑过同样的操作动态语言和静态语言所消耗的CPU资源,系统资源差多少呢?消耗的能源差异多少呢?换句话说,在整个系统并发很高的情况下,这里动态语言带来的能量消耗真的可以忽略不计么?
我对Java不爽的是,10几年前,运行JAVA的DEMO,CPU 占用律100%,10几年后运行同样的DEMO,是快了不少,但CPU占用率还是100%.

对于长期运行的大型系统,动态语言的带来的开发成本的节省,真的可以抵消掉运行成本的增加么?(我想GOOGLE对此会有深切体会)

RUBY社区也是这样的初衷,CPU会越来越快,但目前比较长期的趋势是,CPU越快,功耗越高。目前低炭是主旋律。

各大厂家纷纷拼性能拼速度(集中体现在浏览器),依仗硬件提高提高自己速度的大趋势,已经开始有些转变。

Re: 关于运行效率的一点考虑 by Nathan Li

关于运行成本的问题,Twitter 的做法可以借鉴,先用 Ruby on Rails 做出产品来,市场接受以后再用其他效率更高的语言替换掉其中慢的地方,在抢占市场和运行效率上取一个折衷

如果是对 CPU 消耗非常高的应用,可以用 C/C++ 来写扩展,Ruby 和 Python 都支持。另外,现在的 VM 效率也越来越高,也满符合低碳的主旋律嘛

新手求教 by Shichao Liu

我对动态语言很感兴趣, 刚开始学习没多久, 关于动态语言能大大减少代码行数不是很理解, 请问哪位大侠能给举个例子我学习一下呀?

Re: 新手求教 by Nathan Li

关于“动态语言代码量少”这个说法,其实也是相对而言的。这里也把这个论点当成是一个谬误,因为 Haskell 和 Lisp 的表达能力也很强。不过真正用这些语言构建的大型商用系统并不多见,而且一般来说采用 Ruby 和 Python 这类动态语言写成的系统,肯定要比 Java/C/C++ 这些主流静态语言要少得多。

究其原因,主要是因为像 Duck Typing 和 Meta-programming 这样的动态特性。就比如 Ruby on Rails 中通过 method_missing 来实现 find_by_xxx 查询,利用几行代码就能够提供各种查询接口,这个往往是静态语言所做不到的。

Re: 新手求教 by Jeffrey Zhao

基本同意你的看法,不过有一个小问题:LISP其实也是动态语言,呵呵。

Re: 新手求教 by Nathan Li

确实,不过国内很少有看到用 LISP 写成的系统。我的一个同事在美国公司里面的时候倒是写 LISP 的。

其实语言关于动态语言、动态特性和强/弱类型的分类的时候,很多情况下是不太容易区分的,比如 Objective-C 就不太容易分类。

所以在绞尽脑汁把某种语言放到某个篮子里之前,我们更倾向于去了解它的特性能为我们产生什么价值。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

11 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT