10以上のプロジェクト間でコードベースを共有し、痛みを最小限に抑える方法は？

同じデータベースで同じデータを共有するアプリケーションがいくつかあります。コードの冗長性を最小限に抑えるために、データアクセス層は共有プロジェクトです。これにより、各プロジェクトが独自のデータアクセスを再コーディングする必要がなくなりますが、これも大きな問題になります。1つのチームがデータレイヤーを更新する必要がある場合、他のすべてのチームは変更をプルしてテストし、変更が何も壊れていないことを確認する必要があります。これは遅くて苦痛なプロセスです。

共有データレイヤーを削除し、各チームに独自のデータレイヤーを管理させるというアイデアについて考えましたが、問題は、すべてのチームが同じデータベースにアクセスするため、テーブルの変更がある場合でも、すべてのチームが関連するコードを更新します。

だから私の質問は、多くのプロジェクトが同じデータソースから追​​い出され、データベースまたはアクセスレイヤーへの変更の痛みを最小限に抑えるように、データとアクセスレイヤーをどのように設計できるでしょうか。

共有データ層はかなり良い考えに見えます。痛みを最小限に抑えるソリューションは次のとおりです。

1. 一部のテストが失敗したときに例外をスローするテストモジュールを作成します（例：メッセージだけでなくすべてが機能しなくなる）。
2. すべてのテストモジュールを共有フォルダに配置します。つまり、10以上のプロジェクトのテストモジュールはすべて同じフォルダ（またはわかりやすいパス）にある必要があります。
3. プログラマーがクリティカルレイヤーを編集したい場合、そのフォルダー内のすべてのテストを実行する必要があります。何かが機能しない場合、コードをコミットできません。

このようにして、コードを作成した場合、実際のテストクラスのように、適切なテストクラスを作成する動機が生まれます。テストクラスに変更が加えられて爆発した場合、それらの変更によってコードが破損するためです。したがって、すべてのプログラマーは適切なテストを書くことを余儀なくされています（私がそうしないと、コードがときどき壊れる可能性があります）。すべてのプロジェクトのテストをエラーなしで実行することは、「コミットできます」ということを意味します。何かがうまくいかない場合は、「いいえ、これらの変更はシステムをある行xで壊します」

これは、テストスタッフがプロジェクトに取り残されることが多いため、良い点です。もちろん、テストコードを維持するには、追加の作業が必要です。

私はこの問題を直接経験しました。難しいので、5つのアプリケーションだけを統合していました。私はいくつかのヒントを提供できます：

1. できるだけ多くの目的でRESTfulサービスを使用してデータベースを分離します。これにより、必要に応じて複数のインターフェイスバージョンを簡単に作成でき、データベースの移行がはるかに簡単になります。
2. 一部のアプリケーションのデータベースアクセスが読み取り専用の場合は、必要なデータのデータベースビューを作成します。値を計算するためにバッチプロセスを実行する必要がある場合は、マテリアライズドビューで実行してください。
3. デザインについて注意深く考えてください。データベースを変更すると、他のアプリケーションが壊れる可能性があります。すべてのアプリに本当に完全なデータベースアクセスが必要ですか？そうでない場合は、サービスを使用するためにそれらを分割します。データベースアクセスをロジックから切り離します。

簡単に言えば、共有コードにできるだけ多くの時間を費やして、コードを可能な限り堅牢/堅牢/信頼できるものにする必要があるということです。

発見していると、ライブラリコードを頻繁に変更する余裕がありません。

データレイヤーを2つの部分に分割する必要がある場合があります-非常に単純なことを行うが変更しない低レベルの部分（つまり、共有コード）と、アプリケーションごとに一意にする必要がある高レベルの部分。

低レベルの共有部分については、アプリケーション開発者ではなく、ライブラリ開発者のように考える必要があります。これは、多くの単体テスト、非常に明確かつ完全に定義されたアプリケーションインターフェイス、正確で完全かつ有用なドキュメント、および多くの防御的なコードを意味します。他の方法で証明されるまで、すべての入力は無効です。

共有コードは、コードを使用する今日のアプリケーションのニーズに対応するように作成する必要がありますが、このコードがこれまで使用されていない次の数十のアプリケーションでどのように機能するかを検討するために、時間を追加する必要がありますまだ提案しました。別の言い方をすれば、共有コードは、消費者に意味のある方法でデータを公開するという一般的な問題を解決します。うまくいけば、新しいコンシューマは変更なしでこのライブラリを使用できます。