TypeScript (および JSDoc) と JavaScript の比較

はじめに

TypeScript のリリースから 12 年、JSDoc のリリースから 17 年が経過した 2024 年でも、静的型指定ツールが JavaScript/ NodeJs コミュニティ。

この記事では、TypeScript と JSDoc とは何か、プロジェクトでどちらかを使用する必要がある理由について説明します。

彼らは何ですか

TypeScript と JSDoc は、JavaScript で静的型付けを可能にするツールです。両方の例については、以下を参照してください。

ご覧のとおり、TypeScript は通常、JSDoc よりも冗長ではありませんが、一方で、JSDoc はビルド ステップを必要とせず、JavaScript コード内のコメントを直接処理します。

TypeScript

文字列を int.ts に変換 (TYPESCRIPT ファイル!)

JSDoc

文字列を int.js に変換 (JAVASCRIPT ファイル!)

長所

利点について話す前に、どれだけ多くの記事を読んでも、それらの記事がどれほど優れていても、静的型付けを使用すると開発者のエクスペリエンスがどれほど向上するかを説明する方法はないと言わなければなりません。

誰も、たとえ最高の詩人であっても、型付けされていないコードベースよりも静的型付けを備えたコードベースを使用することがどれほど優れているかを言葉や引数で説明することはできません。

他の多くの人と同様に、私もこの感情を事実とデータに変換しようとしますが、正確な感情を説明するにはそれだけでは十分ではないことを保証します。

本番環境でのエラーを回避する

これは間違いなく、静的型付けの最大の利点です。やり直しの回避とコストの節約の両方の点で、これがどれほど役立つかを説明するには言葉が足りません。

主にホットフィックスを迅速に出荷するために、単体テストを作成したり、ソリューションの考えられるすべてのフローをテストしたりする時間がなくなります。純粋な JavaScript を使用する場合、次のことを保証する方法はありません。

• 使用している変数はすべて存在します

• 使用しているすべての変数が宣言されています

• その型に許可されたメソッドを使用しています (例: 数値変数でマップを使用できます)

• 同等の変数を比較している場合 (数値と配列を比較すべきではありません)

コードのテストが十分にできていない場合は、バグを修正するために再度コードに取り組む必要があり、以前なら無駄にできた作業に貴重な時間を費やすことになります。これらによって引き起こされるバグは愚かに聞こえるかもしれませんが、最も多く発生するのはこれらのバグです。

静的型付けを使用すると、より安全かつ迅速な開発が保証され、本番環境でのバグの量が驚くほど減り、開発者は本当に価値をもたらすもの、つまりビジネス ロジックだけに集中できるようになります。

不必要なテストは不要

ほとんどのレガシー プロジェクトとクラウド集約型プロジェクト (多くのリソースがクラウド専用であるプロジェクト) には、コードをローカルで実行するという難しいプロセスがあり、さらに悪いことに、モックなしで実行できるようにコードをデプロイする必要があります。

ローカルで実行するプロセスは、開発者にとって非常に時間がかかり、疲れる可能性がありますが、これを回避できれば、多くのリソース (時間、お金、忍耐力、クラウド リソースなど) を節約できます。

静的型付けでは、コードは非常に予測可能であり、コードの各部分で何が起こっているかを把握しながらすべてを開発でき、実行を非常に簡単に追跡できるため、コードを実行する必要があるのは 1 回だけです。開発終了後、すべてが期待どおりに動作するかどうかを実際にテストします。

古いドキュメントはありません

ほとんどの場合 (すべてではないにしても)、関数に関するドキュメントを作成し、入出力の例を追加しようとすると、瞬く間に内容が古くなってしまいます。開発者はドキュメントを更新することを決して忘れませんし、スクラム マスターはそのために十分な時間を割り当てたくありません。

静的型付けでは、コードはライブドキュメントになります。開発者がコードを更新すると、ドキュメントも更新されるため、このコードが古くなることはありません。

CommonJs / ES モジュールの問題を回避する

NodeJ での ES モジュールの実装後、多くのライブラリがこの新しいコード記述方法に移行し始めたため、新しいバージョン (安全性、信頼性、パフォーマンスが向上し、より多くの機能を備えたもの) は JavaScript の古いバージョンと互換性がありません。そのため、安全でない古いバージョンが残ってしまいます。

コード内で何も変更せずに (構成内の数行のみ) CommonJs モジュールと ES モジュールの両方と互換性があるものは何だと思いますか?まさに、TypeScript です (残念ながら、JSDoc にはこの利点がないと思います)。

オートコンプリートと書き間違いの回避

何かが持つすべてのプロパティとメソッドを覚えておく必要はなく、静的型付けとお気に入りの IDE に任せましょう!

これにより、次の理由から開発時間が短縮されます。

• 何かのプロパティを調べるために前後に進む必要はありません

• プロパティ/メソッドの最初の文字のみを入力して Enter キーを押すと (または、適切な候補を選択して Enter キーを押すと)、オートコンプリートされます

また、単語の書き間違いも回避できます。これは、運用環境で必要以上にバグを引き起こす原因となります。

知識の損失が少なく、時間を無駄にしない

プロジェクトでは、さまざまな開発者がコードの特定の部分を作成するのが一般的であり、コードを作成する人にとっては非常に明白に見えることでも、誰にとっても直感的ではない可能性があります。

他の開発者が、別の人が書いた新しいものに取り組む場合、変更を加える前に、それを理解するのにしばらく時間を費やす必要があります。静的型付けを使用すると、開発者は変数の値と実行フローを理解するのに多くの時間を短縮できます。

そのコードを書いた開発者が会社やチームを離れても、このドキュメントはすべてコードに直接記述されているため、それほど大きな影響はありません。見つけやすくてわかりやすい

開発者は、プロジェクトに取り組むためにペア プログラミングに依存する必要が少なくなります。ペア プログラミングが適切に型付けされており、十分に単純であれば、プロジェクト内の誰かと会話することなく改善/変更を行うことができる可能性があり、その増加率は異常に増加しています。その効率性。

開発者にとってモダンで魅力的

Stack Overflow Developer Survey に基づくと、TypeScript は最も愛されている言語の 1 つです。4 年連続の結果は次のとおりです:

2020:

2021:

2022:

2023:

JSDoc は調査に含まれていないため、JSDoc が良い選択肢であると言えるようなデータはありません。ただ一つ言えるのは、HTMX が使用しているということですが、非常にシンプルなライブラリです。

一方、この調査から、開発者は近年のほとんどにおいて JavaScript よりも TypeScript を好んでいると言えます。

フレキシブル

すべてを入力する必要はありません。 TypeScript と JSDoc は、ほとんどのものの型を推測できるため、Java や C などの他の言語よりもはるかに簡単で冗長ではありません。

TypeScript の場合、最悪の場合、any を使用してください。 any はジョーカータイプで、何でもを表します。このため、何としても避けるべきです。ただし、時間がない場合や、欠如によってブロックされたくない場合は、タイプの場合は、このオプションがあります。

JSDoc の場合は、純粋な JavaScript なので何もコメントしないでください。

不必要なリファクタリングはもう不要

その理由については、「学習曲線が高い」のセクションで詳しく説明しますが、ここではネタバレを含みます。

理解できないコードを含むコードベースはリファクタリングする必要があり、適切なドキュメントがないコードベース (コードから分離すると保守が不可能であることに同意します) には、それなしでは理解することが不可能となるセクションが大量にあります。多くの調査と分析に時間がかかります。

コードが理解できないという理由でリファクタリングを行うべきではなく、パフォーマンスの問題やビジネス ロジックの変更が原因で行われるべきです。同じことを 2 回実行しなければならないのは、開発者、ユーザー、投資家全員にとって悪いことです。

開発者の独立性の向上

長期にわたるプロジェクトでは複数の人が作業するのが一般的であり、新人がそのコードベースに習熟するには (新人と経験豊富な開発者の両方に) 常にある程度の時間がかかります。

静的型を使用すると、開発者だけで少なくともコードの基本を理解でき、より複雑なビジネス ロジックを理解する場合にのみ他の開発者の助けが必要になるため、必要な時間を大幅に短縮できます (マニュアルに文書化されていない場合)。コードですが、これは別の記事のトピックです)。

これにより、プロジェクトに新人を参加させることが容易になり、彼らの学習曲線が大幅に短縮され、何かを壊すリスクを減らしてプロジェクトに取り組むことができるようになり、チーム全体の効率が向上します。

短所

より複雑なビルドステップ

TypeScirpt の唯一の欠点は、そのビルド ステップがより複雑であることです (実際のところ、最近ではすべての JavaScript プロジェクトにすでにビルド ステップがあるため、少し複雑になるだけです)。

ビルド プロセスを TypeScript と統合するには、適切なプラグインやアダプターが必要になる場合がありますが、現在では、成熟したすぐに運用可能なライブラリ、プラグイン、ツールなど、動作させるために必要なものがすべて揃っています。

嘘をつくつもりはありませんが、JavaScript エコシステムの他のほとんどのツールと同様に、最初はトラブルを引き起こす可能性がありますが、プロを追い越すほどではありません。

TypeScript の代わりに JSDoc を使用することを選択した場合、TypeScript にあるこの唯一の欠点はなくなりますが、新しい欠点が表示されます。クラスを使用して表現しない場合、JSDoc はより複雑な型ではうまく機能しません。

議論の誤りを暴く

学習曲線が高い

静的型付けでは、さらにいくつかのことを記述する必要があります。しかし、学習曲線は、書かなければならない追加の : 文字列とは関係なく、その作業の難しさに関係しています。そのコードベース.

静的型付けを使用しないと、コード内で何が起こっているのか、変数にどのような値があり、どのようなビジネス ロジックが適用されているのかを理解するために、より多くのコンテキストが必要になります。

例を見てみましょう:

function processOrders(orders) {
 // Logic here
}

この情報だけで、注文にどのような値があるかを判断できますか? それは配列です! と言うかもしれませんが、どう思いますか?あなたは間違っている。注文はオブジェクトです。どのような特性を持っていますか?少なくとも 1 分はコードを見て理解してください。

プロパティはオプションですか?それらは常に存在しますか?それらはオブジェクトですか、配列ですか、それとも文字列ですか?あなたのチームの他のメンバーがこの知識を持っていますか、それともこのコードを書いた人はもう亡くなっていますか?

静的型付け自体は、学習曲線を大幅に短縮します。

純粋な JavaScript では、プロセス注文に関連する作業を行う各人は同じプロセスを経る必要があります。

• 命令とは何かを自問する

• processOrders ロジック内でそれを理解するために多くの時間を費やしています

• processOrders の特定の動作が必要な場合は、おそらく他のチームメンバーに詳細を尋ね、時間を費やします

もっと楽しくするために、数字で表してみましょう:

• 5 人からなるチーム、各人が年間 10 万ドルを稼ぐ

• 6 か月に 1 回、processOrders を処理する必要があるとします。これは、特定の詳細を忘れるのに十分な時間です

• 彼らは必要なことをすべて理解するのに 5 分を費やします (はい、私はここでは非常に楽観的です)

• プロジェクトには通常、数千または少なくとも数百の関数があり、それらはすべて processOrders に似ていますが、ここでは関数が 10 個だけの小さなプロジェクトだけを考えてみましょう。

• 5 人の開発者 * 10 分/年 * 10 関数 = 500 分/年

各開発者が 1 分あたり 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 の魔法です。TypeScript をサポートするためにライブラリは必要ありません。

このライブラリは何も入力せずに使用することもでき、同じように動作しますが、純粋な JavaScript ライブラリを使用するのはより困難になるため (この記事で説明した利点がまったくないため)、おそらく次のことを考慮する必要があります。別のものを使用してください。

何か新しいことを学ばなければいけない

はい。私たち開発者は毎日何か新しいことを学ばなければなりません。それは私たちの仕事の一部です。私たちは、問題に対する技術的な解決策を作成し、参考にし、直面している問題を解決する方法を見つけるためにここにいます。

非常に多くのメリットがある新しいことを学ぶことは、時間を価値あるものにする努力です。

結論

静的型付けツールが開発にどれほど役立つかを知れば、それに対する重大なデメリットはなく、開発者、ユーザー、会社の財務など、すべての人にとって静的型付けツールがどれほど有益であるかを否定する方法はありません。

この記事がそれを理解し、ペアを説得して開発経験を向上させるのに役立つことを願っています。

以上がTypeScript (および JSDoc) と JavaScript の比較の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。