動態(tài)語言的興起已經(jīng)有些年頭了?，F(xiàn)在,，人們早已不再去爭論動態(tài)語言是否能夠取代靜態(tài)語言，因為這種爭論毫無意義,。越來越多的開發(fā)者開始在動態(tài)語言更為擅長的領(lǐng)域應(yīng)用它們,。比如，Django和Ruby on Rails等開發(fā)框架的盛行使得像Python和Ruby這樣的動態(tài)語言可以在Web開發(fā)領(lǐng)域大放異彩,，PHP和JavaScript也早已在Web開發(fā)領(lǐng)域占有一席之地,。

不過目前動態(tài)語言在企業(yè)開發(fā)中的應(yīng)用還不夠廣泛，很多企業(yè)只是用它來做一些粘合系統(tǒng)的工作,，并沒有承擔起主力開發(fā)語言的重任,。尤其是在底層系統(tǒng)開發(fā)方面，動態(tài)語言遠沒有在Web開發(fā)方面那么風光,。在運行時效率和虛擬機穩(wěn)定性方面的不足,，使得動態(tài)語言注定無法與編譯型語言競爭，并取代它們在高性能領(lǐng)域的地位,。然而,，動態(tài)語言也有自己的優(yōu)勢所在。如何克服自己的劣勢,，將優(yōu)勢發(fā)揚光大,，便是每一位動態(tài)語言開發(fā)者所面臨的機遇和挑戰(zhàn)。

我所在的團隊用了近兩年的時間,，將一個電信領(lǐng)域的公司絕大部分的生產(chǎn)系統(tǒng)用動態(tài)語言（主要是Python）重寫,。包括短/彩信消息網(wǎng)關(guān)、業(yè)務(wù)訂閱服務(wù),、座席查詢系統(tǒng),、銷售支撐系統(tǒng)，乃至搜索引擎等多個核心系統(tǒng),，都在重寫之列,。重寫的理由很多，一方面原有系統(tǒng)無論是從性能上，還是從應(yīng)對需求變化的能力上,，都已經(jīng)不能滿足業(yè)務(wù)發(fā)展的需要,；另外一方面，動態(tài)語言的諸多優(yōu)勢,，也是我們重寫的動力,。這里僅以開發(fā)這些系統(tǒng)時獲得的經(jīng)驗，來談?wù)剟討B(tài)語言在應(yīng)用時的優(yōu)缺點,。

相關(guān)廠商內(nèi)容

證明你! 是! 極! 客! 紅顏草莓禮盒送你手中

iOS地圖SDK支持大地曲線,、虛線，全面升級地圖覆蓋物,！

Android地圖SDK開放openGL接口,，定位圖標360度旋轉(zhuǎn)

深入淺出Symfony2 結(jié)合MongoDB開發(fā)LBS應(yīng)用

Android定位SDK將自動判斷使用網(wǎng)絡(luò)或 GPS 定位

相關(guān)贊助商

高德地圖lbs專區(qū)，驚爆內(nèi)容精彩呈現(xiàn),！

動態(tài)語言的優(yōu)勢

動態(tài)語言的優(yōu)勢有很多,，歸納起來主要有以下幾個方面：

1. 生產(chǎn)力。動態(tài)語言在開發(fā)效率方面有著無與倫比的優(yōu)勢,，這也與動態(tài)語言“優(yōu)化人的時間而不是機器的時間”這個理念相吻合,。利用傳統(tǒng)的靜態(tài)語言要開發(fā)幾周的功能和特性，使用動態(tài)語言也許幾天甚至幾個小時就可以實現(xiàn),。不僅如此,，動態(tài)語言在開發(fā)原型系統(tǒng)和常用工具方面的開發(fā)效率也非常高，尤其值得一提的是原型系統(tǒng),。更快地讓原型系統(tǒng)運轉(zhuǎn)起來,，不僅可以盡早驗證一些假設(shè)，也能夠更好地與迭代開發(fā)相結(jié)合,，更及時地與需求方進行溝通,，幫助需求方挖掘和了解自己真正的需求。開發(fā)效率可以說是動態(tài)語言最為吸引人的地方,，這也被認為是將來開發(fā)語言的前進方向,。這些年隨著敏捷開發(fā)的盛行，越來越多的開發(fā)者意識到,，原來動態(tài)語言的特性和敏捷開發(fā)的價值觀也相當契合：縮短反饋時間,，對變化的響應(yīng)能力更強。所以許多動態(tài)語言團隊選擇了敏捷開發(fā)的實踐來組織團隊,。我們在實際開發(fā)的過程中，以兩周為一個迭代周期,，基本上1-2個迭代就可以完成一個系統(tǒng)的開發(fā)和上線,，而原型系統(tǒng)的開發(fā)通常能在1-3天內(nèi)完成。

2. 代碼量。曾有報道說,，用Ruby on Rails寫同樣的項目,，代碼量大概只有Java的1/10。且先不說這個說法是否有夸張的成分,，但就實際來看,，動態(tài)語言的確從代碼量上來說，要比 Java/C/C++等傳統(tǒng)靜態(tài)編譯型語言要少的多（當然語言的表達能力與動態(tài)靜態(tài)關(guān)系并不大,，靜態(tài)函數(shù)式語言的表達能力也很強）,，可能幾千行的項目就算得上是個大項目。例如,，我們開發(fā)的系統(tǒng)中較為復(fù)雜的消息網(wǎng)關(guān),，生產(chǎn)代碼行數(shù)大概在7000行左右；而訂閱服務(wù)系統(tǒng)的生產(chǎn)代碼行數(shù)不到3000行,；借助于Xapian的 Python-bindings,，我們的搜索引擎系統(tǒng)代碼行數(shù)只有800行左右。代碼量少的好處非常多：首先,，這意味著將來需要花在維護上的代價更低,；其次，因為代碼少了,，犯錯誤的機會也就少了,，因此代碼量少還意味著BUG的減少；再次,，代碼量的減少也有助于優(yōu)化系統(tǒng),，有句話說的好，“There is no code faster than no code”,。開源項目Nebula Device有一個設(shè)計哲學(xué),，就是“每一次Release要比前一次代碼量更少”，竊以為高論也,。

3. 測試,。因為動態(tài)語言很容易實現(xiàn)反射等動態(tài)特性（JUnit也是等到Java支持了反射以后才出現(xiàn)的），因此測試也更為容易實現(xiàn),。Python和Ruby的標準庫中都帶有unittest的框架,，這幾乎可以讓你無成本地使用單元測試來加固代碼。因為動態(tài)語言本身不具有編譯過程,，因此犯下某些低級錯誤的幾率大大增加,，也為重構(gòu)帶來了重重困難。沒有單元測試的重構(gòu)如同夢魘一般,，動態(tài)語言尤甚,。因此，在開發(fā)語言以動態(tài)語言為主的開源項目中，單元測試總是占有相當大的比重,。還有建議稱測試代碼與生產(chǎn)代碼的比率（Unit Test To Code Ratio）要達到2:1以上,。另外，動態(tài)語言的測試環(huán)境更容易搭建,，實現(xiàn)Mock也更為簡單,。

4. 原生數(shù)據(jù)結(jié)構(gòu)。現(xiàn)在主流的動態(tài)語言多為腳本語言發(fā)展而來,，而在這些語言中,，集合、列表和詞典這樣的數(shù)據(jù)結(jié)構(gòu)都是原生的,，而靜態(tài)語言的數(shù)據(jù)結(jié)構(gòu)往往是通過程序類庫來實現(xiàn)的,。比如Python就提供了set、tuple,、list和dict等原生數(shù)據(jù)結(jié)構(gòu),，同時還提供了大量操作（如數(shù)組分片等），讓這些數(shù)據(jù)結(jié)構(gòu)使用起來非常方便,。原生數(shù)據(jù)結(jié)構(gòu)使得對數(shù)據(jù)的操控融入到了語言的語法當中,，讓程序更為易讀，這也讓基于代碼的溝通更為順暢,。

5. 簡單易學(xué),。動態(tài)語言的語法相對簡單，學(xué)習成本看似也比較低,。有人舉例說,，Python和Ruby寫個Hello World只需要一行即可，這是很多靜態(tài)語言所達不到的（把多行代碼寫成一行的不算）,。當然你可以認為這只不過是句玩笑話,，不過單就語法而言，動態(tài)語言的學(xué)習門檻要比很多靜態(tài)語言要低的多,?？墒牵_發(fā)不僅僅只是語法而已,。很多動態(tài)語言的初學(xué)者,，能夠用動態(tài)語言寫一些簡單的小程序小工具，卻很難構(gòu)建起龐大復(fù)雜的商業(yè)系統(tǒng),，究其原因,，主要是還是因為系統(tǒng)設(shè)計和面向?qū)ο蟮墓Φ浊啡彼鶎?dǎo)致的。如何設(shè)計,，如何抽象,，如何重構(gòu),，這些能力與語言無關(guān)，而是個人的修為,。正如陸游所言，“功夫在詩外”,，這些能力也不是一朝一夕,、通過學(xué)學(xué)語言就能夠輕易練就的。當然,，動態(tài)語言的各種特性（如Duck Typing）也使得在靜態(tài)語言中不得不使用的設(shè)計模式可以很自然地表達,，這些差異也增加了動態(tài)語言學(xué)習的隱性成本。

不足之處

任何事物都具有兩面性,，動態(tài)語言也不例外,，雖然優(yōu)勢顯而易見，動態(tài)語言的不足之處也有很多,。這里列舉一些我們在開發(fā)過程中所遇到的問題,，以及一些初步的解決方案，來供大家參考,。

1. 運行效率,。運行效率低下使得動態(tài)語言飽受詬病?！芭艿锰边@頂帽子已經(jīng)在動態(tài)語言的頭上扣了許多年,。甚至有Benchmark表明，在某些應(yīng)用場景下,，動態(tài)語言的運行效率和C/C++,、Java等成熟的靜態(tài)語言相比，相差數(shù)十倍甚至上百倍,，這也為動態(tài)語言的普及埋下陰影,。不少開發(fā)者因為運行效率的問題，紛紛表示 “對動態(tài)語言很失望”,。其實我倒是覺得大可不必糾結(jié)在這個問題上,，原因有兩點。第一,，很多動態(tài)語言的應(yīng)用場景使得運行效率的重要程度大大降低,。就拿 Ruby on Rails來說，在Web開發(fā)這個應(yīng)用場景里,，數(shù)據(jù)庫的響應(yīng)時間無疑是最大時延,，與之相比代碼運行時間就微不足道了。而且通過Cache和優(yōu)化,，基本上可以消除代碼運行效率低對項目的影響,。又如我們的消息網(wǎng)關(guān)系統(tǒng),，最耗時的部分就是網(wǎng)絡(luò)通信和文件I/O，而這兩部分動態(tài)語言和靜態(tài)語言相比并無明顯劣勢,，運行效率的問題可以完全忽略,。第二，如果遇到很耗CPU或者很耗內(nèi)存的運算,，完全可以通過C/C++實現(xiàn)的擴展來解決,。無論是Python還是Ruby，都支持采用C/C++編寫擴展,。通過這些擴展,，可以極大地提高運行效率，從而彌補動態(tài)語言在運行效率上的不足,。

2. BUG難于發(fā)現(xiàn),。動態(tài)語言由于沒有構(gòu)建的過程，因此很多錯誤只有等到運行時才會發(fā)現(xiàn),。而這些錯誤很可能是些低級錯誤,，比如拼寫錯誤、沒有import相關(guān)的類庫,，或者括號不匹配等等,。如果每次修復(fù)這樣的BUG都要通過去測試環(huán)境中部署來驗證的話，則會浪費了大量時間,。因此動態(tài)語言往往需要充分的自動化測試套件,，才能夠確保代碼基本可用。另外,，使用動態(tài)語言的時候,，一個良好的代碼靜態(tài)檢查工具也是很有必要的。它不但可以糾正一些低級錯誤,，而且還可以幫助你發(fā)現(xiàn)代碼中的Bad Smells,，大大提高開發(fā)效率。對于Python來說,，Pyflakes或Pylint都是不錯的選擇,；而Ruby也有眾多工具可供使用。測試充分的代碼也更容易重構(gòu),，在重構(gòu)動態(tài)語言項目時要萬分小心,，因為動態(tài)語言極容易犯錯，稍不留意就會引入新的BUG,。保持小步前進的步伐,，每次修改后都執(zhí)行測試，最好再通過持續(xù)集成環(huán)境來幫助發(fā)現(xiàn)測試失敗的情況,，這樣重構(gòu)起來才能得心應(yīng)手,。

3. 專業(yè)人員少,。不少使用動態(tài)語言的公司都會遭遇一個問題，那就是使用動態(tài)語言的資深開發(fā)人員很少,，不但很難招聘到靠譜的員工,，核心人員的離隊也會對公司造成很大的損失。這是因為完全使用動態(tài)語言進行開發(fā)的公司少的可憐,，只有極少數(shù)的開發(fā)者能夠參與其中并獲得相關(guān)的開發(fā)經(jīng)驗,。絕大多數(shù)的動態(tài)語言使用者還處在愛好者階段，跟著Tutorials寫寫Demo,，或者隨手寫個Utils等等。因為高水平的動態(tài)語言開發(fā)者的確是可遇不可求,，因此尋找有經(jīng)驗的開發(fā)者也許要花上不少的時間和成本,。當團隊有了較為有經(jīng)驗的開發(fā)者以后，就需要通過內(nèi)部培訓(xùn),、結(jié)對編程等手段,，幫助公司里沒有經(jīng)驗的開發(fā)者迅速積累經(jīng)驗，逐漸成為動態(tài)語言方面的靠譜人才,。其實,，對于動態(tài)語言的圈子，還有一個有趣的說法：因為學(xué)習動態(tài)語言的人往往都是在其他領(lǐng)域有了很深的積累后,，在有余力的情況下才接觸動態(tài)語言的,，因此往往相對都比較靠譜，動態(tài)語言的圈子反而能夠幫助雇主們甄選出一批高素質(zhì)的開發(fā)者,。

4. 不夠成熟,。動態(tài)語言的發(fā)展歷史雖然不比靜態(tài)語言差到哪里（比如Ruby和Java就同為1995年始創(chuàng)），然而由于其較為小眾,，因此無論是虛擬機的實現(xiàn)上,，語言本身的機制上，還是相關(guān)的配套工具上都算不得十分成熟,。例如,，Ruby雖然以其優(yōu)美靈活的語法為人所稱道，但也因為其虛擬機效率低下和內(nèi)存泄露問題所為人詬病,，使用 Ruby on Rails的網(wǎng)站往往需要加配監(jiān)控程序,，一旦發(fā)現(xiàn)某個VM內(nèi)存超標立刻重啟；Python的虛擬機雖然還算穩(wěn)定,，但長久以來一直受GIL（Global Interpreter Lock）問題所困擾,，完全無法發(fā)揮多核的優(yōu)勢，這在家用PC都早已多核的今天的確是個不小的問題（事實上Ruby也存在GIL問題）,。不過,，雖然官方實現(xiàn)不夠成熟,，現(xiàn)在已經(jīng)有很多逐漸成熟的其他選擇可供使用。比如JRuby就充分利用了Java成熟的虛擬機和Ruby優(yōu)良的語法特性,，還可以允許開發(fā)者使用Java背后龐大的類庫,。通過multiprocessing或Stackless Python，甚至手工將任務(wù)切成多份,，分發(fā)給多個進程運行,，都可以規(guī)避掉GIL的問題，更充分地利用系統(tǒng)性能,。當然,，隨著時間的推移，動態(tài)語言的實現(xiàn)將會越來越成熟,，不但MRI逐漸完善,，MagLev和Rubinius等一系列優(yōu)秀的Ruby虛擬機也開始登上舞臺；Python 3000甚至打破了向后兼容性,，試圖將Python以前的設(shè)計錯誤全面改寫,。回頭去看Java等一批成熟開發(fā)語言的發(fā)展路線,，有誰沒有經(jīng)歷過不成熟的青春期呢,？

小結(jié)

通過實踐我們發(fā)現(xiàn)，動態(tài)語言既不是什么洪水猛獸,，也不是什么奇巧玩物,，它們已經(jīng)逐漸成長為稱手的兵器，幫助開發(fā)者們快速完成項目,，進而達成商業(yè)目標,。使用動態(tài)語言，已經(jīng)讓我們切切實實感受到了它的開發(fā)效率為我們所帶來的好處,。在商業(yè)機會瞬息萬變的今天,，誰能以最快的速度實現(xiàn)自己的想法，誰能盡快應(yīng)對市場帶來的變化,，誰就能離成功更進一步,。

誠然，動態(tài)語言目前還存在很多問題,。但瑕不掩瑜,，如果在使用時可以意識到這些問題，并善加處理的話,，動態(tài)語言也可以成為復(fù)雜商業(yè)系統(tǒng)的主角,，在企業(yè)開發(fā)中占據(jù)自己的地位。而且隨著開源社區(qū)的努力,，很多問題正逐一被解決,。我們有理由相信,，在不遠的未來，動態(tài)語言一定會有一片更為廣闊的天空,。

感謝田樂（Tin）和賴翥翔（Jason Lai）對本文提出了大量的反饋意見,，感謝霍泰穩(wěn)為本文找到如此貼切的標題。

給InfoQ中文站投稿或者參與內(nèi)容翻譯工作,，請郵件至editors@cn.,。也歡迎大家加入到InfoQ中文站用戶討論組中與我們的編輯和其他讀者朋友交流。