西西軟件園多重安全檢測下載網(wǎng)站、值得信賴的軟件下載站!
軟件
軟件
文章
搜索

首頁業(yè)內(nèi)動態(tài) 業(yè)內(nèi)資訊 → 動態(tài)語言企業(yè)應(yīng)用優(yōu)缺點淺析

動態(tài)語言企業(yè)應(yīng)用優(yōu)缺點淺析

相關(guān)軟件相關(guān)文章發(fā)表評論 來源:本站整理時間:2010/7/8 18:32:34字體大。A-A+

作者:佚名點擊:156次評論:0次標(biāo)簽: 企業(yè)

  • 類型:社交聊天大。24.6M語言:中文 評分:10.0
  • 標(biāo)簽:
立即下載

動態(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)的工作,并沒有承擔(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)。

我所在的團隊用了近兩年的時間,將一個電信領(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)缺點。

動態(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)能力更強。所以許多動態(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)編譯型語言要少的多(當(dāng)然語言的表達能力與動態(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的標(biāo)準庫中都帶有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í)的隱性成本。

不足之處
任何事物都具有兩面性,動態(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)語言一定會有一片更為廣闊的天空。

    相關(guān)評論

    閱讀本文后您有什么感想? 已有人給出評價!

    • 8 喜歡喜歡
    • 3 頂
    • 1 難過難過
    • 5 囧
    • 3 圍觀圍觀
    • 2 無聊無聊

    熱門評論

    最新評論

    發(fā)表評論 查看所有評論(0)

    昵稱:
    表情: 高興 可 汗 我不要 害羞 好 下下下 送花 屎 親親
    字數(shù): 0/500 (您的評論需要經(jīng)過審核才能顯示)