工程師親述在 Google 從事 TypeScript 工作的獨家體會！

【CSDN編者按】多年來，Google為了開發大型JavaScript應用程序而構建了大量基礎架構。

今天，就來聽聽在TypeScript上工作了兩年多的Google軟體工程師Evan Martin，對此有什麼心得體會吧！

我已經在TypeScript上工作了兩年多了，所以我想寫一兩篇文章來回顧這兩年的工作。首先，我應該寫一個標準的免責聲明：我只是一家公司的一個普通的工程師，公司擁有數萬名工程師，肯定會有人對我在這裡表達的觀點持有不同的意見。

谷歌很早就開始做Web應用程序

Google很早就開始做Web應用程序了。我簡直無法相信Gmail發布已經14年了。在當時使用JavaScript是非常瘋狂的做法。Gmail的工程師不得不擔心IE糟糕的垃圾回收演算法，他們需要手動將字元串文字從for循環中提取出來，以避免GC（Garbage collection垃圾回收機制）停止工作。

最近我發現了一個那個時代的設計文檔，他們當時在考慮做我們現在稱為JavaScript「壓縮」的東西，但一些備選工具只能在Windows上使用。在今天看來，這些都難以想像。

這些年，Google為開發大型JavaScript應用程序，構建了大量基礎架構。例如，有一個模塊系統可以讓源文件表述它們的相互依賴性。有一個捆綁程序可以組合併壓縮源文件，生成可以兼容瀏覽器的產品。

另一個程序可以通過可動態載入的入口點來分析應用的依賴關係圖，並分解出公共的塊供其他塊使用。伺服器端的渲染很常見。對於如今的Web開發人員來說，所有這些概念載熟悉不過了，但Google的技術棧很早就有了，而且一直在發展，因此在概念上類似，但具體方面完全不同，Google擁有不同的流程、工具，甚至不同的概念名稱。

還有個例子可以說明並行發展：Google、Facebook和Microsoft各自構建了類似但不兼容的編譯器，這些編譯器向JavaScript添加了靜態檢查。

Google的編譯器常被稱為Closure。（請不要與Clojure語言混淆；為了避免混淆需要說明一下：ClojureScript使用的是Closure編譯器。）

Google的JavaScript堆棧非常棒。有了它的幫助，Google才能編寫並維護可以改變互聯網的web應用程序。（還記得Google地圖發布時，多麼令人震驚嗎？如今製作一個可以拖拽的地圖小部件似乎非常簡單。）

Google地圖的一些技術甚至超越了當今最好的技術。例如，Closure編譯器可能仍然是最複雜的JavaScript優化程序，它能夠執行很多操作，例如利用類型信息優化代碼，跨越熱載入的塊的邊界進行函數內聯，以及在符號層次刪除未使用的代碼等。

Google的JavaScript技術棧也存在一些問題。linter的漸進式發展表明了Closure只不過是個擁有靜態類型的JavaScript，其中新功能是通過注釋引入的。

Closure的語句難以捉摸，速度很慢，有很多Bug，而且如果你不會正確地使用的話，那麼它往往會破壞你的代碼。儘管它是開源的，但也許是正因為這些原因，除了熟悉它的Google員工之外，行業中並沒有廣泛使用到它。

JavaScript在Google內部的反響並不好，我認為部分原因在於我們對工具很挑剔，大家既嫌靜態語言過於繁瑣，又嫌動態語言不可捉摸。

JavaScript出乎意料地流行了起來

與此同時，在Google之外，JavaScript也在不斷發展，甚至出乎意料地流行起來了。我們構建了Chrome，部分原因是為了解決IE的那些垃圾回收Bug，但也因此催生了了v8，再由v8產生了Node.js。

最後導致今天大多數的Web工具都是用JavaScript編寫的，儘管Google習慣用Java構建這種工具。模塊系統（UMD、AMD、CommonJS）迅速發展。（隨之出現了ES6，並發明了自己的模塊系統，但是由於某種原因它與其他所有模塊系統不兼容，唉！）

NPM統一了工具和庫的共享方式。Webpack可以在開發期間，將模塊動態地切換到正在運行的應用程序中。

Google一概沒有用到這個技術。Google的那些經驗豐富的Web開發人員像是生活在另一個時間線中。我們有像SASS這樣的CSS預處理語言，但它不是SASS而且沒有人喜歡它。精心設計的塊分割程序並不能真正支持第三方JavaScript庫，部分原因是這些工具的出現早於JavaScript的庫生態系統。

這都只是歷史。你可以說我們本不應該這麼做，但這麼說卻無法改變現狀。相反，有趣的問題是：接下來我們該何去何從？有幾個選擇。我的觀點肯定是偏向我喜歡的技術。

接下來我們該何去何從

第一個誘人的選擇就是放棄眼前的一切，並從頭開始建造一個沒有JavaScript的新世界。如果我們投入更多精力到GWT（一個將Java編譯成JavaScript的Google項目）或Dart（一個將新語言編譯成JavaScript的Google項目）或WASM，或者你最喜歡的語言：Clojure？Haxe？還是Elm？那麼我們根本不需要擔心JavaScript！

作為PL愛好者，我非常喜歡這個想法。我想仔細分析一下這個想法，但是這篇文章已經夠長了，而且我認為已經有很多關於這方面討論的文章了。

作為反駁，我有一些常見的問題：如果採用一種不同的語言，那麼第一個問題是，這對於我們現有的數百萬行代碼沒有任何幫助——「用新語言從從頭開始重寫」等想法在某些情況下是正確的選擇，但是如何充分利用Gmail工程師的時間是一個很難的問題；第二個問題是，對於我們想聘請的經驗豐富的前端工程師來說，也幾乎沒什麼用。

與重寫一切相對的做法是不改變任何東西。您可能會說，公開的JavaScript世界充滿了業餘和不成熟的代碼。一個優秀的工程師總能適應我們特殊的前端方式，我們總能改進或構建更多自己的工具。

我們構建的應用類型（Google搜索頁面每天可以獲得數十億次點擊）與其他人構建的web應用程序不同，我們的工具既優秀又很有必要性。我非常贊同這種觀點。

我認為在權衡利弊的時候，有一種看法認為建立我們自己的工具很有道理，而另一種看法則認為我們已經遠離主流，我們的工具是一種負擔。

那麼爭論的焦點是我們究竟處在什麼位置，我相信我們不屬於後者。我們為LLVM / Clang做出的貢獻獲益良多，因為我們依賴於C++，但是我們構建自己的LLVM，並不能從中獲得更多額外的價值。

我們應該折中

所以，我覺得我們應該折中，這也是我們的團隊一直在追求的道路：逐步採用一些合理的外部工具，並弄清楚這些工具如何才能與我們現有的代碼庫相互合作。

這項任務並不那麼有趣，因為我們不會只是單純地拋棄歷史遺留的混亂或者「這次做正確的事情」，但我喜歡更謙虛地思考，不要固步自封。

為了Google的JavaScript世外桃源重回大陸，我們要做的第一步是：採用了一個支持良好的靜態檢查器：（1）不是我們自己做的； （2）很流行，同時與我們現有的代碼相似；（3）旨在搭建通往JavaScript的橋樑；（4）旨在支持大規模的開發，這才是我們定製工具的根本原因。而這個工具就是TypeScript。

Closure編譯器的優勢在於優化輸出，而TypeScript具有出色的用戶界面且根本沒有優化。因此這兩個工具可以互補，並且（有些工作）可以結合在一起。

因為TypeScript已經很好用了——畢竟只有這樣我們才會採用它——所以我們獲得了許多採用已有語言的好處，比如IDE風格的代碼自動補齊，以及能夠從StackOverflow獲取答案。

留給我們的主要工作是集成：允許我們的應用程序逐步轉移到TypeScript，而無需從頭開始重寫。我們在與Google的構建系統集成時非常謹慎，我們採用了漸進式編譯，這對大型應用程序至關重要；而且一個模塊中的變更不會影響使用了該模塊的API，也不會導致下游模塊需要重新編譯。

我們與Closure類型/模塊系統的集成意味著ES6 TypeScript模塊可以導入Google模塊系統中的模塊，而且保留了（大部分）類型信息。一家公司成功地使用了我們發布的工具，自動將其整個代碼庫進行了轉換，同時保留他們壓縮後的輸出。

現在Google內部，各個地方都或多或少地使用了TypeScript；如果您使用Google的產品，那麼意味著你已經與一些TypeScript代碼打過交道了。TypeScript本身就是一系列有趣的折衷方案，它將靜態類型的編程語言與自由轉換的JavaScript生態系統進行了平衡。

我們工程師也會這麼做：我們也會做出有趣的妥協，試圖平衡不同的問題。我希望將來可以寫更多關於多年來發現的一些有趣的小事。正如剛開始使用TypeScript時我寫下的這篇文章一樣（http://neugierig.org/software/blog/2016/02/revisiting-typescript.html），我認為TypeScript在設計領域內做出了很好的權衡。

原文：http://neugierig.org/software/blog/2018/09/typescript-at-google.html

作者：Evan Martin，Google的軟體工程師。

譯者：彎月，責編：胡巍巍

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！