Slack桌面端工程師Felix Rieseberg撰文介紹了Slack從JavaScript切換至TypeScript充滿挑戰，但也獲得了巨大收益的過程。
為了簡化大型JavaScript代碼庫的管理工作，在放棄使用JSDoc進行函數簽名的記錄，以及相關用途的描述后，Slack團隊決定切換至TypeScript。Rieseberg專門提到，對于現有代碼庫，很難應用JSON的方法，因為這需要對代碼的修改制定嚴格的約束，但實際上通常可能根本無法輕松地了解預期的類型到底是什么，例如一個Ppromise所要解決的到底是什么問題。
Slack團隊選擇TypeScript的原因之一在于，TypeScript是JavaScript的超集，因此無須更改現有代碼即可使用，并能在采用后逐漸啟用其代碼分析功能，包括很多流行的軟件包中提供的類型定義。隨著時間的流逝，他們稍后還可以啟用高級編譯器選項，例如--noImplicitAny，借此防止編譯器就any類型進行推斷。Rieseberg說他們花了大約六個月的時間為大部分桌面應用的代碼添加注解，在這個過程中，編譯器發現了很多Bug，并且他們通過諸如自動補全等高級編輯功能大幅加快了開發速度。
InfoQ就這一過程采訪了Rieseberg。
您提到才用了循序漸進的方法來啟用TypeScript的編譯器選項。能否詳細說說哪些選項可以在一開始就啟用，哪些選項需要在對原有代碼進行更多調整之后才能啟用？
我認為，any類型是將我們的代碼庫遷移至TypeScript最強有力的理由之一。該類型可以讓我們循序漸進地將any聲明穩步替換為更具體的類型和接口。隨著使用類型數量的增加，我們遲早會從這種交集與合并的類型所提供的抽象中獲益，而這些問題原本是新接觸類型系統的開發者最頭疼的。在我個人看來，循序漸進地采用TypeScript，這種方法的可行性主要源自它可以接納現有的JavaScript。TypeScript會試圖理解你的代碼，并盡可能為你的開發工作提供支持，但就算你沒時間將自己的整個代碼庫一次性移植完成，TypeScript也能讓人受益匪淺。
從一種動態的類型切換至一種嚴格類型的語言，通常可以借機重新設計某些東西。Slack遇到過這種情況嗎？
我們向著TypeScript的轉換主要是由開發者OJ Kwon負責的，他在加入團隊后很快就開始進行了。他發現這一過程中有很多機會可以讓我們完善現有代碼庫。尤其是移植到TypeScript的過程可以幫助我們更好地理解架構內部的數據流動，但從更大范圍來說，回顧現有代碼始終是一種重新思考所采取的具體方法的好機會。
從語言的層面上來說，TypeScript的哪些功能對于你們構建表達式類型系統最有幫助？
我最喜歡聲明合并（Declaration merging），這個功能可以讓我們重用現有類型和聲明，借此表達我們所要實現的目標。此外雖然關注度略低，但我們的代碼庫中還大量用到了字符串字面量（String literal）類型。
您剛才強調說，TypeScript最大的優勢之一在于它是JavaScript的超集。從另一方面來看，這也意味著無法完全確信你從應用的純JavaScript層所獲得的任何東西。對此您是怎么看的？這是否會造成什么問題？
有必要指出一點，圍繞TypeScript還有一個名為Salsa的項目，這是一種開發服務器，可以在使用JavaScript時提供類似于TypeScript的體驗。正是該項目的引擎幫助Visual Studio Code理解JavaScript。開發過程中我們配合使用了TypeScript、聲明文件，以及Salsa，結果還不錯。我個人很喜歡TypeScript對聲明文件的處理方法。
閱讀英文原文：Moving from JavaScript to TypeScript at Slack
京公網安備 11010502049343號