JSDoc を書くかどうかに関係なく、JS のインターフェイスは非常に動的です。この関数は、arguments 和 call などの動的メソッドを使用してさまざまなパラメーター形式を渡すこともでき、受信側のパラメーター リストと一致しない場合もあります。

ドキュメント生成に関しては、JSDoc は確かに高速なドキュメント生成を実現します。ただし、これには、コード モジュールの編成モード、コメントの長さ、開発者のレベルに関してより高い要件があり、自動生成されたドキュメントは、通常、直接管理されているドキュメントほど読みにくくなります (たとえば、Yeoman では、ほとんどの自動生成ドキュメントを処理する場合)説明できない継承関係があります)。

私のビジネス コードでこの機能を使用する必要がありますか? 】 この質問と[単体テストを書くべきか]は、実際には同じ種類の質問です。単体テストと JSDoc を作成することには多くの利点があることは誰もが知っていますが、問題も非常に明白です。それは、コードの量が増加し、開発サイクルが長くなるということです。別のテスト ディレクトリ内の単体テスト コードとは異なり、JSDoc はビジネス コードの長さを直接増加させます (TypeScript 仕様などの新しい Doc メソッドを使用しない限り)。したがって、再利用性が高くない業務コードについては、実際には JSDoc や単体テストを書かなくても全く問題ありません（回答者は比較的小規模な工場をいくつか勤務しており、実際の業務コードは各フロントエンドで実装する必要があります）。そもそも、基本的にテーブル検索に基づいたバックエンドのポジションについては、ヌードル コードを作成する必要はありません。データを返すと、それぞれの仕様を記述するのが簡単になります。車輪を再発明して再利用可能なコード モジュールを公開する場合、完全な JSDoc と単体テストはモジュールの保守性に有益であり、ユーザーに「コードの品質が非常に優れている」と感じさせることもできます。

簡単に言うと、できるだけ早く JSDoc を開始することが重要であり、残業をしないでください。