ライブラリがなくてもタスクを実行できる場合は、ライブラリを使用する必要がありますか？
オープンソースのJavaScriptプラグインを使用してタスクを実行できる状況にあります。しかし、それを使おうとすると、すでにやったことの多くを再設計しなければならないことに気づき、プロジェクトに複雑さを加えてしまいました。クリーンなコードで同じタスクを達成できるのに対し、これまでに行ったことを変更する必要なく、自分で作成できます。
このような状況では、とにかくライブラリを選択する必要があります（コードの品質を向上させるためなど）。
エンジニアとして、これを最適化の問題と考えるのがおそらく適切です。当然、最適化目標が必要です。この種の状況でよくあるのは、 Total Cost of Ownership を最小限に抑えることです。
サードパーティのコンポーネントを追加すると、長期的にコストを節約できると思われる場合は、それを使用する必要があります。そうでない場合は、すべきではありません。継続的なメンテナンスのコストを考慮してください（たとえば、O/Sの新しいバージョンがリリースされたとき、セキュリティの欠陥が見つかったとき、または新しいW3C仕様がリリースされたとき）。
ささいな問題の多くは、自分で問題を拡大する方がコストは低くなりますが、組織のコアコンピテンシーの範囲外にある中程度に複雑な問題の場合は、サードパーティに依頼することが理にかなっています。
他にも考慮すべき目標（リスクなど）がありますが、TCOは大きな目標です。
ビル・ゲイツはかつて有名に言った：
「コードの行ごとにプログラミングの進捗状況を測定することは、航空機の建造の進捗状況を重量で測定することに似ています。」
ライブラリの数についても同じことが最終的に言えるので、この引用が思い浮かびます。原則として、以下の場合を除いて、ライブラリは使用しません。
- それを成し遂げる他の方法はありません。なしでやることは、時間通りに、そして予算通りに製品を生産するのに経済的に実行可能ではなくなります。
- ライブラリの多くの機能が必要になるため、時間を大幅に節約できます。
- ライブラリは十分に使用されており、私が抱えている可能性のある潜在的な問題は十分に文書化されています。
理想的には3つの条件すべてが満たされていますが、私はどの2つでも解決します。結論としては、目的にかなわない限り、プログラムにライブラリを追加するべきではありません。その目的を尋ねる必要がある場合は、おそらくそれをプログラムに追加するべきではありません。したがって、プログラムのコードqualityは、プログラム内のライブラリを必ず書き換える必要性に悩まされることなく、各ライブラリをエレガントに呼び出すため、メリットがあります。
幸運を！
（注：元の質問は次のとおりでした：ライブラリの数はコードの品質を向上させますか？）
あなたはおそらくあなた自身でそれに答えることができます：いいえ、もちろん、ライブラリを使用するという単なる事実はあなたのコードを改善しません。もしそうなら、努力なしですべてのための素晴らしいコードを書くのは簡単でしょう。
自分でロールするよりも再利用を推奨するときに人々が意味することは、著名なライブラリのコードは、おそらく著者がはるかに多くの時間を費やしたために、あなたが思いつくよりも正確、効率的、および/または使いやすいということです。 （プロジェクト全体の期限付きで）あなたが余裕のある特定の機能領域で。
しかし、それは単なる傾向であり、法律ではありません。確かに、自分で作成したロールのように使用するのに便利でないライブラリが存在する可能性があります。多くの場合、これは、ライブラリが実際に必要以上のものを実行し、妥当な範囲をはるかに超えて独自のコードベースを規則に適合させるように強制する場合に発生します。これは、このインスタンスで見つけたものとまったく同じであるように見えます。
適切なライブラリを使用すると多くの作業を節約できますが、隠れたコストもたくさんあります。
- ライブラリは最新の状態に保つ必要があります。あなたは定期的に彼らがアップデートを取得したかどうかをチェックし（セキュリティ関連かもしれません！）、それらを適用する必要があります。ライブラリを更新するたびに、アプリケーションの一部が壊れる可能性があります。つまり、後で完全な統合テストを実行する必要があります。したがって、プロジェクトが依存するすべてのライブラリは、長期的なメンテナンスのオーバーヘッドを増大させます。
- 一部のJavaScriptライブラリは非常に強力であり、そのような独自のパターンを使用するため、人々はそれらを個別の技術分野の専門分野として認識し始めます。そのため、ライブラリを追加するたびに、慣れていないフレームワークに依存する編集コードに自信がない開発者を怖がらせる可能性があります。使用するすべてのライブラリに精通している新しいメンテナンスプログラマを採用することは、困難な場合があります。
- ライブラリをWebサイトに追加すると、ライブラリのごく一部しか使用しない場合でも、ライブラリ全体をロードする必要があるため、ロード時間が長くなります。一部の一般的なライブラリでは、必要な機能のみを備えたカスタムビルドをダウンロードできますが、それでも通常は実行されない多くのコードが含まれます（さらに悪いことに、実行実行されるコードが含まれますが、使用しない機能のデータ構造を準備するだけなので、有用なことは何もありません）。
したがって、プロジェクトに別の依存関係を追加して、自分で記述できるものを含める前に、コスト/利益分析を行ってください。
これはバイナリの決定である必要はありません。OSSライブラリのみを使用するか、新しいソリューションを最初からプログラムするかのどちらかです。ライセンスで許可されている場合は、ライブラリの一部を再利用することもできます。
たとえば、私の分野（数値ソフトウェア）では、ライブラリに細かいコアモジュールと、80％だけ満足しているいくつかの特殊なモジュールを含めることができます。そのため、コアモジュールを使用して、専用モジュールのラッパーを記述します。または、OSSモジュールのデザインとコードを使用して、独自の専用モジュールを開発することもできます。最も困難なアルゴリズムビットは通常、それらから再利用され、足場コードのみが変更されます。また、元のコードの一部をクリーンアップする場合もあります。これは、ゼロからの開発と比較して、優れた学習体験と時間の節約を証明しています。
誰かがすでにあなたのために仕事をしてくれているなら、もちろんあなたはそれを使うべきです。
ルールの例外はjavascriptです。彼らが言語機能を追加するためにダースの他のライブラリ（もちろん時代遅れのバージョン）をインポートした場合they使用したいとthenが作業を行います。
フレームワークを選択して、その中にとどまります。ライブラリがフレームワークまたはプレーンjsで動作する場合は問題ありません。ただし、別のフレームワークが必要な場合は、別のオプションを探してください。
ライブラリとそれらをいつ使用するかは、複雑な決定です。
一方では、十分にテストされたほぼ標準的なもの（私の分野では、たとえばFFTWがこのカテゴリに分類されるか、またはlibsndfileのようなもの）が動作することが一般に認められており、過去20年間、標準的なものでした。誰もが使用します。
一方、あなたはgithubからランダムなものを持っていて、テストスイートはなく、メンテナーは約1人だけです、一般的になぜわざわざ？
私にとってのアシッドテストは、最初にライブラリが私のアーキテクチャに適合するかどうかです（特定のライブラリを使用することがわかっている場合、最終的にはその周りで設計することになります）。他の人のライブラリコードをデバッグすることになるでしょう。 ？ 2番目の質問に適したプロキシは、「自動化されたテストスイートはあり、ドキュメントはどのようなものですか？」です。
少しのデバッグは大きな問題ではありませんが、その時点で、ライブラリコードはメンテナンスの観点から自分のコードサイズに対してカウントし始めます（何らかの理由で修正をアップストリームにプッシュできない場合はさらにそうです）。
ライブラリとフレームワークも区別します。区別が明確でない場合があるため、私の（小さなコア、DSPが重い）世界のフレームワークは、特にそれ以上マージしようとしている場合は、arseで苦痛になる傾向があります。 1つまたは少し外の何かを行う場合、ライブラリが役立つことがあります。これは、Web開発シーンでは非常に異なって見えることを認識しています。
結局のところ、それは好みと経験に帰着する決定であり、経験豊富な人でさえ、少なくともライブラリでは依然として不十分に選択することがあるので、いつでもそれを破棄して、煩わしすぎる場合は独自の実装を書くことができます。
決定、決定...