非商業轉載請註明做譯者、出處,並保留本文的原始連接:http://www.ituring.com.cn/article/131909java
Venkat Subramaniam 博士是Agile Developer公司創始人,Jolt圖書大獎獲獎做者,如今休斯敦大學計算機系兼職任教。做爲敏捷開發方面的權威人士,他培訓並指導了美國、加拿大、印度和歐洲多國的上千名軟件開發人員,並屢次在各類大會上發表演講。Venkat是一位多產的技術做家,他著有《Groovy程序設計》、《Scala程序設計:Java虛擬機多核編程實戰》,以及Jolt大獎獲獎圖書《高效程序員的45個習慣:敏捷開發修煉之道》。程序員
問:在《高效程序員的45個習慣》中,你告訴了咱們不少絕妙的技巧。你是從哪裏獲得這些想法的?web
大多數是經過對於軟件項目觀察和批判思考得來的。終年以來,經過在商業軟件項目上的工做經驗,咱們觀察到了哪些作法是有效的,而哪些作法並無論用。咱們真心誠意地想要分享所學到的知識,這就是這本書的寫做動機。書中的想法來源自我的經歷、觀察、思考,以及討論核心問題及其解決方案。當咱們回想這些項目的時候,經過咱們倆人(Andy Hunt與Venkat Subramaniam)的我的經歷,以及諮詢對象的意見,一些最爲基礎的實踐浮現了出來。咱們意識到這些實踐能夠幫助到在軟件開發道路上追求精益求精的人。編程
問:Java的特性愈來愈像Scala和Groovy,考慮到Java在性能方面的優點,Scala和Groovy的地位是否會有所動搖?這三種語言在將來會是什麼樣?小程序
Java正在向函數式編程看齊;這種思想在不少語言中都已經存在好久了,好比 LISP,Erlang,以及Haskell。對於這門被不少人稱爲「世界上最受歡迎」的語言來講,這是正確的方向。可是我並不認爲這對於任何其餘語言是一種威脅。之前,和Java相比有些語言能夠多作n件事。如今,咱們仍然能夠多作或用不一樣方式來完成n-1件事。設計模式
若是真要發生的話,Java的進化只會讓其餘這些JVM語言變得更強大。Java對於lambdas,streams以及invokedynamic的支持提高了這個生態系統,使其更加支持函數式編程風格。JVM的其餘語言能夠從中獲益。那些由於編程風格而不肯意接觸Scala或Groovy的程序員很快就會在Java中喜歡上這種風格。隨着Java在正確的道路上不斷前進,差距就變小了。這對於其餘語言來講是好事,對於JVM程序員來講是好上加好。微信
問:Groovy之父James Strachan曾經說過Scala會取代Java,你贊成這種說法嗎?相對於Scala而言,Groovy有什麼獨特的優點嗎?編程語言
若是真要發生的話,那最好的時機就是在幾年之後。可是看起來語言的應用應該會是分散的。當Java還在充當排頭兵的時候,應該還有其餘幾種語言也應用在生產環境中。很難相信會有某種語言徹底取代Java,在5年內確定不會發生。可是十年後呢?真但願我有這種預測能力。函數式編程
語言吸引着我。Scala很好玩,Groovy也頗有趣。Groovy的真正魅力在於它的元編程能力以及輕易和Java集成的能力。Groovy在大多數地方保留了Java的語義,並增長了流暢性。可是Groovy的制勝法寶是利用運行時間和編譯時間的元編程進化程序,這也讓Gradle和Grails這樣的工具備了用武之地。函數
問:什麼樣的項目最適合應用Groovy?
幾乎全部須要Java的項目均可以用Groovy。幾年前,大部分人對Groovy還有性能方面的憂慮,可是隨着靜態編譯的出現,這種憂慮已經很大程度消失了。
Groovy對於各類各樣的項目都適用,從小程序到企業級應用。
對於還不太熟悉Groovy的人來講,能夠選擇從Spock開始,這是一個用Groovy元編程寫的很不錯的自動測試工具。一旦咱們習慣了Groovy,就能夠繼續用Groovy完成自動化任務了,好比發送大部分郵件,運行背景任務,處理XML文件、字符串以及文件處理等等。
任何能夠在Java裏面作的事,咱們均可以用更少的代碼在Groovy更流暢地完成。接下來咱們能夠去建立web應用,在這裏,咱們還能夠利用Groovy的元編程用代碼合成行爲,而不須要爲不一樣類型的對象寫多餘的代碼。
我本身已經爲不少大公司採用Groovy和Grails進行過諮詢和培訓,他們都在生產力上有所提高,也能更輕鬆地開發和部署了。
問:Groovy已經能夠在Android上使用了,有人預測一旦程序員們嘗試過Groovy,就會拋棄Java。Groovy在Android上運行地如何?它會是革命性的嗎?
我已經用Groovy和其餘JVM語言完成了不少工做,在設備上說,我大多數時候都在爲iPhone開發。我在Android上的經驗仍然有限,因此沒法更好地回答這個問題。
問:Scala是一種能力很強的語言,可是不少開發者也說它是宇宙中最難的語言。有不少對這門語言感興趣的程序員,對於他們你有什麼建議嗎?
我常常開玩笑說Scala就像一座城市,你應該知道哪一個部分是能夠拜訪的,而哪一個部分是應該避開的。話雖如此,若是咱們只熟悉一門語言,那麼學習一門徹底不一樣的新語言一般都是很困難的。
咱們不須要學會關於Scala的一切或者學習Scala的全部部分纔能有效地使用它。若是發現Scala的某些領域比其餘部分更難學,那麼咱們能夠從那些不太嚇人的地方開始。從語法上說,Scala能夠用不少不一樣的方法來完成同一件事。咱們能夠從最熟悉的地方開始,而後逐漸熟悉整個語言,咱們能夠探索用不一樣的方式來完成相同的動做。若是語法變得讓人迷惑,咱們能夠後退,給變量更有表現力的名字,避免一開始看起來就很神祕的運算符。
要想學習這門語言有不少可用的資源。比起讀書,花時間寫代碼更加劇要。只有寫更多代碼,咱們才能更好地掌握語言。因此,把恐懼放到一邊,讓實踐和激情指引咱們吧。
問:你以爲讓團隊全部成員都接受一套語言和工具備必要嗎?爲何?
有兩類團隊。一類是特定人在特定領域工做,其中某一個開發者會對特定部分的代碼負責。另外還有一種團隊,他們集體對代碼負責,任何願意和有能力修改代碼的人均可以這麼作。我是集體負責制和合做開發的倡導者。這樣作能夠下降不少方面的風險,好比下降單點失敗的可能性。
在團隊中存在大多數人沒法理解的代碼已是一個很大的風險了。咱們不想再加上大多數成員沒法理解的語言和工具。另外,對於實踐集體負責制的團隊,擁有整個團隊都能維護的語言以及共同的開發環境,是合做工做方式可以成功的惟一方法。
問:經過scriptEngine,Java調用Groovy的代碼的方式性能比較差,Groovy和Java配合有什麼更好的方式?
Groovy身上的一大好處就是用來編譯的
-j
選項。經過這個選項,Groovy的編譯器groovyc會讓Java編譯器來編譯.java
文件,讓groovyc編譯器來編譯.groovy
文件。一旦這些文件由不一樣編譯器編譯,其最終結果就都是字節碼。一旦咱們把代碼都編譯成字節代碼,不一樣語言寫出的代碼就沒什麼實際上的區別了。只要在類路徑中還有必要的jar
文件就沒問題。因此其實沒什麼必要利用scriptEngine把Java代碼調入到Groovy代碼中。
問:對於你來講學習新語言和新工具意味着什麼?最大的獎賞是什麼?
我能夠毫無壓力地用十幾種語言編程。學習前幾門語言確實很難,後面的那些就容易多了。其背後的緣由我認爲在於一點一滴積累式的學習。咱們並不善於一口氣學習不少新概念。咱們漸進式學習,每次知識的體量都很小。
我堅決地相信學習一門新語言的難度和咱們所熟悉掌握的語言數量成反比例。若是僅僅熟知一門語言,那麼要學習和第一門語言大相徑庭的第二種語言就會花不少時間。另外一方面,若是咱們花時間研究不一樣的範式和呈現方式,思惟就會迅速比對新語言中的特性。有可能咱們能夠在熟悉的特性中找到相似的。可是若是咱們只知道一種範式或呈現方式,那麼這個可能性就很低,因此學習起來就很費勁。
十幾年前,我用Basic和C編程。而後我又用C++, Java,以及C#編程。Ruby對我來講是一個很大的改變,學習起來有些困難。我用Ruby編程了幾年以後,再學習Groovy就變得很簡單。隨後我又開始對Erlang感興趣。這也是一次大改變。可是在我用Erlang編程的幾年以後,學習Scala變得很是容易,由於它們的角色模型、功能類型等方面都很類似。
在我看來學習語言和工具的收穫是很大的:
首先,這讓我擁有一個很大的客戶基礎。最近我幫助了一家大公司適應了關鍵性敏捷技術實踐,好比測試驅動開發以及有效模仿。做爲一家國際化的大公司,他們擁有不一樣語言寫成的應用。我須要在不一樣地點使用8種不一樣語言幫助他們。我沒法想象若是不會這些語言,我將如何指導這家公司。
另外,因爲接觸了各類不一樣的語言,對於我來講學習新語言的時間成本已經變得很低。
我在教授軟件設計和編程語言課程的時候,我給學生百分百的自由來挑選本身想學的語言。對於我來講解釋概念是很容易的,好比設計模式,我能夠用他們熟知的語言舉例子。做爲一位訓練者,我在這方面也受益不淺,掌握多種編程語言的感受就想像用不一樣的天然語言進行交流同樣。