項(xiàng)目中使用 TypeScript 的一些感悟

pcChao 發(fā)布于2019-08-23 18:32 / 3100人閱讀

摘要：上周發(fā)布了一款名為的工具，是完全采用以下簡稱來開發(fā)的。而使用，可以在一定程度上減少這個問題。自成文檔的特性對于多人維護(hù)的項(xiàng)目來說是非常有用的，它能夠大大降低項(xiàng)目當(dāng)中溝通和理解的成本。作為的超集，我們可以在中放心使用的各種高級能力。

上周發(fā)布了一款名為 Smartour 的工具，是完全采用 TypeScript （以下簡稱 ts）來開發(fā)的。拋開以前做業(yè)務(wù)的時候的不完全使用，這次實(shí)踐可以算是我第一次真正意義上的使用 ts。由于寫法上的不同，以及對不熟悉事物的新鮮感，在這次項(xiàng)目開發(fā)的過程中著實(shí)有著許多感悟，于是打算寫篇小東西好好記錄下來。

TS 能讓人養(yǎng)成“先思考后動手”的好習(xí)慣

在以往的開發(fā)過程中，我的習(xí)慣總是“先想好一個大概，然后邊做邊想再邊改”。這樣的好處是動作比較快，順利的時候效率會很高，但更多的時候是不斷地推翻自己先前的想法，相信不少的人也有跟我類似的體會。

而使用 ts，可以在一定程度上減少這個問題。眾所周知 ts 是強(qiáng)類型的語言，這也意味著它能有效制約開發(fā)者在開發(fā)過程中“隨心所欲”的程度。就以定義一個函數(shù)的參數(shù)為例，可以看看我在寫 js 和 ts 的思考方式上有什么不同。

寫 js 的時候，我的思考過程是這樣的。


首先這個參數(shù)是一個對象，這個對象的屬性 el 是一個 css 選擇器；而對象的屬性 keyNodes 是一個數(shù)組，里面的元素是一系列的 keyNode。
這個所謂的 keyNode 也是一個對象，它也包含了一個 css 選擇器屬性 el，以及一個綁定在 dom 元素上的事件參數(shù) event。
我會把這個參數(shù)對象以注釋的形式寫下來，以便記住它的具體定義。

/**
{
    el: "#demo-id",
    keyNodes: [{
      el: ".item-1",
      event (e) { console.log(e) }
    }]
}
 */
以后任何地方要用到這個參數(shù)，我都要手動保證參數(shù)的結(jié)構(gòu)要和這個注釋保持一致。

而換成 ts 的寫法以后，我的思路是這樣的：


首先這個參數(shù)是一個對象，這個對象的屬性 el 是一個 css 選擇器；而對象的屬性 keyNodes 是一個數(shù)組，里面的元素是一系列的 keyNode。
然后我會通過 interface 把它給定義好：

interface HightlightElement {
    el: string,
    keyNodes: Array
}
interface KeyNode {
    el: string,
    event: EventListener
}
在需要用到這個參數(shù)的時候，只需要在定義形參的時候傳入這個 interface 即可。萬一參數(shù)結(jié)構(gòu)或內(nèi)容的類型有誤，VScode 編輯器都會立刻給予提示，省去了手動檢查的麻煩。
someFunction (param: HightlightElement) { ... }

可以看到，在寫 js 的時候更多的是“自己和自己約定，自己判斷是否遵守了約定”，而 ts 則是“自己和自己約定以后，由第三方（編輯器）去判斷是否遵守了約定”。這樣的好處是除了老生常談的減少錯誤之外，更多的則是對思維上的良性約束。這種良性約束能夠讓我們在思考的階段就定義好接下來要做的一系列事情，在操作的過程中如果發(fā)現(xiàn)任何問題也能夠在第一時間溯源回最初思考的起點(diǎn)，排查問題的時候會更加高效。

TS 擁有自成文檔的特性

在寫 js 的時候，我們依賴注釋去判斷某個變量或參數(shù)的類型、結(jié)構(gòu)和作用。如果沒有了注釋，只能通過閱讀源碼和不斷調(diào)試去搞清楚當(dāng)中的細(xì)節(jié)。許多人在接手他人項(xiàng)目的時候都會有這么一個經(jīng)歷：“為什么不寫注釋！這個函數(shù)寫的啥！這參數(shù)又是啥！”沒有注釋的 js 代碼是讓人崩潰的，但是寫注釋不僅需要時間，更考驗(yàn)一個人的概括能力。說了等于沒說甚至誤導(dǎo)性的注釋，也是足夠讓人崩潰。

在 ts 中，除了注釋以外我們還有另外一個選擇，就是查看某個變量或參數(shù)所對應(yīng)的 interface 接口定義。在 interface 中我們可以很直觀地看到參數(shù)的結(jié)構(gòu)，內(nèi)部屬性的類型，是否為可選等詳細(xì)信息。再加上VScode 的智能提示及跳轉(zhuǎn)，不管是查看他人的代碼還是維護(hù)一個歷史項(xiàng)目，都能更加方便和規(guī)范——畢竟寫接口往往比寫注釋要順手，看接口往往比猜代碼要穩(wěn)妥。

說到自成文檔的特性，我也聯(lián)想到了另外一個熱門技術(shù) GraphQL。借助 GraphQL 社區(qū)配套的一系列工具，調(diào)用方在調(diào)用接口的時候就能直接讀到接口的標(biāo)準(zhǔn)定義；而接口的開發(fā)者也不需要額外編寫文檔，在定義接口的時候其實(shí)就相當(dāng)于把文檔也寫好了。

自成文檔的特性對于多人維護(hù)的項(xiàng)目來說是非常有用的，它能夠大大降低項(xiàng)目當(dāng)中溝通和理解的成本。但是這句話也有一個前提，就是開發(fā)者要遵守并合理工具當(dāng)中的約束規(guī)范，如果一個接口的任何參數(shù)類型都是 any ，那么也就失去了使用 ts 的意義。

TS 能夠降低搭建環(huán)境的時間成本

為了同時使用 js 新穎的特性以及兼容陳舊的瀏覽器，我們往往會借助一系列的工具去搭建一套開發(fā)環(huán)境。也許我們已經(jīng)習(xí)慣了 webpack + babel 的開發(fā)方式，可是又有誰能夠保證自己在不看文檔的情況下能夠自己去搭一套呢？且不說這些工具各有著復(fù)雜的文檔，就算好不容易把環(huán)境搭好了，還會發(fā)現(xiàn)有著更多“最佳實(shí)踐”。改來改去花了一天時間，才終于算是完成。

作為 js 的超集，我們可以在 ts 中放心使用 js 的各種高級能力。由于自帶命令行工具，我們不再需要去研究 babel 或者各種 preset-env 插件，只需要指定需要構(gòu)建的版本，ts 命令行工具就會自動為我們生成對應(yīng)版本的 js。

當(dāng)然這并不是說有了 ts 就能夠完全拋棄構(gòu)建工具了，在構(gòu)建復(fù)雜應(yīng)用（如包含各種靜態(tài)資源，跨格式文件引用）場景的情況下還是離不開構(gòu)建工具的，且在未來很長一段時間都會維持這種狀況。但是秉承著“多一事不如少一事”的原則，只要能夠減少哪怕是一個工具的使用，對開發(fā)者來說都是有好處的，畢竟我們都期待著某一個能夠只管代碼不管環(huán)境的日子。

尾聲

由于不是 ts 的資深玩家，以上的碎碎念都是作為一個初學(xué)者個人的新鮮感。在工作的這些日子里，也深刻體會到永遠(yuǎn)沒有百分百理想化的東西。ts 固然是好，但也需要辯證地看待它。我們是否真的需要 ts？它是否真的能夠提高我們的生產(chǎn)力？它是否真的如他人描述般理想？這些問題都需要經(jīng)過實(shí)踐才能回答。說到底 ts 只是一個工具，什么時候用它，怎么用它，還是取決于具體的場合。一味地尬吹或者否認(rèn)其他的東西，只能說明思想還是太狹隘了。