なぜ内部アプリケーション用の内部ライブラリを開発するのですか？

内部アプリケーションの開発専用に使用する内部ライブラリを開発する必要がある理由を理解できません。組織外の誰かが作成したソフトウェアを使用したい場合は、ヘッダーファイルと.aまたは.soファイルを送ってプロジェクトにリンクするだけでよい（同じ環境でコンパイルされていると仮定） 。

しかし、ヘッダーと実装ファイルにアクセスでき、それらをソースツリーに含めてすべて一緒にコンパイルできるときに、内部ライブラリを内部アプリケーションにリンクするためだけに開発する必要があるのはなぜですか？

つまり、ソースコードが記述されている場合、それをバイナリライブラリにコンパイルしてアプリケーションにリンクするか、プロジェクトのソースファイルに含めて定期的にコンパイルするだけにするかをどのように決定しますか？

各プロジェクトに「インクルード」ファイルと言っても、現在開発中のプロジェクトのソースツリーに各ファイルをコピーして貼り付けることを意味するものではありません。通常の方法でプロジェクトのファイルに含めることができる共通のソースコード（#includeなど）を含む（任意のプロジェクトとは別の）ディレクトリ/ライブラリを開発することを意味します。

psここでは、複数のデスクトップアプリケーション用のc / c ++開発について話しています。

内部で使用する場合でも、ライブラリと共有ライブラリを（.dllまたは.soファイルで）作成する理由は数多くあります。

1. プロジェクト間での再利用ははるかにきれいです
2. 責任の分離-コードの一部は、より適切な異なる開発者またはチームである可能性があります
3. 特定のコードを見つけることなく、他のチームが作成したライブラリの改善から利益を得ることができます
4. ビルド時間が短縮されます。ライブラリが安定している場合は、再ビルドする必要はありません。
5. ディスク容量-ライブラリとヘッダーのみをプロジェクトに含めることができます
6. 共有ライブラリを使用すると、複数のプログラムが使用している場合でも、RAMにコピーを1つだけロードすることでメモリを節約できます
7. 一般的に、ライブラリのドキュメントとテストが改善されます。
8. クリーナーの設計とコード-ライブラリに構造化することについての考え方は、各ライブラリにおける機能の関連グループをもたらすべきである、あなたは、汎用コードを分離する傾向があるライブラリに、アプリケーションの仕様から、アプリで。
9. ライブラリに独自のアルゴリズムがある場合は、ソースへのアクセスを制限できます。たとえば、請負業者や外部のチームがソースにアクセスできないようにします。
10. ライブラリのコードは、それが元々の一部として書かれたアプリケーションに異なるライセンスの下に置くことができる、いくつかの企業も、彼らは誇りに思っていることを、オープンソースのライブラリに知られている- 貢献したオープンソース・コミュニティの主要な賛辞といつか主要な拡張機能を獲得しますバック。

一部の企業は、ライブラリを作成するプロジェクトが再利用するたびにいくらか払い戻しを受ける会計慣行を持っています。

大規模で重要なプロジェクトに適用される可能性のあるその他の考えられる理由：

• コンパイル時間：数千のファイル、数千のクラス、関数などを含む巨大なモノリシックC ++プロジェクトは、コンパイルに非常に長い時間がかかる可能性があります（数行のコードを変更するたびに再コンパイルする場合、生産性が低下します）。静的にリンクされたライブラリと動的にリンクされたライブラリは個別にコンパイルされ、ソースが変更されていない場合は再コンパイルする必要はありません。

• 個別のモジュールまたはサブシステムの論理的な分離：機能の個別の領域が個別のモジュールに配置されている場合、大規模なシステムは通常管理が容易であり、開発者は何千ものファイル/クラスを含む巨大なフォルダー/プロジェクトを検索する必要がありません。

• 開発者/チーム間の境界：別々の新しい機能を同時に開発する開発者は、各開発者が異なるモジュールで作業することが可能であれば、マージの競合の可能性を減らすことができます。

• ライブ環境にリリースしてはならないコード：たとえば、開発者テストでライブシステムコンポーネント（ハードウェア、API、リモートシステム、データベースなど）の代わりに使用される単体テストライブラリまたは「モック」ライブラリ

• コンパイラフラグ：奇妙なコンパイラフラグが必要なサードパーティのAPIと統合するという非常に不幸な立場にいる場合、ライブラリはサードパーティのAPIとアプリケーションの残りの部分の間にある「汚染除去層」になる可能性があります。

• オプション機能/最適化：大規模なシステムでは、アプリケーションの基本的な機能にとって重要ではない場合、特定の動的にリンクされたモジュールを実行時にメモリにロードする前に、アプリケーションが待機する場合があります。

一般に、多くの内部プロジェクトは小さなマイクロアプリであることが多く、個別のライブラリに分割してもメリットがありません。小さなプロジェクトで単独の開発者として作業している場合は、コードをライブラリに分割することを心配する必要はありません（まだ...）。YAGNI原則を忘れないでください。

あなたの元の質問は、他のほとんどの答えについてここで誤解を引き起こしたかもしれません。プロジェクト間で既存のコードをコピーするのではなく、異なるプロジェクトからの同じソースファイルを参照として含めるつもりなので、「重複するコード」の引数は、他の多くの引数と同様に無意味になります。

これは時々（常にではないが）賢明な手法であることに注意してください。実際、プロジェクト間で再利用したいすべてのソースファイルを1つの個別のインクルードフォルダーに入れると、すでにライブラリも構築されています。これは、バイナリライブラリではなく、ソースコードライブラリです。特にC ++では、テンプレートを使用して汎用ライブラリを作成する場合、単純なインクルードだけを必要とし、個別のリンクの準備を必要としない、ヘッダーのみのライブラリがあることも珍しくありません。

だからあなたの本当の質問は-ソースコードライブラリをいつビルドするのか、またはいつプリコンパイルされたバイナリライブラリを好むのか？この中で、このサイト上の古い答え、私は多分それはあなたを助け、ヘッダのみのLIBSのいくつかの長所と短所を議論しました。ソースコードライブラリの主な利点は、それらを使用するアプリケーションと同じランタイムフラグまたは互換性のあるコンパイラ/リンカーフラグでコンパイルする必要がないことです。欠点は、追加のコンパイル時間、およびソースコードへのアクセスを提供するための要件です（これは、明らかに、想定している「内部」プロジェクトの種類では問題ではありません）。

他のコメンターがコードを複製してはならないと書いたとき、私はそれに同意します。しかし、あなたの場合、あなた（またはあなたが一緒に働く人々）は、他の場所で複製されていないコードのライブラリを作成しているようです。

この場合、私は時期尚早な一般化に対して警告します。コードの一部が再利用可能であると感じる場合がよくあります。ただし、2番目のユースケースがこのようなコードをどのように使用するかについての詳細がわからない場合、追加のケースでは実際には役立たない「再利用性」機能に余分な時間を費やしたり、間違っていると仮定したりすることは非常に簡単です。 2番目のケース。

1つのユースケースで「ライブラリ」を作成すると、見返りがなければ非常に費用のかかる練習になる可能性があります---これに何度も噛まれました。

費用の例：

1. 「一般的な」ユースケースの検討に費やされた時間/エネルギー
2. 「ライブラリ」を「クライアント」（独自のコード）に配布可能にするために費やされた時間
3. 「ライブラリ」を次のユースケースと完全に一致させなくても、利用するという将来のプレッシャー

私の一般的なルールは次のとおりです。コードが必要な場所が少なくとも2つある場合を除いて、コードをライブラリにしないでください。

ヘッダーと実装ファイルにアクセスでき、それらをソースツリーに含めてすべて一緒にコンパイルできるのに、内部ライブラリを内部アプリケーションにリンクするためだけに開発する必要があるのはなぜですか？

あなたが「私のソースツリーにそれらを含めるだけ」なら、あなたはコードを複製しているからです。

これの問題は、コードをコピーしたプロジェクトによって行われた改善（重要なバグ修正を含む）の恩恵を受けないこと、およびあなたが加えた改善の恩恵を受けないことです。

この問題は、最新バージョンのコードをソースツリーに定期的にコピーするだけで解決できると思うかもしれません。おそらくgitなどのサブモジュールを使用して自動化することもできます。ただし、互換性のないAPIの変更により、ビルドが常に中断されます。一方、ライブラリには「公式の」パブリックAPIがあり、開発者はクライアントと調整しないと変更できないことを知っています。

最後に、技術的な理由があるかもしれません-コードの一部をライブラリとして保持する必要があるので、オプションでロードしたり、必要に応じてロードおよびアンロードしたりできるため、機能が不要なときにメモリ使用量を削減できますか？

ソリューションの長期的なコストについて詳しく説明します。

明らかに、ライブラリをプロジェクトに追加すると、オーバーヘッドが発生します。これが最初の場合は上記のとおりです。ワークフローを変更する必要があり、インフラストラクチャやチームメンバーによっては（最初は）気に入らない場合もあります。そのため、今よりコストがかからないため、ソリューションの利点は明白です。

ただし、プロジェクトが成長するにつれて、「疑似ライブラリ」のコストも増加します。Aアプリケーションと単体テスターが使用する「疑似ライブラリ」があると仮定します。cppをAに追加するたびに、両方のプロジェクトに追加する必要があります。追加しないと、リンクされません。

「疑似ライブラリ」が別の「疑似ライブラリ」によって使用されている場合はどうなりますBか？たくさんのプロジェクトに新しいcppを追加する必要があります。そして、B別のライブラリを使用するように切り替えたら？にAのみ依存するすべてのプロジェクトでcppsをから削除する必要がありBます。

実際のライブラリを使用する場合、これはすべて無料です。それで問題は、実際のライブラリへの移行を正当化するために必要なcppはいくつですか

しかし、待ってください。さらに多くの資料があります。開発者は、新しいcppを必要とするすべてのプロジェクトを探し出すというこの愚かな作業を嫌い、既存のファイルのどこかに自分のコード/クラスを追加します。これは、長期的には。

したがって、「疑似ライブラリ」を使用することは、モノリシックプロジェクトを分割するための最初のステップになる可能性がありますが、実際のライブラリをその利点を利用できるようにするために、それほど長く待つべきではありません。

しかし、ヘッダーと実装ファイルにアクセスでき、それらをソースツリーに含めてすべて一緒にコンパイルできるときに、内部ライブラリを内部アプリケーションにリンクするためだけに開発する必要があるのはなぜですか？

ライブラリが1つのアプリケーションでのみ使用される場合は、おそらくそれを別個のライブラリとして必要としません。

ライブラリは3500個のアプリケーションで使用されているなら、あなたは絶対にない別のライブラリとして、それを必要とします。

ライブラリにバグがあり、修正する必要がある場合はどうなりますか？または、法的または規制の変更が伴います。つまり、ライブラリの動作方法を変更する必要がありますか？

別のライブラリーにある場合は、ライブラリーを（場合によっては）修正し、再テストして再デプロイすると、すべてのアプリケーションで修正によるメリットが得られます。

各アプリケーションに対して「ローカル」であるのがソースコード内だけである場合は、すべてのアプリケーションを個別に変更、再ビルド、再テスト、および再デプロイする必要があります。これは、はるかに大きな（つまり、よりコストのかかる）演習です。