簡介
即使到了 2024 年，TypeScript 發布 12 年後，JSDoc 發布 17 年後，許多人仍然不知道為什麼要在 JavaScript 專案中使用靜態類型工具，即使它已經成為 JavaScript/ NodeJs 社群。
在本文中，我將解釋什麼是 TypeScript 和 JSDoc，以及為什麼您應該在專案中使用其中之一。
TypeScript 和 JSDoc 是允許 JavaScript 進行靜態類型化的工具。請參閱下面的範例。
如您所見，TypeScript 通常比 JSDoc 簡潔，但另一方面，JSDoc 不需要建置步驟，它可以直接與 JavaScript 程式碼中的註解配合使用。
convert-string-to-int.ts（TYPESCRIPT 檔案！）
convert-string-to-int.js（JAVASCRIPT 檔案！）
在談論優點之前，我必須說，無論您讀了多少文章或這些文章有多好，都無法描述使用靜態類型時開發人員的體驗有多好。
沒有人可以用語言或論證來解釋使用具有靜態類型的代碼庫比無類型的代碼庫有多好，即使是最好的詩人也是如此。
我和許多其他人一樣，會嘗試將這種感覺轉化為事實和數據，但我確保這不足以描述確切的感覺。
毫無疑問，這是靜態型別的最大優勢。無論是在避免返工還是在節省金錢方面，都無法用言語來形容它的幫助有多大。
為了快速交付內容（主要是修補程式），我們最終沒有時間編寫單元測試或測試解決方案的所有可能流程。如果您使用純 JavaScript，則無法確保：
您正在使用的所有變數都存在
您使用的所有變數都已宣告
您正在使用該類型允許的方法（例如：您可以在數字變數中使用映射）
如果您正在比較等效變數（您不應該將數字與陣列進行比較）
如果你沒有很好地測試你的程式碼，你將不得不再次修復錯誤，將寶貴的時間花在你以前可能會咳嗽的事情上。由這些事情引起的錯誤聽起來可能很愚蠢，但它們是發生最多的錯誤。
使用靜態類型，您可以確保更安全、更快速的開發，大大減少生產中的錯誤數量，並允許開發人員只專注於真正提供價值的事情：業務邏輯。
大多數遺留專案和雲端密集型專案（您的許多資源都屬於雲端的專案）在本地運行程式碼的過程很困難，或者更糟的是，您必須部署它才能在沒有模擬的情況下執行。
在本地運行事物的過程對於開發人員來說可能非常耗時且疲憊不堪，而能夠避免它可以節省大量資源（時間、金錢、耐心、雲端資源等）。
使用靜態類型，程式碼是非常可預測的，你可以開發一切，知道程式碼的每個部分發生了什麼，並非常容易地追蹤執行情況，這使得你只需要運行程式碼是在開發完成後，真正測試一切是否如預期般運作。
大多數時候（如果不是全部）當我們嘗試編寫有關函數的文件並嘗試添加輸入/輸出的範例時，它眨眼間就會過時。開發人員永遠不會記得更新文檔，Scrum Master 也永遠不想分配足夠的時間來執行此操作。
使用靜態類型，程式碼就是一個即時文件。它永遠不會過時，因為當開發人員更新程式碼時，他們也會更新文件。
在NodeJs 中實作ES 模組之後，許多函式庫開始遷移到這種新的程式碼編寫方式，因此它們的新版本（更安全、可靠、高效能且具有更多功能）與舊版的JavaScript 不相容，這會讓您陷入不安全的過時版本。
猜猜什麼可以與 CommonJs 和 ES 模組相容，而無需更改程式碼中的任何內容（只需配置中的幾行）？沒錯，TypeScript（不幸的是，我認為 JSDoc 沒有這個優勢）。
不必記住某個東西所具有的每個屬性和方法，讓靜態類型和您最喜歡的 IDE 為您做這件事！
這減少了開發時間，因為：
你不必來回查看某物的屬性
您可以只輸入屬性/方法的首字母並按 Enter（或選擇正確的建議，然後按 Enter），它將自動完成
它也避免了單字寫錯，這種情況會導致生產中出現比應有的錯誤更多的錯誤。
在一個專案中，不同的開發人員會編寫程式碼的特定部分，而對於編寫程式碼的人來說似乎非常明顯的部分，對於每個人來說可能並不直觀。
如果其他開發人員致力於另一個人編寫的新事物，他們將必須花一些時間來理解它，然後才能進行任何更改。使用靜態類型可以讓開發人員節省大量時間來理解變數的值和執行流程。
如果編寫程式碼的開發人員離開公司/團隊，影響不會那麼大，因為所有這些文件都直接在程式碼上。易於找到且易於理解。
開發人員還需要減少對結對程式設計的依賴才能在專案上工作，如果專案類型良好且足夠簡單，他們甚至可以在不與專案中的某人交談的情況下進行改進/更改，增加荒謬他們的效率。
根據 Stack Overflow 開發者調查，TypeScript 是最受歡迎的語言之一，這是連續 4 年的結果：
2020：
2021 年：
2022 年：
2023：
JSDoc 沒有出現在調查中，所以我沒有任何數據表明它是一個不錯的選擇。我唯一能說的是 HTMX 正在使用它，但它是一個非常簡單的函式庫。
另一方面，從這項調查中我們可以看出，近年來，開發人員更喜歡 TypeScript，而不是 JavaScript。
您不需要輸入所有內容。 TypeScript 和 JSDoc 可以猜測大多數事物的類型，這使得它比 Java 或 C 等其他語言更容易且更簡潔。
對於 TypeScript，在最壞的情況下，只需使用 any。 any 是百搭類型，它代表任何東西，因此你應該不惜一切代價避免它，但是如果你時間不夠或不想被缺乏所阻礙某種類型，你有這個選擇。
對於 JSDoc，不要評論任何東西，它是純粹的 JavaScript！
我將在它的學習曲線較高部分解釋更多關於它的原因，但我會在這裡劇透一些。
程式碼難以理解的程式碼庫需要重構，而沒有適當文件的程式碼庫（我們同意如果它與程式碼分離就不可能維護）有更多的部分不可能沒有理解就無法理解大量的挖掘和分析時間。
重構不應該因為你的程式碼無法理解而發生，而是因為效能問題或業務邏輯的變化。必須做同樣的事情兩次對每個人都不好：開發者、使用者和投資者。
長期專案由多人參與是很常見的，而且總是需要一些時間（無論是對於新手還是經驗豐富的開發人員）來讓新手精通該程式碼庫。
使用靜態類型，我們可以大幅減少必要的時間，因為開發人員至少可以單獨理解程式碼的基礎知識，並且只需要其他開發人員的幫助來理解更複雜的業務邏輯（如果它們沒有記錄在文件中）代碼，但這是另一篇文章的主題）。
它讓新人更容易加入項目，大大降低他們的學習曲線，並允許他們在專案上工作時破壞某些東西的風險較小，從而提高整個團隊的效率。
TypeScirpt 的唯一缺點是它的建置步驟更加複雜（因為說實話，現在所有 JavaScript 專案都已經有一個建置步驟，所以這只會讓它變得更複雜一點）。
您可能需要適當的插件或適配器來將建置流程與 TypeScript 集成，但現在我們擁有大量成熟且可用於生產的程式庫、插件、工具以及使其工作所需的任何內容。
我不會撒謊，它可能第一次會給你帶來一些麻煩，就像 JavaScript 生態系統中的大多數其他工具一樣，但還不足以超越專業人士。
如果你選擇使用 JSDoc 而不是 TypeScript，TypeScript 的這個唯一缺點就消失了，但出現了一個新的缺點：如果你不使用類別來表示更複雜的類型，JSDoc 就不能很好地處理它們。
靜態類型需要您多寫一些東西，但是學習曲線與您必須編寫的額外: 字串無關，而是與使用它的難度有關該程式碼庫.
如果沒有靜態類型，您需要更多上下文來了解程式碼中發生的情況、變數具有哪些值以及正在應用什麼業務邏輯。
讓我們來看一個例子：
function processOrders(orders) {
// Logic here
}
僅憑這些信息，您可以確定訂單有哪些值嗎？你可能會說它是一個陣列！ ，但你猜怎麼著？您錯了。訂單是一個物件。它有哪些屬性？祝你好運，至少花一分鐘時間查看程式碼來弄清楚。
屬性是可選的嗎？它們總是存在嗎？它們是物件、陣列還是字串？您團隊中的其他成員是否具備這方面的知識，或者編寫此程式碼的人早已不在了？
靜態型別本身減少了學習曲線大量。
使用純 JavaScript，每個從事與流程訂單相關的工作的人都必須經歷相同的流程：
問自己什麼是指令
在流程訂單邏輯中花費大量時間試圖弄清楚
如果需要 processOrders 的特定行為，可能會向其他團隊成員詢問更多詳細資訊並花費時間
讓我們用數字來表示，這樣會更有趣：
一個5人團隊，每人年薪10萬美元
假設他們必須每 6 個月處理一次 processOrders，時間足以忘記具體細節
他們花了 5 分鐘來弄清楚他們需要的一切（是的，我在這裡非常非常樂觀）
一個項目通常有數千個或至少數百個函數，所有這些函數都類似於 processOrders，但我們這裡只考慮一個小項目，只有 10 個函數。
5 位開發人員 * 10 分鐘/年 * 10 個功能 = 每年 500 分鐘
如果每個開發人員每分鐘賺 88 美分，只計算出 10 個函數接收和返回哪些內容就需要花費 440 美元。這是沒有生產力的時間，不會產生任何價值，在最好的情況下，你的神奇項目只有 10 個功能，而不是現實世界中的項目有 數千個 個功能。
現在，使用 TypeScript：
interface Orders {
ids: Array<number>
skipTypes?: Array<string> // Skip orders if they have specific types
}
interface ProcessedOrders {
total: number
success: number // Amount of orders that were succesfully
processed skipped: number // Amount of skipped orders based on input filters
}
function processOrders(orders: Orders): Promise<ProcessedOrders> {
// Logic here
}
我知道這是一個可怕的、不直觀的函數，但這種情況發生在程式碼中。 不應該，但確實如此，所以最好至少將其記錄下來。
與純 JavaScript 版本相反，這裡有您需要了解的所有上下文函數接收和返回的所有內容，無論其是否可選，以及函數的基本原理.
在這一切之後，你仍然可以爭論很多事情，例如 這是一個乾淨的程式碼問題，而不是 JavaScript 的問題！ 或 它缺乏文件 問題，而不是 JavaScript 的問題問題！ ， 但我向你保證，所有這些事情都是不同的 問題，是的，發生在代碼中，我可能會在其他文章中解決這些問題，但不是本文的重點。
這就是 TypeScript 的魔力：你不需要你的函式庫來支援 TypeScript。
您無需任何輸入即可使用該庫，並且它的工作方式相同，但由於使用純 JavaScript 庫會更困難（因為它沒有本文中提到的任何優點），您可能應該考慮使用不同的。
是的。身為開發人員，我們必須每天學習新事物。這是我們工作的一部分。我們來這裡是為了針對問題創建技術解決方案，作為參考，並找出如何解決我們面臨的問題。
學習有很多好處的新東西是值得付出時間的努力。
在了解靜態類型工具對開發有多大幫助之後，並且沒有任何明顯的缺點，沒有辦法否認它對每個人都有多大的好處：開發人員、用戶和公司的財務。
我希望這篇文章可以幫助您理解它並說服您的同伴改善您的開發體驗。
以上是TypeScript（和 JSDoc）與 JavaScript的詳細內容。更多資訊請關注PHP中文網其他相關文章！
