Python等動態(tài)語言企業(yè)應(yīng)用面面觀
動態(tài)語言的興起已經(jīng)有些年頭了，現(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)域占有一席之地。（相關(guān)文章推薦：動態(tài)語言，別再輕言不）
不過目前動態(tài)語言在企業(yè)開發(fā)中的應(yīng)用還不夠廣泛，并沒有承擔(dān)起主力開發(fā)語言的重任。尤其是在底層系統(tǒng)開發(fā)方面，動態(tài)語言遠沒有在Web開發(fā)方面那么風(fēng)光。
在運行時效率和虛擬機穩(wěn)定性方面的不足，使得動態(tài)語言注定無法與編譯型語言競爭，并取代它們在高性能領(lǐng)域的地位。然而，動態(tài)語言也有自己的優(yōu)勢所在。如何克服自己的劣勢，將優(yōu)勢發(fā)揚光大，便是每一位動態(tài)語言開發(fā)者所面臨的機遇和挑戰(zhà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ā)的價值觀也相當(dāng)契合：縮短反饋時間，對變化的響應(yīng)能力更強。
2. 代碼量。曾有報道說，用Ruby on Rails寫同樣的項目，代碼量大概只有Java的1/10。且先不說這個說法是否有夸張的成分，但就實際來看，動態(tài)語言的確從代碼量上來說，要比 Java/C/C++等傳統(tǒng)靜態(tài)編譯型語言要少的多（當(dāng)然語言的表達能力與動態(tài)靜態(tài)關(guān)系并不大，靜態(tài)函數(shù)式語言的表達能力也很強），可能幾千行的項目就算得上是個大項目。
3. 測試。因為動態(tài)語言很容易實現(xiàn)反射等動態(tài)特性（JUnit也是等到Java支持了反射以后才出現(xiàn)的），因此測試也更為容易實現(xiàn)。Python和Ruby的標(biāo)準(zhǔn)庫中都帶有unittest的框架，這幾乎可以讓你無成本地使用單元測試來加固代碼。因為動態(tài)語言本身不具有編譯過程，因此犯下某些低級錯誤的幾率大大增加，也為重構(gòu)帶來了重重困難。沒有單元測試的重構(gòu)如同夢魘一般，動態(tài)語言尤甚。
因此，在開發(fā)語言以動態(tài)語言為主的開源項目中，單元測試總是占有相當(dāng)大的比重。還有建議稱測試代碼與生產(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ù)的操控融入到了語言的語法當(dāng)中，讓程序更為易讀，這也讓基于代碼的溝通更為順暢。
5. 簡單易學(xué)。動態(tài)語言的語法相對簡單，學(xué)習(xí)成本看似也比較低。有人舉例說，Python和Ruby寫個Hello World只需要一行即可，這是很多靜態(tài)語言所達不到的（把多行代碼寫成一行的不算）。
當(dāng)然你可以認為這只不過是句玩笑話，不過單就語法而言，動態(tài)語言的學(xué)習(xí)門檻要比很多靜態(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é)語言就能夠輕易練就的。當(dāng)然，動態(tài)語言的各種特性（如Duck Typing）也使得在靜態(tài)語言中不得不使用的設(shè)計模式可以很自然地表達，這些差異也增加了動態(tài)語言學(xué)習(xí)的隱性成本。
#p#
不足之處
任何事物都具有兩面性，動態(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ā)者也許要花上不少的時間和成本。當(dāng)團隊有了較為有經(jīng)驗的開發(fā)者以后，就需要通過內(nèi)部培訓(xùn)、結(jié)對編程等手段，幫助公司里沒有經(jīng)驗的開發(fā)者迅速積累經(jīng)驗，逐漸成為動態(tài)語言方面的靠譜人才。
其實，對于動態(tài)語言的圈子，還有一個有趣的說法：因為學(xué)習(xí)動態(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)存超標(biāo)立刻重啟；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)性能。
當(dā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è)目標(biāo)。使用動態(tài)語言，已經(jīng)讓我們切切實實感受到了它的開發(fā)效率為我們所帶來的好處。在商業(yè)機會瞬息萬變的今天，誰能以最快的速度實現(xiàn)自己的想法，誰能盡快應(yīng)對市場帶來的變化，誰就能離成功更進一步。
誠然，動態(tài)語言目前還存在很多問題。但瑕不掩瑜，如果在使用時可以意識到這些問題，并善加處理的話，動態(tài)語言也可以成為復(fù)雜商業(yè)系統(tǒng)的主角，在企業(yè)開發(fā)中占據(jù)自己的地位。而且隨著開源社區(qū)的努力，很多問題正逐一被解決。我們有理由相信，在不遠的未來，動態(tài)語言一定會有一片更為廣闊的天空。
【編輯推薦】
