轉(zhuǎn)入 TypeScript 做開發(fā)有大半年了，想來(lái)分享一些自己的心得體會(huì)。
第一次學(xué)習(xí)并使用 JavaScript 大概是在07年，當(dāng)時(shí)為了做一個(gè) Web 自動(dòng)化的項(xiàng)目，踏上了我的 JavaScript 之旅，最終以《Web 應(yīng)用自動(dòng)化生成工具的設(shè)計(jì)與實(shí)現(xiàn)》（大概是這么個(gè)名字）這篇論文來(lái)結(jié)束了我的研究生生涯。
那時(shí)候還沒有全棧開發(fā)這一說，不過想想自己似乎10年前就開始了這種工作狀態(tài)。我過往的技術(shù)經(jīng)歷比較復(fù)雜，在我們那個(gè)年代最主要的軟件還是以 Windows C/S 架構(gòu)為主，搞過 Socket 通信、寫過 ARP 病毒，研究過 MFC 的 Thunk 技術(shù)；后來(lái)慢慢又接觸了 C#、Java，還深深記得剛從 DAO 轉(zhuǎn)入到 Hibernate 時(shí)的那種懵逼。
那時(shí)候覺得學(xué)什么都特別的開心，計(jì)算機(jī)專業(yè)學(xué)的還是“科學(xué)”與“技術(shù)”，也沒有“互聯(lián)網(wǎng)行業(yè)”這一說，我們這一行都還叫做“軟件行業(yè)”，培訓(xùn)班都還在教你如何做網(wǎng)頁(yè)。《曉松奇談》里面有一集講歌壇那個(gè)“白衣飄飄的年代”，我覺得2000年-2010年這10年就似乎是我的那個(gè)“白衣飄飄的年代”。那時(shí)候技術(shù)還比較神秘，大家都以研習(xí) Windows Undocumented API 為榮，我記得我還打印了一本 Intel x86 匯編的小冊(cè)子隨身攜帶；那時(shí)候以為掌握了 Hook 就掌控了操作系統(tǒng)，以為會(huì)用 Ethereal 就監(jiān)聽了全世界。
我記得那是一個(gè)午后，我的導(dǎo)師花了兩個(gè)小時(shí)給我講解 JavaScript 的基礎(chǔ)語(yǔ)法。這應(yīng)該算是我從業(yè)多年來(lái)，最快速最密集學(xué)習(xí)的一門語(yǔ)言了。我還依稀記得那“22條軍規(guī)”：
- 變量類型有 numer、string、bool......
- 定義變量用 var
- if & for 跟 C 語(yǔ)言 一樣
- function 跟 C 語(yǔ)言 一樣
- class 的語(yǔ)法是...
- 訪問成員變量必須帶上 this 指針
- 閉包是......
- ......
就這么從頭到尾講完了這10來(lái)?xiàng)l語(yǔ)法，然后導(dǎo)師對(duì)我說：“恩，差不多就這些了，你先開工吧，明天我來(lái)檢查......”。WTF！！！就像駕校司機(jī)剛告訴了你如何啟動(dòng)汽車、如何操作剎車、油門，就對(duì)你說：“差不多了，明天你開車去趟......”。好吧，一個(gè)“老司機(jī)”就這么上路了，反正寫啥都是在寫 BUG。
作為那個(gè)年代的三大神獸語(yǔ)言 C++、C#、Java，我基本上都同時(shí)在寫。不過他們都是 Class First 語(yǔ)言，以面向?qū)ο鬄楹诵模愂且坏裙瘢x一個(gè)類也是各種繁文縟節(jié)（相對(duì)于動(dòng)態(tài)語(yǔ)言來(lái)說）。所以我在第一次見到 JavaScript 這種動(dòng)態(tài)語(yǔ)言時(shí)，我的內(nèi)心是震撼的，猶如從三維世界進(jìn)入到四維世界的那種“宏大”，那種難以描述的“自由”。
為了防止有人噴我，特地做一下說明，不然一堆屁話就來(lái)了：
1、回頭來(lái)看，我如此的震撼并不是因?yàn)?JavaScript 語(yǔ)言本身的精妙，而是因?yàn)閯?dòng)態(tài)語(yǔ)言相對(duì)于靜態(tài)語(yǔ)言的自由程度；
2、我之前的技術(shù)經(jīng)歷主要是在 C++，并未接觸過動(dòng)態(tài)語(yǔ)言；
3、JavaScript 語(yǔ)言也有很多糟粕，不算“優(yōu)秀”的語(yǔ)言，但并不影響我對(duì)它的喜愛；
4、Ruby 也是我喜愛的語(yǔ)言之一。
一個(gè) JavaScript 的類（準(zhǔn)確的講是指模擬 C++ 里同一概念的類），它身上的屬性、方法可以被動(dòng)態(tài)的添加、刪除、修改；一個(gè)函數(shù)可以作為變量到處傳遞，還有 lambda 表達(dá)式，可以直接寫在函數(shù)的參數(shù)里面作為 Callback，這在當(dāng)時(shí)的 C++/Java 里面簡(jiǎn)直不可想象。
在 C++ 里面，底層的很多網(wǎng)絡(luò)庫(kù)都是 C 語(yǔ)言實(shí)現(xiàn)的，所以一個(gè) C++ 的成員函數(shù)是不能直接直接做為 Callback 函數(shù)傳給底層 lib 的，而是要傳遞一個(gè)類的 static 方法，然后再想辦法從這個(gè) static 方法 跳回到成員方法。MFC 的 Thunk 技術(shù)就是在解決這一問題。直至今天在 Java 里面要實(shí)現(xiàn)一個(gè) Callback 還需要寫一大堆 Interface、Listener 什么的，真的是非常繁瑣（Java 8 已經(jīng)支持 lambda 表達(dá)式了，通過引入編譯工具可以在 Android 開發(fā)里面使用，強(qiáng)烈推薦）。
而最最重要的一點(diǎn)就是 JavaScript 的世界觀其實(shí)就是一張 Hash 表，至少我的理解是這樣的。這就是一個(gè) key-value 的世界，所有類、對(duì)象都是 Hash 表，數(shù)組也是。key 就是對(duì)象屬性，value 可以是普通變量，也可以是函數(shù)，也可以是一個(gè)對(duì)象，等等。只是恰好如果 value 是一個(gè)變量，我們習(xí)慣稱它為成員屬性，如果 value 是一個(gè)函數(shù)，我們習(xí)慣稱它為成員函數(shù)。而 Prototype 原型鏈也只不過是 Hash 表的一種存儲(chǔ)結(jié)構(gòu)，原型鏈查找也就是一種 Hash 查找算法而已。
10年前，用了一個(gè)下午愛上了 JavaScript，而10年后又遇上了 TypeScript。這10年中大部分時(shí)候還是在用 C++ 和 Java 來(lái)工作，所以 JavaScript 的一些痛苦，感受并沒有像 “職業(yè)”開發(fā)者那樣深，不過也還是遭遇到了不少的坑。變量不用定義就能用，偶爾代碼寫錯(cuò)一個(gè)字就成了一個(gè)新變量，為此卻要付出大量的 debug 時(shí)間；早期調(diào)試也相對(duì)比較痛苦，這幾年工具越來(lái)越完善了，不過做為一個(gè)從 Visual Studio 入門的開發(fā)者，看別的平臺(tái)的調(diào)試方法總覺得不夠傻瓜。
遇上 TypeScript 雖然沒有10年前遇上 JavaScript 那樣轟轟烈烈，但是也算喜愛有加。遇上 Javascript（遇上動(dòng)態(tài)語(yǔ)言）我覺得解決的是精神生活的問題，而遇上 TypeScript 算是解決了物質(zhì)生活的問題。以前開發(fā) JavaScript 時(shí)的部分臟活累活都可以被消滅了。
這里才剛剛開始
先簡(jiǎn)單科普一下 TypeScript：
TypeScript 是由微軟開發(fā)的一種基于 JavaScript 語(yǔ)法的語(yǔ)言，且已經(jīng)支持了ES6、ES7語(yǔ)法。你可以理解它為 JavaScript 的超集，也可以理解為 JavaScript 的增強(qiáng)版。TypeScript 代碼不能直接運(yùn)行，需要通過編譯器編譯成 JavaScript 文件才能使用，所以依然可以在瀏覽器環(huán)境或者 node 環(huán)境下無(wú)縫使用。
好了，跑題了這么久，我終于要說為什么要從 JavaScript 轉(zhuǎn)到 TypeScript 了，它到底解決了什么問題。
編譯期類型檢查
最最重要的能力就是：
- 編譯期類型檢查
- 編譯期類型檢查
- 編譯期類型檢查
重要的事情要說三遍。有了編譯期類型檢查再也不用擔(dān)心變量寫錯(cuò)名字、錯(cuò)誤的類型賦值、寫掉對(duì)象屬性這些基本問題了。雖然無(wú)時(shí)無(wú)刻都需要書寫類型信息，但是我相信這是值得的。部分 JavaScript 開發(fā)者可能會(huì)覺得有點(diǎn)繁瑣，其實(shí)相信從靜態(tài)語(yǔ)言轉(zhuǎn)到 JavaScript 的開發(fā)者一定會(huì)感覺到非常親切，所以主要還是一個(gè)先入為主的習(xí)慣問題。相對(duì)于這些付出，收益是巨大的。尤其在大型項(xiàng)目里面，后面接手的同事再也不用去“猜測(cè)”一個(gè) Callback 返回的變量到底是什么類型了。
以下是 JavaScript 代碼：
var name; //定義變量
function getName(type) { //定義函數(shù)
return ...
}
class Person { //ES7下的類定義
name = '';
age = 18;
getName() {
...
}
getAge() {
}
}
以下是 TypeScript 代碼：
var name: string; //定義變量
function getName(type: string):string { //定義函數(shù)
return ...
}
class Person { //類定義
private name: string = '';
private age: number = 18;
public getName(): string {
...
}
public getAge(): number {
}
}
大家可以發(fā)現(xiàn)，最基本的語(yǔ)法其實(shí)就是在所有的變量或者函數(shù)的定義時(shí)，在變量名字的后面加多了一個(gè)類型信息。相較于傳統(tǒng)靜態(tài)語(yǔ)言的語(yǔ)法，基本上就是把類型信息從前面移到了后面而已。
我們?cè)賮?lái)看一下調(diào)用代碼：
let name: string = obj.getName() //編譯通過
let name: number = obj.getName() //編譯失敗
let name = obj.getName() //編譯通過
let nameOther: number = name //編譯失敗
- 第一行編譯通過，因?yàn)轭愋鸵恢?/li>
- 第二行編譯失敗，因?yàn)轭愋筒灰恢?/li>
- 第三行編譯通過，因?yàn)?name 沒有指定類型，TypeScript 編譯器會(huì)自動(dòng)推導(dǎo)，認(rèn)為 name 變量也是 string 類型
- 第四行編譯失敗，因?yàn)?name 被推導(dǎo)為 string 類型，而 nameOther 是 number類型，類型檢查失敗。
所以其實(shí)我們可以看到，TypeScript 也并不是無(wú)時(shí)無(wú)刻都必須要寫上類型信息，只要定義時(shí)類型信息足夠豐富，我們也可以選擇性的偷懶。
最近有看到一種言論說：
連 C# 都在拼命動(dòng)態(tài)化，為何要讓 JavaScript 變成一個(gè)靜態(tài)語(yǔ)言？
其實(shí)我覺得這里是有一些誤解的：“靜態(tài)類型檢查并不等于靜態(tài)語(yǔ)言或者說靜態(tài)化”。
動(dòng)態(tài)語(yǔ)言雖然可以在運(yùn)行期動(dòng)態(tài)改變類型，但是一個(gè)變量類型的改變也是受“業(yè)務(wù)需求”影響的。我相信沒有誰(shuí)會(huì)因?yàn)橄矚g炫技而在代碼里面不斷改變一個(gè)變量的類型信息。而大部分時(shí)候，是因?yàn)闃I(yè)務(wù)的需求再配合語(yǔ)言的動(dòng)態(tài)優(yōu)勢(shì)，可以讓一個(gè)變量在不同階段存儲(chǔ)不同類型的數(shù)據(jù)。
我們回憶一下，其實(shí)大部分時(shí)候一個(gè)變量在它生命周期內(nèi)依然是同一種類型一直用到銷毀。只有小部分時(shí)候有那么幾個(gè)變量會(huì)偶爾存儲(chǔ)number，偶爾存儲(chǔ) string；或者在服務(wù)器返回的數(shù)據(jù)里面，根據(jù) errCode，在 json 里面取出余下不同的信息。
所以一言以蔽之就是說：
“即使是動(dòng)態(tài)語(yǔ)言，一個(gè)變量在生命周期內(nèi)，它的類型變化可能性是非常有限的”。
那么 TypeScript 非常好的解決了這個(gè)問題，那就是“聯(lián)合類型（Union）”。相信有過 C 語(yǔ)言基礎(chǔ)的同學(xué)，對(duì) Union 一定不會(huì)陌生。Union 就是說一個(gè)變量可以時(shí)而為 A 類型，時(shí)而為 B 類型，到底是什么類型，這個(gè)由開發(fā)者自行判斷。
這不正好和“服務(wù)器返回的 json 數(shù)據(jù)格式”的情況非常吻合么？我們通過檢查 errCode （在 restful API 下，更提倡用 header 來(lái)返回錯(cuò)誤信息） 來(lái)判斷余下部分應(yīng)該為 Data 域還是是 Error 域。
一個(gè) Union 的變量定義：
let name: number | string;
name = 123; //編譯通過
name = "danney"; //編譯通過
name = true; //編譯失敗
上述代碼編譯成 JavaScript 的 ES5 版本為：
var name;
name = 123;
name = "danney";
name = true;
對(duì)比可以發(fā)現(xiàn)，其實(shí) TypeScript 完全沒有沒有給你帶來(lái)什么學(xué)習(xí)成本和使用不便，它真的是在幫你，幫你檢查類型、幫你排除那些粗心大意的小錯(cuò)誤。
除此之外，在 TypeScript 里面還有很多突破靜態(tài)類型的方法，比如你可以把一個(gè)變量強(qiáng)轉(zhuǎn)為 any 類型，這樣就不受編譯器類型檢查限制了。所以再也不要誤認(rèn)為 TypeScript 把 JavaScript 靜態(tài)化了。
代碼智能提示
習(xí)慣了在 Visual Studio 上的番茄工具，以及 Android Studio 和 XCode 上的智能提示功能，切到 JavaScript 時(shí)，真是有一些不習(xí)慣，雖然目前幾大主流的 Web 開發(fā)工具也有提示功能，但是我覺得還是不夠完善和智能。
畢竟 TypeScript 語(yǔ)言天生是帶有類型信息的，可以完美識(shí)別出一個(gè)對(duì)象的類型，它自身有哪些屬性和方法，然后調(diào)用這些方法時(shí)，也能智能匹配出它的函數(shù)原型。
說到這里就不能不提 Visual Studio Code 了，簡(jiǎn)稱 VSCode。VSCode是微軟新一代的輕量級(jí)跨平臺(tái)開發(fā)工具，雖然也叫Visual Studio，但是我覺得和傳統(tǒng)的 Visual Studio 家族工具已經(jīng)沒有太大關(guān)系了。它更像 WebStorm 或則 Sublime Text 這樣的 Web 開發(fā)工具，輕量級(jí)、跨平臺(tái)，支持各種語(yǔ)言或者平臺(tái)插件，Debug 也很方便。
用 TypeScript 做開發(fā)，基本上 VSCode 就是標(biāo)配了。VSCode 自帶 TypeScript 插件，完美智能提示，類型推導(dǎo)，讓你的開發(fā)效率極大提升。有意思的是 VSCode 和 TypeScript 編譯器也是用 TypeScript 語(yǔ)言開發(fā)的，這就像一個(gè)雞生蛋蛋生雞的問題。很多年前我就是在想 Java 編譯器也是由 Java 語(yǔ)言開發(fā)的，那么最早的 Java 語(yǔ)言又是用什么來(lái)編譯的呢？
其實(shí)答案很簡(jiǎn)單，現(xiàn)代編譯器基本上都不是從零裸寫的，而是先書寫這門語(yǔ)言的“語(yǔ)法描述文件”，然后由“編譯器生成器”來(lái)讀取“語(yǔ)法描述文件”，從而生成一個(gè)“編譯器”。所以無(wú)論是 Java 還是 TypeScript，都是先用別的語(yǔ)言來(lái)創(chuàng)建一個(gè)最基本的編譯器，再用這門語(yǔ)言來(lái)開發(fā)自己的新版編譯器。
JavaScript 混合編程
很多同學(xué)一定擔(dān)心 TypeScript 的生態(tài)環(huán)境不夠豐富，相關(guān)的 lib 不夠多，這一點(diǎn)完全不用擔(dān)心。因?yàn)?TypeScript 和 JavaScript 可以在一個(gè)工程里面混合編程，TypeScript 的文件后綴是 .ts ，JavaScript 的文件后綴是 .js 僅此而已。ts 文件里面依然用 import 或者 require 來(lái)引入一個(gè) module。
唯一的問題就是因?yàn)橐氲?JavaScript 模塊因?yàn)闆]有類型信息，會(huì)導(dǎo)致 VSCode 的智能提示無(wú)法使用而已。有智能提示時(shí)算是一個(gè)補(bǔ)充，沒有智能提示時(shí)我覺得也不算吃虧。
不過其實(shí)這個(gè)問題基本上已經(jīng)解決了，那就是 TypeScript 在編譯為 JavaScript 時(shí)，可以自動(dòng)產(chǎn)生一個(gè)叫做 .d.ts 的文件，它就是 js 的頭文件，和 C 語(yǔ)言的 .h 文件一個(gè)道理。所以當(dāng)一個(gè)編譯后的 TypeScript 作為一個(gè) lib 發(fā)布時(shí)，會(huì)附上 .js 和 .d.ts 兩種文件。這樣別人在導(dǎo)入你的 lib 時(shí)，也會(huì)獲得智能提示功能。
那么對(duì)于一個(gè)基于 JavaScript 開發(fā)的老牌 lib，有沒有辦法也能智能提示呢？答案是肯定的。那就是現(xiàn)在有大量的開發(fā)者在為老牌 lib 人肉編寫 .d.ts 文件。并且微軟提供了一個(gè)叫做 typings 的工具，可以為你在線查找并下載一個(gè) lib 的 .d.ts文件。typings 和 npm 使用類似，最新的 typings 也已經(jīng)統(tǒng)一到 npm 工具上了，即使用 npm 就可以下載 .d.ts 文件了。還有最新版的 VSCode 也能做到自動(dòng)分析你的包依賴，然后后臺(tái)自動(dòng)下載 .d.ts 文件。不用擔(dān)心 JavaScript lib 沒有 .d.ts 文件，連微信小程序的頭文件都已經(jīng)有了。
編譯質(zhì)量
對(duì)于擔(dān)心 TypeScript 編譯質(zhì)量不如人手寫優(yōu)化的同學(xué)，你們也完全不用怕。TypeScript 編譯邏輯主要有兩部分，一部分是去掉類型信息，回歸正常 JavaScript 語(yǔ)法；另外一部分就是翻譯 ES6 和 ES7 語(yǔ)法，我目測(cè)編譯結(jié)果和 babel 基本上一致，所以 babel 的編譯結(jié)果如果你都不擔(dān)心，TypeScript 的編譯結(jié)果也就沒什么好擔(dān)心的了。
但是假如你連整個(gè)編譯過程都覺得不能忍受的話，那一定是你寫的代碼太少。你來(lái)開發(fā) iOS 和 Android 試試 ？當(dāng)年 Windows QQ 編譯一次可是要40分鐘啊，我們一般都是點(diǎn)一下編譯按鈕，然后就去吃飯了。記得以前有從 JavaScript 入門的同學(xué)轉(zhuǎn)去做 Android 開發(fā)時(shí)，狂吐槽分號(hào)的問題，我想說：真的是你見識(shí)的東西太少。可以熱愛 JavaScript，但是不要讓它蒙了你的眼。
調(diào)試
VSCode 提供了完善了調(diào)試工具，非常方便。因?yàn)槲一旧鲜窃?node 環(huán)境下開發(fā)，Web 調(diào)試不好說，不過 node 下再也不用蹩腳的彈到 Chrome 里面去 debug 了。TypeScript 編譯后會(huì)自動(dòng)生成 souremap 文件，所以 debug 時(shí)是不會(huì)涉及到編譯后的 js 源文件的。就好像 C 語(yǔ)言編譯成匯編后，你 debug 時(shí)也不用關(guān)注匯編一樣。
所以另外一個(gè)需要注意的就是團(tuán)隊(duì)開發(fā)時(shí)，如果要修復(fù) bug，千萬(wàn)千萬(wàn)不要修改編譯后的 js 源文件。因?yàn)橹霸诰W(wǎng)上看到有人在吐槽他用 TypeScript 開發(fā)的代碼，編譯成 js 上線后，有同學(xué)吭哧吭哧拿 js 代碼去修復(fù) bug，還一個(gè)勁吐槽原作者。腦子是個(gè)好東西，希望他也有。所以一定要避免在一個(gè)項(xiàng)目里面有的人用 TypeScript 開發(fā)，有的人用 JavaScript 開發(fā)。要么全都用，要么就別用。
其他
相比于 CoffeeScript 等變種 JavaScript 語(yǔ)言，TypeScript 語(yǔ)法幾乎保持不變，沒有什么學(xué)習(xí)難度。說學(xué)習(xí)曲線陡峭或者覺得團(tuán)隊(duì)內(nèi)部不好培訓(xùn)、不好推進(jìn)的，我真心覺得這個(gè)行業(yè)的從業(yè)者素質(zhì)可能確實(shí)需要提升。
其他幾個(gè)不錯(cuò)的新增語(yǔ)法點(diǎn)：
- TypeScript 提供了 enum ，我個(gè)人超級(jí)喜歡
- TypeScript 提供了泛型，解決了不少問題
- TypeScript 支持 JSX 語(yǔ)法，做 ReactJS 和 React-Native 開發(fā)的同學(xué)應(yīng)該會(huì)非常喜歡
差不多就這些了，擁抱 TypeScript 吧，希望你也會(huì)喜歡！
