いくつかの大きなライブラリまたは多くの小さなライブラリ？

数か月の間に、現在すべてのプロジェクトに組み込んでいるゲーム開発のための小さなフレームワークを作成しました。

フレームワークは、SFML、LUA、JSONcpp、およびその他のライブラリに依存しています。オーディオ、グラフィック、ネットワーキング、スレッディングを扱います。いくつかの便利なファイルシステムユーティリティとLUAラッピング機能があります。また、文字列解析ヘルパーや数学ユーティリティなど、多くの便利な「ランダム」ユーティリティメソッドがあります。

私のプロジェクトのほとんどはこれらの機能をすべて使用していますが、すべてを使用しているわけではありません。

• ファイルシステムとネットワーク機能のみを使用する自動アップデーターがあります
• ネットワーク機能のないゲームを持っています
• JSONcppを必要としないプロジェクトがあります
• これらの文字列/数学ユーティリティのみが必要なプロジェクトがあります

つまり、SFML / LUA / JSON共有ライブラリは、たとえ使用されていなくても、すべてのプロジェクトに含める必要があります。プロジェクト（非圧縮）のサイズはこのように10MB以上で、そのほとんどは未使用です。

代替策は、フレームワークを多くの小さなライブラリに分割することです。これは、はるかに効果的でエレガントになると思いますが、より多くのDLLファイルとプロジェクトを維持する必要があります。

フレームワークを多数の小さなライブラリに分割する必要があります。

• グラフィックス
• スレッディング
• ネットワーキング
• ファイルシステム
• 小さいユーティリティ
• JSONcpp utils
• LUA utils

これは最良の解決策ですか？

個人的にはたくさんの小さな図書館に行きたいです。

• 開発者が他の方法では無関係なパッケージ間の依存関係を作成しないようにします。
• 焦点が絞られた、より小さくて管理しやすいライブラリ。
• 分割が容易になり、別々のチームが各ライブラリを管理できるようになります。
• 十分に複雑な新しい要件がある場合、既存のライブラリを見つけて新しいコードを投入するのではなく、新しいモジュールを追加することをお勧めします。小さなライブラリがこのパターンを奨励します。

あなたはトレードオフの一方を与えましたが、もう一方は与えていません。あなたが働いている圧力の「公正でバランスの取れた」なしでは、私たちはおそらくあなたに言うことができません。

ライブラリを分割すると、すべてのプロジェクトが小さくなります。それは明らかなプラスです。さまざまなマイナスを想像できます。

• ライブラリを分割すること自体は、たとえ一度だけ実行する必要があっても、それ自体が努力です。
• 多くのライブラリのバージョンを一貫して維持することは、小規模ですが永続的な追加作業です。
• すべてのプロジェクトが実際に必要なものを実際にバンドルしていることを確認するのは簡単ではありません
• 分割は、現時点で考えているほどきれいにできず、余分な作業が発生する可能性があり、一部のモジュールの概念的な整合性を脅かす可能性さえあります。

このような反論がどの程度可能性/重要であるかに応じて、分割は適切な場合とそうでない場合があります。（「スプリッター」と「ランパー」の間の二分法は、そもそも論理の影響を受けにくい基本的な性格特性であると多くの人が考えていることに注意してください！）

そうは言っても、あなたのモジュールが実行していると言うさまざまなタスクはお互いから離れているので、少なくともいくつかの分割がおそらく必要だと思います。

明確な答えはありません。私が考えることができる最良の推進要因は、ライブラリが現在どのように相互に関連しているか、そしてそれらが後で関連するようになることを期待していますか？依存関係の複雑なWebがある場合は、おそらく1つの大きなライブラリの方が簡単です。最小限の関係があれば、きれいに分割できます。

これは非常に主観的で、心理学と感性に依存するかもしれませんが、私が個人的なプロジェクトで使用していて、長年にわたって嫌いにならなかった私の最長のライブラリは、常に最小で、最も孤立しています（外部への依存関係はありません）他のライブラリ）。

それは、私のライブラリ全体の認識を混乱させるために、1つのばかげたまたは古風なアイデアしか必要としないためです。私が90年代に書いた16ビット画像に対して、90年代に書いた画像と数学ライブラリに依存していることを除いて、描画ライブラリで形状をラスタライズするための完全に妥当なCコードがあるかもしれませんが、今は完全にシテになっています。まあまあの解析コードとASTコードを含むC ++解析ライブラリもあるかもしれません。ただし、振り返ってみると、本当にばかげて非実用的な設計であったモノリシックな解析ストリームに結合しました。だから今、全体がシテのように感じています。90年代のC ++コードの大部分は、C ++で効果的に設計する方法が本当にわからなかったため、継承を使用して「拡張」するなどの馬鹿げたことをしたので、今ではまったくのがらくたです。ミニマリストのインターフェースで適切なサブタイプをモデル化する代わりに、100以上のメンバーと間抜けな抽象化を備えたクラスを形成するスーパーセット機能を提供します。ほんの一部ですが、私のCコードの多くが私のシテフィルターを生き延びました。主にシテの山を思いついた。私が選んだ小さな金塊は、常に最も分離された最小限のコードであり、目的の特異性が最も高く、多くの場合、プリミティブデータ型に依存していました。

次に、これらのライブラリに煩わされたくありません。ただし、コードを新しいライブラリに移植し、それらに煩わされず、生の32ビットおよび128ビットピクセルに対してのみ機能し、依存する代わりにベクトル数学をインライン化しますたとえば、ラスタライゼーションライブラリ用のいくつかの外部数学ライブラリ。その後、コードはずっと長く続き、私を幸せに保ちます。私は図書館に対する私の見方にちょっと皮肉です。最強のリンクではなく、最弱のリンクで判断する傾向があります。そのライブラリから完全に悪が排除されるまで、私は善のために悪を見逃すことはできません。

少なくとも私にとっては、彼らが後でシテしているように感じる可能性が低いので、私はより小さくてより独立したライブラリに投票します。チームで作業している場合は、ライブラリを互いに切り離しておくためのより強力な基準でさらに投票します。非常に特異な目的と目的がない限り、ライブラリは多くの手で非常に乱雑になる可能性があるためです。ミニマリズムに向けて（常に追加する理由を見つけるのではなく、追加しない理由を探す-追加しないものを嫌うことはできません）...これはおそらく、個人的なプロジェクトのほうが多かったという質問に聞こえました心理学の要素はもっと重要です。しかし、さらに私は非常に切り離された機能の断片を分割することを投票します。フレームワークをすぐに必要なすべての部分に分割する必要はありません。私'