引入新程式語言的經驗教訓

唐尤華發表於2012-03-05

引言:這些年我(在工作中)使用過很多程式語言:(馬上能夠想到的有)Cold Fusion、HTML、Javascript、php、 SQL、 CSS,、ASP(經典ASP和.net)、C#、Ruby、Flex、Java以及Clojure。每個語言都有自身的優缺點。作為一名程式設計師,你可以很容易地指出這些缺點——概括起來就是一句話:

我痛恨所有的程式語言—— Matt Foemmel

我認為一開始就考慮到這個問題很重要。在某些時候,你會對現在提倡的東西開始厭惡,所以請想象一下別人對它的感受。

在2008年,我在DRW的一個程式碼庫中引入Clojure語言。這篇部落格討論了過去幾年中,我在引入新語言的過程中得到的經驗和教訓。

選擇語言

在組織裡引入一門新的語言並非易事。如果你想要成功,你需要選擇一門程式語言,它不但能夠滿足廣泛的技術要求同時還要得到大家的認可。在加入DRW的時候,我100%用Java程式設計,儘管事實上我編寫的大部分程式碼只需要在眨眼之間執行完成(250毫秒)。我們編寫程式碼要求執行時間比眨眼還要短,Java是絕對正確的選擇,但使用Java編寫其他程式碼讓我感覺Java成為了一種負擔。

偶爾我會抱怨這種負擔,我的老闆開始對JRuby發生了興趣。我認為選擇JRuby對我們已經是一個勝利,但就我個人而言更想聽到支援非Java語言的呼聲。如果考慮JRuby,那麼我認為任何高階的動態型別語言都可以勝任。

然而,在我對JRuby生成好奇心之前,我已經開始學習Haskell了。總的說來,在貿易公司使用的軟體要求執行“快速”。如果我要成功地引入一門新語言,它必須執行得“幾乎和Java一樣快”。Haskell執行速度很快我已有所耳聞,它同時也滿足了我的另一個選擇條件:

一門程式語言,如果不能對你思考程式設計的方式產生影響,就不值得去學習。——  Alan Perlis

我認為,如果我發現一門程式語言“效能足夠好”,釋出程式速度更快,並且能夠提高我們的程式設計水平,那麼在它上面花時間就是值得的。

我玩過一點Haskell,但是學習曲線似乎太陡峭。學習Haskell需要一些時間,但更重要的是:我們的產品已經執行在JVM上。如果我需要得到任何幫助,應該能夠輕易地融入現有的基礎設施。想想Clojure,它的效能足夠好,比Java更簡潔,並且比我之前用過的其他語言更加有效。Clojure同時也是動態型別的高階語言(像Ruby一樣),所以我希望能夠得到老闆的支援。

讓同事們儘可能地減少學習的痛苦是一個很大的要求——我認為這是接受新語言的關鍵。Clojure看上去是最佳的選擇,因為我們現在已經在工作中已經使用下列工具:

• 整天使用IntelliJ

• 使用JUnit執行所有測試

• 使用TeamCity建立CI和artifact

• 在伺服器上執行JVM

• 使用Yourkit進行動態分析

Clojure能夠滿足我的所有條件,其他同事接受起來也會更容易。

作為學習,我更推薦Haskell或者OCaml,但他們並不適合在實際中選用——我懷疑是否能夠成功地將他們應用到開發中。當我需要在Clojure方面給與專業指導時,我會依賴其他人認可的“最佳”JVM伺服器設定。如果一旦選擇了Haskell或者OCaml,我將需要在更多方面成為專家(例如部署、記憶體模型、函式庫、新開發工具等等)。

不論是當時還是現在,我都認為Clojure是在技術要求和公司環境下的最佳選擇。

Hello World

引入一門新的語言是一個微妙的行為。你需要兼顧很多的相關內容。我不確定同事們會對使用Clojure作何反應,所以我在家裡預先寫好了程式碼。雖然大家都需要整合測試,然而沒有人積極行動。於是我開始用Java編寫整合測試,然後寫出了Clojure的版本。我非常瞭解Clojure並能夠向其他人展示它的簡潔——這是團隊在整合測試中最看重的東西。除此之外,因為測試並不是實際產品執行的程式碼,因而並不真正需要考慮實際執行速度。

整合測試是一個引入新語言的好地方,其實任何非產品程式碼都是好的選擇。例如,你也可以選擇資料庫遷移指令碼、日誌檔案解析器、第三方軟體模擬器或者軟體部署。只要你的選擇不會馬上帶來痛苦,你應該能夠很容易地從任何遷移到新語言的失敗中恢復過來。

當我完成了Java和Clojure版本的測試以後,我給開發組裡的其他人展示了這兩個版本。我告訴他們為什麼我推薦Clojure版本,並詢問他們能不能用Clojure做一次嘗試。我也做出承諾,讓他們很難拒絕做這樣的實驗。

hello world

( Credit: Windell Oskay ,伯樂線上配圖)

 

你的使命

為了讓我的夥伴們減少接受新語言的恐懼,我做出了下列承諾:

• 如果你想要編寫程式碼,我會和你一起做(假如你想要和我一起工作的話)

• 如果你不想編寫程式碼,我會將缺失的部分補上

• 如果你覺得用新語言寫程式碼讓你難以接受,我會在我的個人時間將所有的內容重新用Java寫一遍

很明顯地,你需要在使用新語言編寫很多程式碼之前讓團隊接納——否則你會獨自一個人在晚上和週末加班。

工具支援

運氣好的話,你的團隊已經有了一套他們喜歡的工具。不論工具是什麼,你的新語言應該能夠很好地被支援。對我而言,這就意味著在IntelliJ上Clojure應該像Java一樣被執行。很大程度上La Clojure外掛完成了這項重任;然而,我需要編寫一個而是框架讓我能夠執行指定的測試並且無縫地將現有JUnit測試集合整合進去。這裡要說的是,請為團隊成員消除所有新語言可能帶來的阻力。學習一門新語言的要求是合理的,但僅僅為了適應一個(在那個團隊裡)未經實際驗證過的語言而改變團隊的工作,這也許是一個過分的要求。

你也可能需要作出一些犧牲。我喜歡在emacs中編寫Clojure;然而我寧願在IntelliJ中編寫Clojure而不是Java。在轉向新語言剛開始的脆弱時期,你會是需要作出妥協最多的人。

尋找同盟軍

對新語言熱愛程度的不同會讓事情的發展也有所不同。當別人開始感興趣的時候,你應當盡己所能地鼓勵他們。然而,不要強迫別做事情——這是最容易樹敵的辦法。希望你能找到一些和你一樣對新語言感興趣的夥伴——與他們一起緊密工作並提高你的水平。你需要尋找更多的支持者,否則你會成為團隊中唯一強迫別人做他們不喜歡事情的人。

你不可避免地需要做一些調研,需要相關工具的支援,而且需要處理比開始預期更多的問題。當你發現自己捉襟見肘的時候,會需要其他人來助你一臂之力。即使一切運轉正常,你也會發現需要一些支持者來幫助你維護日益增多的新語言程式碼。

最後,最糟糕的情況是當你離開團隊時沒有一個留下的人願意維護這些程式碼。當人員發生調整時,採納新語言會很容易成為大問題。

瞭解所有事情

很明顯地你不可能確切地瞭解所有的事情,但當問題出現時你需要能夠馬上給出或想出一個答案。在將新語言放進如何程式碼庫之前,你一定要通讀幾本新語言的書,因為程式碼庫是你的同事賴以工作的基礎。這樣還不夠,你還要知道如果遇到問題你能夠去哪裡尋求幫助。對於Clojure,得到問題回覆方式就是IRC,如果問題不是很緊急或者需要詳細描述你的問題,你可以通過郵件列表來尋求答案。如果你真的想要掩蓋自己的不足,你需要和語言的作者或者社群的領袖人物建立某種關係。

一旦人們接受了你介紹的新語言,他們會開始做一些你意想不到的事情。你需要了解語言的缺點,並想到可能因此帶來的後果。你還需要成為一名專家,通曉記憶體分配、效能、部署、工具整合、函式庫支援、升級計劃以及除了語言文法之外的所有問題。

你的支持者越多,需要“知道所有事情”的情形就越少。然而,在每天完成工作以後,你還是應當儘可能地去了解相關的技術。如果出現問題,所有人都會認為這是你的錯。這就是引入新語言應當承擔的責任,所以你應當更好地理解你正在做什麼。

獲得幫助

如果你的公司願意讓你引入新的語言,那它一定願意提供支援。有可能你已經得到了一些培訓預算。看看有沒有機會能夠讓語言作者或者社群領袖和你一起工作,或是提供相關的培訓。如果你在新語言的各個方面都有問題,那麼讓語言的作者和你一起工作會帶來巨大的好處。當然一切進展順利的時候,如果團隊中其他對新語言感興趣的同事能夠從語言作者(或者某個社群領袖)那裡學習,那麼將預算投給這樣的培訓會給你帶來巨大的好處。無論是你自己或是感興趣的支持者,利用公司的培訓預算來推廣新語言都是有益的事情。

成為擁護者而不是狂熱分子

每天結束工作的時候,並非每個人都能會妥協。這沒有關係。不要將自己的觀點強加給對此沒有興趣的人。最有可能的情況是,總會有人對“正確”選擇充滿熱情。也許你對自己推薦的語言報以熱情,但你的隊友可能非常喜歡之前的語言。你們不必為此分出誰對誰錯。人們只會用自己喜歡的語言程式設計,任何試圖讓他們嘗試別的方式都會弊大於利。喜歡用新語言的人們會聚集在一起,而不喜歡的人也會如此。沒有任何理由強迫別人接受。

起初我對這個問題的看法是“如果我提出一個好的辦法,那麼所有人都會接受它。”事實並非如此,所以我寫了一篇軟體開發中的妥協。我瞭解到一個人眼中“更好的辦法”在另一個人看來卻是“更糟糕的選擇”。最後,團隊分成了用Clojure程式設計和不用Clojure兩個小組。這對兩方都有好處,想要用Clojure的人會有更好的環境,而其他人也不用強迫使用Clojure.

這種劃分當然只是私下的,在公司裡我們仍然是“一個團隊”。但我們開發不同的應用程式,通過發訊息交流或者不溝通。我強烈建議一個小組按照不同的想法和規模分開(7個人的團隊,我認為分成4人和3人兩個小組是可以接受的),但永遠不要在公司裡公開。逐漸的,其他因素會讓團隊規模縮小,這種劃分會變得多此一舉。如果團隊沒有因為其他原因重組,我仍然堅信組內劃分是最好的選擇。

尾聲

引入一門新語言對於任何上規模的組織都是一件需要多年才能完成的事情。自打引入新語言開始,你的責任就永遠不會“結束”。反過來說,你已經開始使用適合這項工作最好的工具。希望所有說過和做過的事情都是值得的。就自己而言,我對自己的選擇感到高興,但我也期待未來的幾年裡在“引入新語言”這個話題上能有更多的收穫。

 

英文原文:jaycfields   編譯:伯樂線上唐尤華

【如需轉載,請標註並保留原文連結、譯文連結和譯者等資訊,謝謝合作!】

相關文章