最近、広く使用されているテーブル (PRODUCT、USER など) の DB 列定義を変更する際の影響分析を行う必要があります。とても時間がかかり、退屈で難しい作業だと思います。そうするための既知の方法論があるかどうかを尋ねたいですか？
この質問は、アプリケーション、ファイル システム、検索エンジンなどの変更にも当てはまります。最初は、この種の機能的な関係は事前に文書化するか、何らかの方法で追跡する必要があると考えていましたが、その後、すべてに変更が生じる可能性があることに気付きました。そうすることは不可能です。
この質問に何をタグ付けするべきかさえわかりません。助けてください。
下手な英語でごめんなさい。
もちろん。プログラムスライスを決定することにより、技術的には、少なくともどのコードが DB 列に触れる (読み取りまたは書き込み) かを知ることができます。
方法論: ソース内のすべての SQL コード要素を見つけます。問題の列にどれが接触しているかを判断します。(注意: SELECT ALL は列に影響を与える可能性があるため、スキーマを知る必要があります)。その列の読み取りまたは書き込みを行う変数を決定します。それらの変数がどこに行っても追跡し、それらが影響するコードと変数を決定します。これらすべての変数にも従ってください。(これは、前方スライスを計算することになります)。同様に、列を埋めるために使用される変数のソースを見つけます。それらをコードとソースまでたどり、それらの変数もたどってください。(これは後方スライスを計算することになります)。
スライスのすべての要素は、変更によって影響を受ける可能性があります。スライスで選択されたコードに、新しいユース ケースで期待される条件から明らかに外れている条件が含まれている可能性があり、そのコードを考慮から除外できます。スライス内の他のすべてのものは、変更を加えるために検査/変更する必要があります。
ここで、変更が他のコードに影響を与える可能性があります (たとえば、DB 列を使用する新しい場所、または DB 列の値を他の値と組み合わせるなど)。変更したコードの上流と下流のスライスも検査する必要があります。
このプロセスは、DB 列だけでなく、コード ベースに加える可能性のあるあらゆる変更に適用できます。
これを手動で行うのは、大規模なコード ベースでは容易ではなく、確かに迅速ではありません。C および C++ コードでは自動化を行う必要がありますが、他の言語ではそれほど多くはありません。
目的の変数またはアクションを含むテスト ケースを実行し、テスト カバレッジを検査することで、不適切な概算を得ることができます。(テストケースを実行すると、目的の変数またはアクションが確実にカバーされず、カバーされているすべてのコードが削除された場合に、近似が改善されます)。
最終的に、このタスクを自動化することも、アルゴリズムに還元することもできません。それ以外の場合は、リファクタリングされた変更をプレビューするツールがあります。最初にコードをうまく書けば書くほど、作業は簡単になります。
答えにたどり着く方法を説明しましょう。隔離が鍵です。すべてをオブジェクト プロパティにマッピングすると、レビューの自動化に役立ちます。
例を挙げることができます。特定のケースを以下にマッピングすることができれば、命を救うことができます。
Hibernate や Entity Framework のように...
データベース列への変更は、特定のオブジェクトのプロパティを使用するコードを分析することで簡単にプレビューできます。すべての DB 列がオブジェクトのプロパティにマップされ、純粋な SQLを使用するコードがないと仮定すると、見積もりを行うのに適しています。
これは、変更管理の非常に単純なパターンです。
ファイル システム/ネットワークまたはデータ ファイルの問題を上記のパターンに減らすには、他のソフトウェア パターンを実装する必要があります。つまり、複雑なシナリオをオブジェクトのプロパティの変更に減らすことができれば、IDE を活用して、コンパイルにわずかな変更が必要なコードや、まったく書き直す必要があるコードなどの変更を検出できます。
上記を行うと、手動の要件レビューが簡単になります。全体的なタスクは手動ですが、自動化されたツールで支援できるためです。クラスのプロパティの名前を変更して、コンパイラでその副作用を確認することができます
明らかに、コードの周りの複数の場所でプレーン SQL がハードコーディングされ、粉々になっているソフトウェアで、データベース内の特定の列の名前、型、および長さを変更する必要がある場合、さらに悪いことに、多くのテーブルが同様の列の命名を提示し、プロジェクトのドキュメントもありません (私は最悪のケースを書いていますよね?) 合計 10000 以上のクラスのうち、検索ツールを使用して手動でプロジェクトを探索する以外に方法はありませんが、それらに依存することはありません。
また、ソフトウェア テスト スイートの作成元となるドキュメントであるテスト計画がない場合は、それを作成する時が来ました。