Python等動(dòng)態(tài)語(yǔ)言企業(yè)應(yīng)用面面觀
動(dòng)態(tài)語(yǔ)言的興起已經(jīng)有些年頭了，現(xiàn)在，人們?cè)缫巡辉偃?zhēng)論動(dòng)態(tài)語(yǔ)言是否能夠取代靜態(tài)語(yǔ)言，因?yàn)檫@種爭(zhēng)論毫無意義。越來越多的開發(fā)者開始在動(dòng)態(tài)語(yǔ)言更為擅長(zhǎng)的領(lǐng)域應(yīng)用它們。
Django和Ruby on Rails等開發(fā)框架的盛行使得像Python和Ruby這樣的動(dòng)態(tài)語(yǔ)言可以在Web開發(fā)領(lǐng)域大放異彩，PHP和JavaScript也早已在Web開發(fā)領(lǐng)域占有一席之地。（相關(guān)文章推薦：動(dòng)態(tài)語(yǔ)言，別再輕言不）
不過目前動(dòng)態(tài)語(yǔ)言在企業(yè)開發(fā)中的應(yīng)用還不夠廣泛，并沒有承擔(dān)起主力開發(fā)語(yǔ)言的重任。尤其是在底層系統(tǒng)開發(fā)方面，動(dòng)態(tài)語(yǔ)言遠(yuǎn)沒有在Web開發(fā)方面那么風(fēng)光。
在運(yùn)行時(shí)效率和虛擬機(jī)穩(wěn)定性方面的不足，使得動(dòng)態(tài)語(yǔ)言注定無法與編譯型語(yǔ)言競(jìng)爭(zhēng)，并取代它們?cè)诟咝阅茴I(lǐng)域的地位。然而，動(dòng)態(tài)語(yǔ)言也有自己的優(yōu)勢(shì)所在。如何克服自己的劣勢(shì)，將優(yōu)勢(shì)發(fā)揚(yáng)光大，便是每一位動(dòng)態(tài)語(yǔ)言開發(fā)者所面臨的機(jī)遇和挑戰(zhàn)。
動(dòng)態(tài)語(yǔ)言的優(yōu)勢(shì)
動(dòng)態(tài)語(yǔ)言的優(yōu)勢(shì)有很多，歸納起來主要有以下幾個(gè)方面：
1. 生產(chǎn)力。動(dòng)態(tài)語(yǔ)言在開發(fā)效率方面有著無與倫比的優(yōu)勢(shì)，這也與動(dòng)態(tài)語(yǔ)言“優(yōu)化人的時(shí)間而不是機(jī)器的時(shí)間”這個(gè)理念相吻合。利用傳統(tǒng)的靜態(tài)語(yǔ)言要開發(fā)幾周的功能和特性，使用動(dòng)態(tài)語(yǔ)言也許幾天甚至幾個(gè)小時(shí)就可以實(shí)現(xiàn)。不僅如此，動(dòng)態(tài)語(yǔ)言在開發(fā)原型系統(tǒng)和常用工具方面的開發(fā)效率也非常高，尤其值得一提的是原型系統(tǒng)。
更快地讓原型系統(tǒng)運(yùn)轉(zhuǎn)起來，不僅可以盡早驗(yàn)證一些假設(shè)，也能夠更好地與迭代開發(fā)相結(jié)合，更及時(shí)地與需求方進(jìn)行溝通，幫助需求方挖掘和了解自己真正的需求。開發(fā)效率可以說是動(dòng)態(tài)語(yǔ)言最為吸引人的地方，這也被認(rèn)為是將來開發(fā)語(yǔ)言的前進(jìn)方向。這些年隨著敏捷開發(fā)的盛行，越來越多的開發(fā)者意識(shí)到，原來動(dòng)態(tài)語(yǔ)言的特性和敏捷開發(fā)的價(jià)值觀也相當(dāng)契合：縮短反饋時(shí)間，對(duì)變化的響應(yīng)能力更強(qiáng)。
2. 代碼量。曾有報(bào)道說，用Ruby on Rails寫同樣的項(xiàng)目，代碼量大概只有Java的1/10。且先不說這個(gè)說法是否有夸張的成分，但就實(shí)際來看，動(dòng)態(tài)語(yǔ)言的確從代碼量上來說，要比 Java/C/C++等傳統(tǒng)靜態(tài)編譯型語(yǔ)言要少的多（當(dāng)然語(yǔ)言的表達(dá)能力與動(dòng)態(tài)靜態(tài)關(guān)系并不大，靜態(tài)函數(shù)式語(yǔ)言的表達(dá)能力也很強(qiáng)），可能幾千行的項(xiàng)目就算得上是個(gè)大項(xiàng)目。
3. 測(cè)試。因?yàn)閯?dòng)態(tài)語(yǔ)言很容易實(shí)現(xiàn)反射等動(dòng)態(tài)特性（JUnit也是等到Java支持了反射以后才出現(xiàn)的），因此測(cè)試也更為容易實(shí)現(xiàn)。Python和Ruby的標(biāo)準(zhǔn)庫(kù)中都帶有unittest的框架，這幾乎可以讓你無成本地使用單元測(cè)試來加固代碼。因?yàn)閯?dòng)態(tài)語(yǔ)言本身不具有編譯過程，因此犯下某些低級(jí)錯(cuò)誤的幾率大大增加，也為重構(gòu)帶來了重重困難。沒有單元測(cè)試的重構(gòu)如同夢(mèng)魘一般，動(dòng)態(tài)語(yǔ)言尤甚。
因此，在開發(fā)語(yǔ)言以動(dòng)態(tài)語(yǔ)言為主的開源項(xiàng)目中，單元測(cè)試總是占有相當(dāng)大的比重。還有建議稱測(cè)試代碼與生產(chǎn)代碼的比率（Unit Test To Code Ratio）要達(dá)到2:1以上。另外，動(dòng)態(tài)語(yǔ)言的測(cè)試環(huán)境更容易搭建，實(shí)現(xiàn)Mock也更為簡(jiǎn)單。
4. 原生數(shù)據(jù)結(jié)構(gòu)。現(xiàn)在主流的動(dòng)態(tài)語(yǔ)言多為腳本語(yǔ)言發(fā)展而來，而在這些語(yǔ)言中，集合、列表和詞典這樣的數(shù)據(jù)結(jié)構(gòu)都是原生的，而靜態(tài)語(yǔ)言的數(shù)據(jù)結(jié)構(gòu)往往是通過程序類庫(kù)來實(shí)現(xiàn)的。比如Python就提供了set、tuple、list和dict等原生數(shù)據(jù)結(jié)構(gòu)，同時(shí)還提供了大量操作（如數(shù)組分片等），讓這些數(shù)據(jù)結(jié)構(gòu)使用起來非常方便。原生數(shù)據(jù)結(jié)構(gòu)使得對(duì)數(shù)據(jù)的操控融入到了語(yǔ)言的語(yǔ)法當(dāng)中，讓程序更為易讀，這也讓基于代碼的溝通更為順暢。
5. 簡(jiǎn)單易學(xué)。動(dòng)態(tài)語(yǔ)言的語(yǔ)法相對(duì)簡(jiǎn)單，學(xué)習(xí)成本看似也比較低。有人舉例說，Python和Ruby寫個(gè)Hello World只需要一行即可，這是很多靜態(tài)語(yǔ)言所達(dá)不到的（把多行代碼寫成一行的不算）。
當(dāng)然你可以認(rèn)為這只不過是句玩笑話，不過單就語(yǔ)法而言，動(dòng)態(tài)語(yǔ)言的學(xué)習(xí)門檻要比很多靜態(tài)語(yǔ)言要低的多。可是，開發(fā)不僅僅只是語(yǔ)法而已。很多動(dòng)態(tài)語(yǔ)言的初學(xué)者，能夠用動(dòng)態(tài)語(yǔ)言寫一些簡(jiǎn)單的小程序小工具，卻很難構(gòu)建起龐大復(fù)雜的商業(yè)系統(tǒng)，究其原因，主要是還是因?yàn)橄到y(tǒng)設(shè)計(jì)和面向?qū)ο蟮墓Φ浊啡彼鶎?dǎo)致的。如何設(shè)計(jì)，如何抽象，如何重構(gòu)，這些能力與語(yǔ)言無關(guān)，而是個(gè)人的修為。
正如陸游所言，“功夫在詩(shī)外”，這些能力也不是一朝一夕、通過學(xué)學(xué)語(yǔ)言就能夠輕易練就的。當(dāng)然，動(dòng)態(tài)語(yǔ)言的各種特性（如Duck Typing）也使得在靜態(tài)語(yǔ)言中不得不使用的設(shè)計(jì)模式可以很自然地表達(dá)，這些差異也增加了動(dòng)態(tài)語(yǔ)言學(xué)習(xí)的隱性成本。
#p#
不足之處
任何事物都具有兩面性，動(dòng)態(tài)語(yǔ)言也不例外，雖然優(yōu)勢(shì)顯而易見，動(dòng)態(tài)語(yǔ)言的不足之處也有很多。這里列舉一些我們?cè)陂_發(fā)過程中所遇到的問題，以及一些初步的解決方案，來供大家參考。
1. 運(yùn)行效率。運(yùn)行效率低下使得動(dòng)態(tài)語(yǔ)言飽受詬病。“跑得太慢”這頂帽子已經(jīng)在動(dòng)態(tài)語(yǔ)言的頭上扣了許多年。甚至有Benchmark表明，在某些應(yīng)用場(chǎng)景下，動(dòng)態(tài)語(yǔ)言的運(yùn)行效率和C/C++、Java等成熟的靜態(tài)語(yǔ)言相比，相差數(shù)十倍甚至上百倍，這也為動(dòng)態(tài)語(yǔ)言的普及埋下陰影。不少開發(fā)者因?yàn)檫\(yùn)行效率的問題，紛紛表示 “對(duì)動(dòng)態(tài)語(yǔ)言很失望”。其實(shí)我倒是覺得大可不必糾結(jié)在這個(gè)問題上，原因有兩點(diǎn)。
第一，很多動(dòng)態(tài)語(yǔ)言的應(yīng)用場(chǎng)景使得運(yùn)行效率的重要程度大大降低。就拿 Ruby on Rails來說，在Web開發(fā)這個(gè)應(yīng)用場(chǎng)景里，數(shù)據(jù)庫(kù)的響應(yīng)時(shí)間無疑是最大時(shí)延，與之相比代碼運(yùn)行時(shí)間就微不足道了。而且通過Cache和優(yōu)化，基本上可以消除代碼運(yùn)行效率低對(duì)項(xiàng)目的影響。又如我們的消息網(wǎng)關(guān)系統(tǒng)，最耗時(shí)的部分就是網(wǎng)絡(luò)通信和文件I/O，而這兩部分動(dòng)態(tài)語(yǔ)言和靜態(tài)語(yǔ)言相比并無明顯劣勢(shì)，運(yùn)行效率的問題可以完全忽略。
第二，如果遇到很耗CPU或者很耗內(nèi)存的運(yùn)算，完全可以通過C/C++實(shí)現(xiàn)的擴(kuò)展來解決。無論是Python還是Ruby，都支持采用C/C++編寫擴(kuò)展。通過這些擴(kuò)展，可以極大地提高運(yùn)行效率，從而彌補(bǔ)動(dòng)態(tài)語(yǔ)言在運(yùn)行效率上的不足。
2. BUG難于發(fā)現(xiàn)。動(dòng)態(tài)語(yǔ)言由于沒有構(gòu)建的過程，因此很多錯(cuò)誤只有等到運(yùn)行時(shí)才會(huì)發(fā)現(xiàn)。而這些錯(cuò)誤很可能是些低級(jí)錯(cuò)誤，比如拼寫錯(cuò)誤、沒有import相關(guān)的類庫(kù)，或者括號(hào)不匹配等等。如果每次修復(fù)這樣的BUG都要通過去測(cè)試環(huán)境中部署來驗(yàn)證的話，則會(huì)浪費(fèi)了大量時(shí)間。
因此動(dòng)態(tài)語(yǔ)言往往需要充分的自動(dòng)化測(cè)試套件，才能夠確保代碼基本可用。另外，使用動(dòng)態(tài)語(yǔ)言的時(shí)候，一個(gè)良好的代碼靜態(tài)檢查工具也是很有必要的。它不但可以糾正一些低級(jí)錯(cuò)誤，而且還可以幫助你發(fā)現(xiàn)代碼中的Bad Smells，大大提高開發(fā)效率。
對(duì)于Python來說，Pyflakes或Pylint都是不錯(cuò)的選擇；而Ruby也有眾多工具可供使用。測(cè)試充分的代碼也更容易重構(gòu)，在重構(gòu)動(dòng)態(tài)語(yǔ)言項(xiàng)目時(shí)要萬(wàn)分小心，因?yàn)閯?dòng)態(tài)語(yǔ)言極容易犯錯(cuò)，稍不留意就會(huì)引入新的BUG。保持小步前進(jìn)的步伐，每次修改后都執(zhí)行測(cè)試，最好再通過持續(xù)集成環(huán)境來幫助發(fā)現(xiàn)測(cè)試失敗的情況，這樣重構(gòu)起來才能得心應(yīng)手。
3. 專業(yè)人員少。不少使用動(dòng)態(tài)語(yǔ)言的公司都會(huì)遭遇一個(gè)問題，那就是使用動(dòng)態(tài)語(yǔ)言的資深開發(fā)人員很少，不但很難招聘到靠譜的員工，核心人員的離隊(duì)也會(huì)對(duì)公司造成很大的損失。這是因?yàn)橥耆褂脛?dòng)態(tài)語(yǔ)言進(jìn)行開發(fā)的公司少的可憐，只有極少數(shù)的開發(fā)者能夠參與其中并獲得相關(guān)的開發(fā)經(jīng)驗(yàn)。絕大多數(shù)的動(dòng)態(tài)語(yǔ)言使用者還處在愛好者階段，跟著Tutorials寫寫Demo，或者隨手寫個(gè)Utils等等。
因?yàn)楦咚降膭?dòng)態(tài)語(yǔ)言開發(fā)者的確是可遇不可求，因此尋找有經(jīng)驗(yàn)的開發(fā)者也許要花上不少的時(shí)間和成本。當(dāng)團(tuán)隊(duì)有了較為有經(jīng)驗(yàn)的開發(fā)者以后，就需要通過內(nèi)部培訓(xùn)、結(jié)對(duì)編程等手段，幫助公司里沒有經(jīng)驗(yàn)的開發(fā)者迅速積累經(jīng)驗(yàn)，逐漸成為動(dòng)態(tài)語(yǔ)言方面的靠譜人才。
其實(shí)，對(duì)于動(dòng)態(tài)語(yǔ)言的圈子，還有一個(gè)有趣的說法：因?yàn)閷W(xué)習(xí)動(dòng)態(tài)語(yǔ)言的人往往都是在其他領(lǐng)域有了很深的積累后，在有余力的情況下才接觸動(dòng)態(tài)語(yǔ)言的，因此往往相對(duì)都比較靠譜，動(dòng)態(tài)語(yǔ)言的圈子反而能夠幫助雇主們甄選出一批高素質(zhì)的開發(fā)者。
4. 不夠成熟。動(dòng)態(tài)語(yǔ)言的發(fā)展歷史雖然不比靜態(tài)語(yǔ)言差到哪里（比如Ruby和Java就同為1995年始創(chuàng)），然而由于其較為小眾，因此無論是虛擬機(jī)的實(shí)現(xiàn)上，語(yǔ)言本身的機(jī)制上，還是相關(guān)的配套工具上都算不得十分成熟。
例如，Ruby雖然以其優(yōu)美靈活的語(yǔ)法為人所稱道，但也因?yàn)槠涮摂M機(jī)效率低下和內(nèi)存泄露問題所為人詬病，使用Ruby on Rails的網(wǎng)站往往需要加配監(jiān)控程序，一旦發(fā)現(xiàn)某個(gè)VM內(nèi)存超標(biāo)立刻重啟；Python的虛擬機(jī)雖然還算穩(wěn)定，但長(zhǎng)久以來一直受GIL（Global Interpreter Lock）問題所困擾，完全無法發(fā)揮多核的優(yōu)勢(shì)，這在家用PC都早已多核的今天的確是個(gè)不小的問題（事實(shí)上Ruby也存在GIL問題）。
不過，雖然官方實(shí)現(xiàn)不夠成熟，現(xiàn)在已經(jīng)有很多逐漸成熟的其他選擇可供使用。比如JRuby就充分利用了Java成熟的虛擬機(jī)和Ruby優(yōu)良的語(yǔ)法特性，還可以允許開發(fā)者使用Java背后龐大的類庫(kù)。通過multiprocessing或Stackless Python，甚至手工將任務(wù)切成多份，分發(fā)給多個(gè)進(jìn)程運(yùn)行，都可以規(guī)避掉GIL的問題，更充分地利用系統(tǒng)性能。
當(dāng)然，隨著時(shí)間的推移，動(dòng)態(tài)語(yǔ)言的實(shí)現(xiàn)將會(huì)越來越成熟，不但MRI逐漸完善，MagLev和Rubinius等一系列優(yōu)秀的Ruby虛擬機(jī)也開始登上舞臺(tái)；Python 3000甚至打破了向后兼容性，試圖將Python以前的設(shè)計(jì)錯(cuò)誤全面改寫。回頭去看Java等一批成熟開發(fā)語(yǔ)言的發(fā)展路線，有誰(shuí)沒有經(jīng)歷過不成熟的青春期呢？
小結(jié)
通過實(shí)踐我們發(fā)現(xiàn)，動(dòng)態(tài)語(yǔ)言既不是什么洪水猛獸，也不是什么奇巧玩物，它們已經(jīng)逐漸成長(zhǎng)為稱手的兵器，幫助開發(fā)者們快速完成項(xiàng)目，進(jìn)而達(dá)成商業(yè)目標(biāo)。使用動(dòng)態(tài)語(yǔ)言，已經(jīng)讓我們切切實(shí)實(shí)感受到了它的開發(fā)效率為我們所帶來的好處。在商業(yè)機(jī)會(huì)瞬息萬(wàn)變的今天，誰(shuí)能以最快的速度實(shí)現(xiàn)自己的想法，誰(shuí)能盡快應(yīng)對(duì)市場(chǎng)帶來的變化，誰(shuí)就能離成功更進(jìn)一步。
誠(chéng)然，動(dòng)態(tài)語(yǔ)言目前還存在很多問題。但瑕不掩瑜，如果在使用時(shí)可以意識(shí)到這些問題，并善加處理的話，動(dòng)態(tài)語(yǔ)言也可以成為復(fù)雜商業(yè)系統(tǒng)的主角，在企業(yè)開發(fā)中占據(jù)自己的地位。而且隨著開源社區(qū)的努力，很多問題正逐一被解決。我們有理由相信，在不遠(yuǎn)的未來，動(dòng)態(tài)語(yǔ)言一定會(huì)有一片更為廣闊的天空。
【編輯推薦】
