引入新編程語言的經驗教訓
英文原文：Lessons Learned while Introducing a New Programming Language
引言：這些年我（在工作中）使用過很多編程語言：（馬上能夠想到的有）Cold Fusion、HTML、Javascript、PHP、 SQL、 CSS,、ASP（經典 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 做一次嘗試。我也做出承諾，讓他們很難拒絕做這樣的實驗。
( Credit: Windell Oskay)
你的使命
為了讓我的伙伴們減少接受新語言的恐懼，我做出了下列承諾：
如果你想要編寫代碼，我會和你一起做（假如你想要和我一起工作的話）
如果你不想編寫代碼，我會將缺失的部分補上
如果你覺得用新語言寫代碼讓你難以接受，我會在我的個人時間將所有的內容重新用 Java 寫一遍
很明顯地，你需要在使用新語言編寫很多代碼之前讓團隊接納——否則你會獨自一個人在晚上和周末加班。
工具支持
運氣好的話，你的團隊已經有了一套他們喜歡的工具。不論工具是什么，你的新語言應該能夠很好地被支持。對我而言，這就意味著在 IntelliJ 上 Clojure 應該像 Java 一樣被執行。很大程度上 La Clojure 插件完成了這項重任；然而，我需要編寫一個而是框架讓我能夠運行指定的測試并且無縫地將現有 JUnit 測試集合集成進去。這里要說的是，請為團隊成員消除所有新語言可能帶來的阻力。學習一門新語言的要求是合理的，但僅僅為了適應一個（在那個團隊里）未經實際驗證過的語言而改變團隊的工作，這也許是一個過分的要求。
你也可能需要作出一些犧牲。我喜歡在 emacs 中編寫 Clojure；然而我寧愿在 IntelliJ 中編寫 Clojure 而不是 Java。在轉向新語言剛開始的脆弱時期，你會是需要作出妥協最多的人。
尋找同盟軍
對新語言熱愛程度的不同會讓事情的發展也有所不同。當別人開始感興趣的時候，你應當盡己所能地鼓勵他們。然而，不要強迫別做事情——這是最容易樹敵的辦法。希望你能找到一些和你一樣對新語言感興趣的伙伴——與他們一起緊密工作并提高你的水平。你需要尋找更多的支持者，否則你會成為團隊中唯一強迫別人做他們不喜歡事情的人。
你不可避免地需要做一些調研，需要相關工具的支持，而且需要處理比開始預期更多的問題。當你發現自己捉襟見肘的時候，會需要其他人來助你一臂之力。即使一切運轉正常，你也會發現需要一些支持者來幫助你維護日益增多的新語言代碼。
最后，最糟糕的情況是當你離開團隊時沒有一個留下的人愿意維護這些代碼。當人員發生調整時，采納新語言會很容易成為大問題。
了解所有事情
很明顯地你不可能確切地了解所有的事情，但當問題出現時你需要能夠馬上給出或想出一個答案。在將新語言放進如何代碼庫之前，你一定要通讀幾本新語言的書，因為代碼庫是你的同事賴以工作的基礎。這樣還不夠，你還要知道如果遇到問題你能夠去哪里尋求幫助。對于 Clojure，得到問題回復方式就是 IRC，如果問題不是很緊急或者需要詳細描述你的問題，你可以通過郵件列表來尋求答案。如果你真的想要掩蓋自己的不足，你需要和語言的作者或者社區的領袖人物建立某種關系。
一旦人們接受了你介紹的新語言，他們會開始做一些你意想不到的事情。你需要了解語言的缺點，并想到可能因此帶來的后果。你還需要成為一名專家，通曉內存分配、性能、部署、工具集成、函數庫支持、升級計劃以及除了語言文法之外的所有問題。
你的支持者越多，需要“知道所有事情”的情形就越少。然而，在每天完成工作以后，你還是應當盡可能地去了解相關的技術。如果出現問題，所有人都會認為這是你的錯。這就是引入新語言應當承擔的責任，所以你應當更好地理解你正在做什么。
獲得幫助
如果你的公司愿意讓你引入新的語言，那它一定愿意提供支持。有可能你已經得到了一些培訓預算。看看有沒有機會能夠讓語言作者或者社區領袖和你一起工作，或是提供相關的培訓。如果你在新語言的各個方面都有問題，那么讓語言的作者和你一起工作會帶來巨大的好處。當然一切進展順利的時候，如果團隊中其他對新語言感興趣的同事能夠從語言作者（或者某個社區領袖）那里學習，那么將預算投給這樣的培訓會給你帶來巨大的好處。無論是你自己或是感興趣的支持者，利用公司的培訓預算來推廣新語言都是有益的事情。
成為擁護者而不是狂熱分子
每天結束工作的時候，并非每個人都能會妥協。 這沒有關系。不要將自己的觀點強加給對此沒有興趣的人。最有可能的情況是，總會有人對“正確”選擇充滿熱情。也許你對自己推薦的語言報以熱情，但你的隊友可能非常喜歡之前的語言。你們不必為此分出誰對誰錯。人們只會用自己喜歡的語言編程，任何試圖讓他們嘗試別的方式都會弊大于利。喜歡用新語言的人們會聚集在一起，而不喜歡的人也會如此。沒有任何理由強迫別人接受。
起初我對這個問題的看法是“如果我提出一個好的辦法，那么所有人都會接受它。”事實并非如此，所以我寫了一篇軟件開發中的妥協。我了解到一個人眼中“更好的辦法”在另一個人看來卻是“更糟糕的選擇”。最后，團隊分成了用 Clojure 編程和不用 Clojure 兩個小組。這對兩方都有好處，想要用 Clojure 的人會有更好的環境，而其他人也不用強迫使用 Clojure.
這種劃分當然只是私下的，在公司里我們仍然是“一個團隊”。但我們開發不同的應用程序，通過發消息交流或者不溝通。我強烈建議一個小組按照不同的想法和規模分開（7個人的團隊，我認為分成 4 人和 3 人兩個小組是可以接受的），但永遠不要在公司里公開。逐漸的，其他因素會讓團隊規模縮小，這種劃分會變得多此一舉。如果團隊沒有因為其他原因重組，我仍然堅信組內劃分是最好的選擇。
尾聲
引入一門新語言對于任何上規模的組織都是一件需要多年才能完成的事情。自打引入新語言開始，你的責任就永遠不會“結束”。反過來說，你已經開始使用適合這項工作最好的工具。希望所有說過和做過的事情都是值得的。就自己而言，我對自己的選擇感到高興，但我也期待未來的幾年里在“引入新語言”這個話題上能有更多的收獲。
留言列表
