開発のスピードと品質
既存のライブラリを使用すると、主な機能の開発がはるかに速く完了することは間違いありません。 開発者は、インフラストラクチャなどではなく機能に集中します。
最適なソリューション
ライブラリは通常、非常に普遍的に書かれており、さまざまな問題を解決することを目指しています。 したがって、それらのコードは理解するのがかなり面倒であり、特定のタスクを解決するのに最適なものではありません。 あなた自身の決定の場合、あなたはそれを最も最適な方法で書き、あなたは特定のユースケースのためにそれを特に研ぎます。
虫
ライブラリの場合、多くのユーザーによってテストされたソリューションがあります。 それでもエラーが見つかった場合は、メッセージテキストをGoogleに入力するだけで、間違いを正確に把握できます。 一方、誰もこのエラーに遭遇していない場合、または誰もそれについて書いていないことが明らかな場合は、ここで何かが機能していない理由を見つけるために多くの時間を費やすことができます。 結局のところ、ライブラリコードはかなり面倒で混乱を招く可能性があります。 そのようなライブラリがどのようになるかを示す素晴らしい例がここにあります。 さらに、それを書いたのはあなたではないので、他の誰かのコードを理解するのに長い時間がかかりますが、これには特別なスキルが必要です。 ライブラリがオープンソースであると便利です。そうしないと、サポートと通信するとエラーの検索が長くなる可能性があります。 すべてのコードを自分で書いた場合、それを広く知っているので、エラーを見つけることはこれまで以上に簡単になります。 ここにエラーがありますが、このコードをテストしたのはあなただけなので、かなり多くの可能性があります。 コードを最初から記述したとしても、ライブラリが時間の経過とともに既に識別およびコーディングされているというまれなケースを見失う可能性があります。
チーム
これには2つの側面があります。 最初に、新しい人があなたのチームに来たとき、彼はあなたがライブラリとして使用する技術ですでに働いている可能性が高いです（または、あなたは彼が関連する経験を持っているという条件ですぐに人を雇います）。 独自のソリューションを使用する場合、新しい従業員はその仕組みの詳細を理解する必要があります。 第二に、通常はライブラリで書かれているコード自体を書くのは簡単な作業ではありません。 ここでは、高度な資格を持つ専門家が必要です。そうでないと、コードが先駆者によって書かれた場合、独自のソリューションの他のすべての利点が無駄になります。
各アプローチの長所と短所を要約するには：
図書館
- +迅速な開発
- +膨大な数のユーザーがテストしたコード
- +チームの人々はそれがどのように機能するかを知っています
- +あなたが予見しなかったかもしれない問題を解決します、私は自分でライブラリを実装します
- +プログラマーは、補助ライブラリーではなく機能性に焦点を合わせます
- -多くのクラス、かなり複雑な一般的なアーキテクチャなので、発生するエラーを理解するのは難しい
- -おそらく、それはあなたの特定のタスクに非常に役立つだろう非常に特定のことをしないので、あなたはわずかに異なるものを使用します
- -特定の問題を最適な方法で解決することはできません。これは、内部に他のタスク用の一連のラッパーとフラグが含まれているためです
- -自分でライブラリにパッチを適用する場合、将来のバージョンのアップグレードに問題がある可能性があります
独自の開発
- +チームメンバーは、すべてが詳細に機能する方法を知っています（チームを離れるまで）
- +記述されたコードは最小限であるため、エラーの原因を特定するのは簡単です
- +最も生産的なソリューション
- +必要な方向にライブラリを開発する機能
- -優れたライブラリを作成するには、高度な資格を持つ開発者が必要です
- -長い開発
- -特に実装段階で、十分な数のエラーが含まれています
- -チームの新しい人々は、それがどのように機能するかを知らない
あなたのコメントは大歓迎です。 決定を下す際に他に注意を払う必要があるものを聞くのは興味深いでしょう。