いくつかの大きなライブラリまたは多くの小さなライブラリ？
数か月の間に、すべてのプロジェクトに現在組み込んでいるゲーム開発用の小さなフレームワークを作成しました。
フレームワークは、SFML、LUA、JSONcpp、およびその他のライブラリに依存しています。オーディオ、グラフィック、ネットワーキング、スレッディングを扱います。いくつかの便利なファイルシステムユーティリティとLUAラッピング機能があります。また、文字列解析ヘルパーや数学ユーティリティなど、多くの便利な「ランダム」ユーティリティメソッドがあります。
私のプロジェクトのほとんどはこれらの機能をすべて使用していますが、すべてを使用しているわけではありません。
- ファイルシステムとネットワーク機能のみを使用する自動アップデーターがあります
- ネットワーク機能のないゲームを持っています
- JSONcppを必要としないプロジェクトがあります
- これらの文字列/数学ユーティリティのみが必要なプロジェクトがあります
つまり、SFML/LUA/JSON共有ライブラリは、たとえ使用されていなくても、すべてのプロジェクトに含める必要があります。プロジェクト（非圧縮）のサイズはこのように10MB以上で、そのほとんどは未使用です。
代替策は、フレームワークを多くの小さなライブラリに分割することです。これは、はるかに効果的でエレガントになると思いますが、より多くのDLLファイルとプロジェクトを維持する必要があるというコストも伴います。
フレームワークを多数の小さなライブラリに分割する必要があります。
- グラフィックス
- スレッディング
- ネットワーキング
- ファイルシステム
- 小さいユーティリティ
- JSONcpp utils
- LUA utils
これは最良の解決策ですか？
個人的にはたくさんの小さな図書館に行きたいと思います。
- 開発者が他の方法では無関係なパッケージ間の依存関係を作成しないようにします。
- 焦点が絞られた、より小さくて管理しやすいライブラリ。
- 分割が簡単になり、各ライブラリを別々のチームで管理できます。
- 十分に複雑な新しい要件がある場合、既存のライブラリを見つけて新しいコードを投入するのではなく、新しいモジュールを追加することをお勧めします。小さなライブラリはこのパターンを奨励します。
あなたはトレードオフの一方を与えましたが、もう一方は与えていません。あなたが働いている圧力の「公正でバランスの取れた」ものなしでは、私たちはおそらくあなたに言うことができません。
ライブラリを分割すると、すべてのプロジェクトが小さくなります。それは明らかなプラスです。さまざまなマイナスを想像できます。
- ライブラリを分割することは、たとえそれが一度だけ行われなければならないとしても、それ自体が努力です。
- 多くのライブラリのバージョンを一貫して維持することは、小規模ですが永続的な追加作業です。
- すべてのプロジェクトが実際に必要なものをバンドルしていることを確認するのは簡単ではありません
- 分割は、現時点で考えているほどきれいにできず、余分な作業が必要になる可能性があり、一部のモジュールの概念的な整合性を脅かす可能性さえあります。
このような反論がどの程度可能性/重要であるかに応じて、分割は正しい選択かもしれませんし、そうでないかもしれません。 （「スプリッター」と「ランパー」の間の二分法は、そもそも論理の影響を受けない基本的な性格特性であると多くの人が考えていることに注意してください！）
そうは言っても、あなたのモジュールが実行していると言っているさまざまなタスクはお互いから遠く離れているので、少なくともsome分割がおそらく必要だと考えます。
明確な答えはありません。私が考えることができる最良の推進要因は、ライブラリが現在どのように相互に関連しているか、そしてそれらが後で関連するようになることを期待していますか？依存関係の複雑なWebがある場合、おそらく1つの大きなライブラリの方が簡単です。最小限の関係があれば、それらをきれいに分割できます。
これは非常に主観的であり、心理学と感性に依存するかもしれませんが、私が個人的なプロジェクトに使用していて、長年にわたって嫌いにならなかった私の最長のライブラリは、常に最小で、最も孤立しています（外部への依存関係はありません）他のライブラリ）。
それは、私のライブラリ全体の認識を混乱させるために、1つのばかげたまたは古風なアイデアしか必要としないためです。私が90年代に書いた16ビット画像に対して、90年代に書いた画像と数学ライブラリに依存していることを除いて、描画ライブラリで図形をラスタライズするための完全に妥当なCコードがあるかもしれませんが、今は完全にシテになっています。まともな解析コードとASTコードが含まれているC++解析ライブラリもあるかもしれません。ただし、振り返ってみると、非常に愚かで非実用的な設計であったモノリシック解析ストリームに結合しました。今では全体がシテのように感じられます。90年代のC++コードのほとんどは、C++で効果的に設計する方法が本当にわからなかったので、継承を使用して「拡張」してミニマリストのインターフェイスで適切なサブタイプをモデル化するのではなく、100以上のメンバーと間抜けな抽象化でクラスを形成するスーパーセット機能。Cコードの多くは、ほんの一部ですが、シテフィルターを生き延びました。ほとんどの場合、シテの山を思いつきました。小さな金のナゲット私は常に、最も分離された最小限のコードであり、目的の最大の特異性を持ち、多くの場合、プリミティブデータ型に依存するだけでした。
次に、これらのライブラリを気にしたくありません。ただし、コードを新しいライブラリに移植し、それらを気にせず、未処理の32ビットおよび128ビットピクセルに対してのみ機能し、依存する代わりにベクトル数学をインライン化しますたとえば、ラスタライゼーションライブラリ用のいくつかの外部数学ライブラリ。その後、コードはずっと長く続き、私を幸せに保ちます。私は、ライブラリーに対する私の見方がちょっと皮肉です。最強のリンクではなく、最弱のリンクで判断する傾向があります。ライブラリから完全に排除されるまで、私は善を支持して悪を見逃すことはできません。
少なくとも私にとっては、彼らが後でシテしているように感じる確率が低いので、私はより小さくてより独立したライブラリに投票します。チームで作業している場合は、ライブラリを互いに切り離しておくために、より強力な基準でさらに投票します。非常に特異な目的と目的がない限り、ライブラリは多くの手で乱雑に処理されるためです。ミニマリズムに向けて（常に追加する理由を見つけるのではなく、追加しない理由を探す-追加しないものを嫌うことはできない）...心理学の要素はもっと重要です。しかし、さらに私は、非常に切り離された機能の部分を分割することを投票します。フレームワークをすぐに必要なすべての部分に分割する必要はありません。十分にテストされた、最小限の性質で分離された、安定したコードライブラリの構築を開始したいと思います。