状況：
私たちのチーフ アーキテクトは、私たちの作業領域の「ランタイム」として意図された C++ ライブラリを作成しました (これらは実際にはいくつかのライブラリです - sdl、sdl_net、sdl_ttf を考えてみてください。ただし、C++ インターフェイスを備えています。そのうちの 1 つだけが必要な場合があります)。
つまり、これらのライブラリは、多数の CRUD アプリケーション、他の (より具体的な) ライブラリ (sdl に基づくスプライト ライブラリを考えてください)、および大規模なアプリケーション (クライアント/サーバー、リモート GUI) にリンクされています。
問題：
多くの理由により (もちろん、時間の不足もその 1 つです)、「ランタイム」ライブラリはまだ変更される可能性があります。新しいクラスが導入されたり、既存のクラスがクラス階層に取り込まれたり、メソッドのパラメーターが変更されたりする可能性があります。ABI がないため、適切なバージョニングなしで動的にリンクすると、ランタイムをリンクするコードが壊れ、製品ソフトウェアがクラッシュします。
却下されたソリューション:
- ランタイム ライブラリの変更により、新しいバージョンが導入されるはずです。に対してリンクしているバイナリは、 (しばらくの間) 削除されることを意図していないため、出荷
myrt.so.1時に引き続き機能します。myrt.so.2myrt.so.1
却下の理由: 多くの新しいライブラリ バージョンが本番環境を「汚染」します。最悪の場合、各バイナリには独自のmyrtバージョンがあります。
- 静的リンク。
却下の理由: 明らかな肥大化とともに、上記の最後のステートメントは実質的にここにも当てはまります。
- おそらく 2 つの
myrtバージョンを保持し、依存関係を再構築しmyrtます。
拒否の理由: すべての依存関係の機能をテストする時間はなく (自動テストはほとんどありません)、テストされていないバイナリを出荷するリスクが高すぎると見なされます。
質問:
他に何ができるでしょうか？却下の声明に取り組むことで、提案された解決策の 1 つを復活させる方法はありますか?
おそらく、原因ではなく症状を修正しています (自動テストの欠如、安定した API を実際に作成するためのリソースの欠如など)。正直なところ、より大きな問題から抜け出す方法はわかりませんが、より良いテストに向けた措置は講じられています。