作者丨Tom Hacohen

編譯丨千山

我寫軟件已經有20多年了，隨著時間的推移，我越來越確信強靜態類型不僅是一個好主意，而且幾乎總是正確的選擇。

非類型化語言(或語言變體)肯定有用途，例如，當使用REPL時，或者在已經無可救藥的無類型環境(例如shell)中使用一次性腳本時，它們會更好。然而，在幾乎所有其他情況下，強類型都是首選。

不使用類型是有好處的，比如更快的開發速度，但與所有的好處相比，它們就顯得微不足道了。對此，我要說：

編寫沒有類型的軟件可以讓你全速前進——全速沖向懸崖。

關于強靜態類型的問題很簡單:你是愿意多做一點工作，在編譯時檢查不變量(或非編譯語言的類型檢查時間)，還是愿意少做一點工作，在運行時強制執行它們，或者更糟糕的是，即使在運行時也不強制執行(JavaScript，我在看著你…)。

在運行時出錯是一個糟糕的想法。首先，這意味著在開發過程中你不會總是抓住它們。其次，當你抓住他們的時候，它會以面向客戶的方式發生。是的，測試有幫助，但是考慮到無限的可能性，為每一個可能的錯誤類型函數參數編寫測試是不可能的。即使可以，擁有類型也比測試錯誤類型容易得多。

1、類型導致更少的錯誤

類型還為代碼提供注釋，使人類和機器都受益。擁有類型是一種更嚴格地定義不同代碼段之間協定的方法。

請考慮以下四個示例。它們都做完全相同的事情，只是契約定義級別不同。

// Params: Name (a string) and age (a number).
function birthdayGreeting1(...params) {
    return `${params[0]} is ${params[1]}!`;
}

// Params: Name (a string) and age (a number).
function birthdayGreeting2(name, age) {
    return `${name} is ${age}!`;
}

function birthdayGreeting3(name: string, age: number): string {
    return `${name} is ${age}!`;
}

第一個甚至沒有定義參數的數量，因此如果不閱讀文檔，很難知道它的作用。我相信大多數人都會同意第一個是令人討厭的，不會寫這樣的代碼。雖然它的思想與類型非常相似，但它是關于定義調用者和被調用者之間的契約。

至于第二個和第三個，由于類型的原因，第三個將需要更少的文檔。代碼更簡單，但不可否認，優點相當有限。好吧，直到你真正更改這個函數前......

在第二個和第三個函數中，作者假設年齡是一個數字。因此，更改代碼絕對沒問題，如下所示：

// Params: Name (a string) and age (a number).
function birthdayGreeting2(name, age) {
    return `${name} will turn ${age + 1} next year!`;
}

function birthdayGreeting3(name: string, age: number): string {
    return `${name} will turn ${age + 1} next year!`;
}

問題是使用此代碼的某些位置接受從HTML輸入（因此始終是字符串）收集的用戶輸入。這將導致：

> birthdayGreeting2("John", "20")
"John will turn 201 next year!"

雖然類型化版本將無法正確編譯，因為此函數將年齡除外，否則年齡是數字，而不是字符串。

在調用方和被調用方之間建立協定對于代碼庫非常重要，這樣調用方就可以知道被調用方何時更改。這對于開源庫尤其重要，因為調用方和被調用方不是由同一組人編寫的。沒有這個合同，就不可能知道事情在發生時是如何變化的。

2、類型帶來更好的開發體驗

IDE和其他開發工具也可以使用類型來極大地改善開發體驗。如果你的任何期望是錯誤的，你將在編寫代碼時得到通知。這大大降低了認知負荷。你不再需要記住上下文中所有變量和函數的類型。編譯器將與你同在，并在出現問題時告訴你。

這也帶來了一個非常好的額外好處：更容易重構。你可以相信編譯器會讓你知道你所做的更改（例如上面示例中的更改）是否會破壞代碼中其他地方所做的假設。

類型還可以使新工程師更容易加入代碼庫或庫：

• 他們可以遵循類型定義來了解事物的使用位置。
• 修改東西要容易得多，因為更改會觸發編譯錯誤。

讓我們考慮對上述代碼進行以下更改：

class Person {
  name: string;
  age: number;
}

function birthdayGreeting2(person) {
    return `${person.name} will turn ${person.age + 1} next year!`;
}

function birthdayGreeting3(person: Person): string {
    return `${person.name} will turn ${person.age + 1} next year!`;
}

function main() {
  const person: Person = { name: "Hello", age: 12 };

  birthdayGreeting2(person);

  birthdayGreeting3(person);
}

很容易查看（或使用IDE查找）所有使用過的位置。你可以看到它被啟動，你可以看到它被使用。然而，為了知道它的用途，你需要閱讀整個代碼庫。

這樣做的另一方面是，在看的時候，很難知道它期望a作為參數。其中一些問題可以通過詳盡的文檔來解決，但是：(1)如果使用類型可以實現更多的功能，為什么還要費心呢?(2)文檔過時，這里的代碼是document。

這與你不編寫代碼的方式非常相似：

// a is a person
function birthdayGreeting2(a) {
    b = a.name;
    c = a.age;
    return `${b} will turn ${c + 1} next year!`;
}

你可能希望使用有用的變量名。類型也是一樣的，它只是steriods上的變量名。

3、我們對類型系統中的所有內容進行編碼

在Svix，我們喜歡類型。事實上，我們嘗試在類型系統中對盡可能多的信息進行編碼，以便在編譯時捕獲所有可以在編譯時捕獲的錯誤；同時也要壓縮開發者體驗改進的額外里程。

例如，Redis是一個基于字符串的協議，沒有固有的類型。我們使用Redis進行緩存(以及其他功能)。問題是，我們所有的優秀的類型優勢將在Redis層丟失，并且可能發生bug。

考慮下面這段代碼：

pub struct Person {
    pub id: String,
    pub name: String,
    pub age: u16,
}

pub struct Pet {
    pub id: String,
    pub owner: String,
}


let id = "p123";
let person = Person::new("John", 20);
cache.set(format!("person-{id}"), person);
// ...
let pet: Pet = cache.get(format!("preson-{id}"));

代碼片段中有幾個bug：

• 第二個鍵名稱有個拼寫錯誤。
• 我們正在嘗試將一個人裝入寵物類型。

為了避免這樣的問題，我們在Svix做了兩件事。首先，我們要求鍵是某種類型的(不是泛型字符串)，要創建這種類型，需要調用一個特定的函數。我們做的第二件事，是將鍵與值強制配對。

所以上面的例子看起來像這樣：

pub struct PersonCacheKey(String);

impl PersonCacheKey {
    fn new(id: &str) -> Self { ... }
}

pub struct Person {
    pub id: String,
    pub name: String,
    pub age: u16,
}

pub struct PetCacheKey;

pub struct Pet {
    pub id: String,
    pub owner: String,
}


let id = "p123";
let person = Person::new(id, "John", 20);
cache.set(PersonCacheKey::new(id), person);
// ...
// Compilation will fail on the next line
let pet: Pet = cache.get(PersonCacheKey::new(id));

這已經好多了，并且不可能出現前面提到的任何錯誤。雖然我們可以做得更好！

請考慮以下函數：

pub fn do_something(id: String) {
    let person: Person = cache.get(PersonCacheKey::new(id));
    // ...
}

它有幾個問題。首先是不太清楚id應該用來做什么。是一個人嗎?一個寵物嗎?很容易意外地用錯誤的名稱調用它，就像下面的例子一樣

let pet = ...;
do_something(pet.id); // <-- should be pet.owner!

第二，我們正在失去可發現性。很難知道寵物與人有關系。

因此，在Svix，我們為每個類型都有一個特殊的類型，以確保沒有錯誤。調整后的代碼如下所示：

pub struct PersonId(String);
pub struct PetId(String);

pub struct Person {
    pub id: PersonId,
    pub name: String,
    pub age: u16,
}

pub struct Pet {
    pub id: PetId,
    pub owner: PersonId,
}

這確實比我們之前的例子要好得多。

4、那么為什么不是每個人都喜歡類型呢？

反對類型一方論證的主要依據是：

• 開發速度
• 學習曲線和類型復雜性
• 所需的工作量和樣板

首先，我認為即使上述所有情況都是真的，上面提到的優勢也值得麻煩。

首先是開發速度。沒有類型的原型設計肯定要快得多。你可以注釋掉代碼片段，并且不會讓編譯器向你抱怨。你可以為某些字段設置錯誤的值，直到你準備好找出正確的字段等。

雖然就像我上面說的：“編寫沒有類型的軟件可以讓你全速前進。全速向懸崖走去。”問題在于，這只是激進且不必要的技術債務。當你需要調試代碼無法正常工作的原因時（無論在本地、測試套件或生產環境中），你都需要多次支付這筆費用。

至于學習曲線：是的，學習更多的東西需要時間。不過我得說，大多數人不需要成為類型專家。他們可以使用非常簡單的類型表達式過日子，并詢問他們是否曾經遇到瓶頸。然而，如果你讓事情保持簡單，你可能很少會碰到一個。

此外，人們已經被要求學習如何編碼，學習框架（React，Axum等），以及許多其他東西。我認為學習負擔并不像人們想象的那么重。

最后，但并非最不重要的是，關于學習曲線：我堅信，不必了解類型而減少學習曲線的好處遠遠小于在特定代碼庫上使用類型腳本的好處。特別是因為學習類型是一次性的成本。

最后一點是關于在代碼庫中使用類型所需的工作量和樣板。我堅信，比起不寫類型所需要的工作量，這種工作量實際上要少得多。

不使用類型需要大量的文檔和測試，才能達到基本的健康水平。文檔可能會過時，測試也會過時；無論哪種方式，它們都比添加正確的類型需要更多的努力。閱讀帶有類型的代碼也更容易，因為你可以內聯獲取類型，而不是在函數文檔中獲取類型，在函數文檔中，它的格式不一致，并且增加了很多干擾。

是的，在不支持推理的語言中，類型可能是一種痛苦，例如Java可能很乏味：

Person person1 = newPerson();
Person person2 = newPerson();
Person child = makeChild(person1, person2);

而其他具有推理功能的語言（如 Rust）則要好得多：

let person1 = new_person();
let person2 = new_person();
let child = make_child(person1, person2);

因此，擁有合適的工具肯定會有所幫助。說到工具，為了獲得類型的好處，你可能需要使用支持語言感知的現代代碼完成的代碼編輯器（或 IDE）。

5、結語

我可以在許多話題上看到雙方的爭論，比如vs.，制表符vs.空格，甚至更具爭議性的主題。盡管在這種情況下，與收益相比，成本是如此之低，以至于我不明白為什么有人會選擇不使用類型。我不知道自己忽略了什么，我只知道，強類型是我愿意死在上面的一座山。

參考鏈接：https://www.svix.com/blog/strong-typing-hill-to-die-on/