ライブラリを使用せずにタスクを実行できる場合、ライブラリを使用する必要がありますか？[閉まっている]

私は、オープンソースのJavaScriptプラグインを使用してタスクを遂行できる状況にあります。しかし、それを使用しようとしたとき、私はすでにやったことの多くを再設計する必要があることに気づきました。きれいなコードで同じタスクを達成できるのに対し、自分で作成でき、これまでに行ったことを変更する必要はありません。

とにかく、このような状況ではライブラリを選択する必要がありますか（コードの品質を向上させるためなど）。

エンジニアとして、おそらくこれを最適化の問題と考えるのが適切でしょう。当然、最適化の目標が必要です。この種の状況の一般的なものは総所有コストを最小にすることでしょう。

サードパーティのコンポーネントを追加すると、長期的にコストを節約できると思われる場合は、それを使用する必要があります。そうでない場合は、すべきではありません。継続的なメンテナンスのコストを考慮してください（たとえば、O / Sの新しいバージョンがリリースされたとき、セキュリティの欠陥が見つかったとき、または新しいW3C仕様がリリースされたとき）。

多くの些細な問題については、独自に成長させる方がコストは低くなりますが、組織のコアコンピテンシー以外のやや複雑な問題については、サードパーティに行くのが理にかなっています。

考慮すべき他の目標（リスクなど）もありますが、TCOが大きな目標です。

ビルゲイツはかつて有名に言った：

「コードの行でプログラミングの進捗を測定することは、航空機の建物の進捗を重量で測定するようなものです。」

最終的にライブラリの数についても同じことが言えるため、この引用が思い浮かびます。原則として、次の場合を除き、ライブラリは使用しません。

1. それを成し遂げる他の方法はありません。期限なしに予算内で製品を生産することは、経済的に実行不可能になります。
2. このライブラリの多くの機能が必要になるため、時間を大幅に節約できます
3. ライブラリはよく使用されており、潜在的な問題は文書化されています。

理想的には3つの条件すべてが満たされていますが、私は任意の2つで解決します。一番下の行は、目的に役立つ場合を除き、プログラムにライブラリを追加しないでください。その目的を尋ねる必要がある場合、おそらくプログラムに追加するべきではありません。したがって、プログラムのコード品質は、プログラム内のライブラリを必ずしも書き換える必要性に圧倒されることなく、各ライブラリをエレガントに呼び出すため、メリットがあります。

がんばろう！

（注：元の質問は次のとおりでした：ライブラリの数はコード品質を改善しますか？）

たぶん、あなたはそれを自分で答えることができるでしょう：いいえ、もちろん、ライブラリを使うという単なる事実はあなたのコードを改善しません。もしそうなら、努力なしですべてのための素晴らしいコードを書くことは簡単でしょう。

自分でロールオーバーするよりも再利用することを推奨するとき、人々が意味するのは、有名なライブラリのコードは、著者がより多くの時間を費やしているという理由だけで、おそらくあなたが思いつくものよりも正確で、効率的かつ/または使いやすいということです（プロジェクト全体の締め切りが）あなたが余裕があるよりも、機能の特定の領域について。

しかし、それはただの傾向であり、法律ではありません。もちろん、自分でロールするほど便利ではないライブラリもあります。多くの場合、これは、ライブラリが実際に必要なものよりもはるかに多くのことを行い、独自のコードベースを合理的なものよりもはるかに慣習に合わせるように強制するときに起こります。これはまさにこのインスタンスで見つけたもののように見えます。

適切なライブラリを使用すると多くの作業を節約できますが、多くの隠れたコストもあります。

• 図書館は最新の状態に保つ必要があります。定期的に更新プログラム（セキュリティ関連の可能性があります！）があるかどうかを確認し、適用する必要があります。ライブラリを更新するたびに、アプリケーションの何かが壊れる可能性があります。つまり、後で完全な統合テストを実行する必要があります。したがって、プロジェクトが依存するすべてのライブラリは、長期的なメンテナンスのオーバーヘッドを増加させます。
• 一部のJavascriptライブラリは非常に強力で、独自のパターンを使用しているため、人々はそれらを別個の専門技術分野として認識し始めています。したがって、追加する各ライブラリは、馴染みのないフレームワークに依存するコードの編集に自信がないと感じる開発者を怖がらせるかもしれません。使用するすべてのライブラリに精通している新しいメンテナンスプログラマを採用するのは困難な場合があります。
• ライブラリをWebサイトに追加すると、ライブラリの一部しか使用しなくてもユーザーがライブラリ全体をロードする必要があるため、ロード時間が長くなります。ダウンロードカスタムは、あなたが必要とする機能だけで構築するためにいくつかの人気のあるライブラリがあなたを許す、それでもあなたはまだ（実行されません多くのコードが含まれ、通常ますかさらに悪い：コードず実行されますが、何も有効ではありません、使用しない機能のためにデータ構造を準備するだけですから）。

したがって、プロジェクトに別の依存関係を追加して、自分で作成できるものを含める前に、コスト/利益分析を実行します。

これは、バイナリの決定である必要はありません。OSSライブラリのみを使用するか、新しいソリューションをゼロからプログラミングします。ライセンスで許可されている場合は、ライブラリの一部を再利用することもできます。

たとえば、私の分野（数値ソフトウェア）では、ライブラリにすばらしいコアモジュールと、80％しか満足していない特殊なモジュールを含めることができます。したがって、コアモジュールを使用し、特殊なモジュールのラッパーを作成します。または、OSSモジュールの設計とコードを使用して、独自の特殊なモジュールを開発することもできます。最も困難なアルゴリズムビットは通常、それらから再利用され、足場コードのみが変更されます。元のコードの一部をクリーンアップすることもできます。これは、ゼロからの開発と比較して、優れた学習体験と時​​間の節約を証明しています。

誰かがすでにあなたのために仕事をしているなら、もちろんあなたはそれを使うべきです。

ルールの例外はjavascriptです。彼らは言語を追加するためにダース他のライブラリ（当然の時代遅れのバージョン）をインポートしているだろうどこに備えて、彼らが使用したいと、その後、あなたのために仕事をして。

フレームワークを選択して、その中にとどまります。ライブラリがフレームワークまたはプレーンjsで動作する場合は、問題ありません。ただし、別のフレームワークが必要な場合は、別のオプションを探してください。

ライブラリとそれらをいつ使用するかは複雑な決定です。

一方で、あなたはよくテストされた、ほぼ標準的なもの（私の分野では、例えばFFTWはこのカテゴリーに分類されます、またはlibsndfileのようなもの）。誰もが使用します。

一方、githubからはランダムなものがありますが、テストスイートはなく、メンテナーは1人しかいません。

私にとっての酸のテストは、最初にライブラリが私のアーキテクチャに適合するかどうかです（時には、特定のライブラリを使用することを知っている場合は、その周りに設計することになります）。 ？2番目の質問に対する適切なプロキシは、「自動化されたテストスイートがあり、ドキュメントはどのようなものですか？」です。

少しのデバッグは大きな問題ではありませんが、その時点で、ライブラリコードはメンテナンスの観点から自分のコードサイズにカウントされ始めます（何らかの理由で修正をアップストリームにプッシュできない場合）。

また、ライブラリとフレームワークを区別しますが、その違いは時には明確ではないため、私の（小さなコア、DSPヘビー）世界のフレームワークは、特にあなたがより多くをマージしようとしている場合、行の少し外側で何かをしたり、ライブラリを使用すると便利な場合があります。これは、Web開発シーンで非常に異なって見られることを知っています。

結局のところ、それは好みと経験に帰着する決定であり、経験のある人でさえ、少なくともライブラリーを使って、時々貧弱な選択をします。

決定、決定...