コードは、サード パーティのツールを使用して移行されました。ツールができなかったことは、すべてのコンパイルの問題が修正されるように、.net 開発者によって行われました。私の質問は、そのような移行活動のために、関数の単体テストを実行することを気にしませんか?
次に、クライアントが発見する可能性のある問題のリスクを最小限に抑えるために、VSTS 10 のツールを使用してこのコードの UML モデルを作成する必要があるかどうかを提案してください。なんと面倒くさい。
元の VB6 アプリケーションの機能が不明であるという事実を考慮して、高品質の移行コードを配信する方法について他に提案はありますか?
そのような移行作業のために、関数の単体テストをわざわざ実行しませんか。
新しく翻訳されたコード (機械的またはその他)はまったく信用できません。絶対にテストが必要です。
元の VB6 アプリケーションの機能は不明です。
これにより、回帰テストが非常に困難になります。それがどのように振る舞うべきか分からない場合、それがいつ終了したかをどのように知ることができますか?
もちろん、翻訳されたコードの単体テストを行わないこともできます。そうすると、新しいコードがどのように機能するかわかりません。ただし、「不明 = 不明」が「合格」と見なされるかどうかはわかりません。
私の経験では、大部分のアプリケーションが大量の「未知の」機能を提供しています。結局のところ、私たちがソフトウェアを書く理由は、単なるモラルとしての私たちの能力を計り知れない方法で情報を管理できるようにするためです。時間が経つにつれて、ソフトウェアのサイズと複雑さが増大し、増大し、増大し、膨大な量の「未知の」機能が含まれるようになります。未知の機能はおそらく既知であり、一度に「正しい」ことが確認され、ソース コードによって詳細にキャプチャされました。ただし、時間が経つにつれて、すべての機能が何であるか、またはそれが「正しい」理由でさえ、完全に覚えている/知っている人は誰もいません。完全な機能はソースコードによってのみ「記憶/認識」され、チームは「変更内容をテスト」し、問題が発生しない限り残りは正しいと見なされます。これは、何年にもわたって多くの人々によって拡張および変更されてきたシステムに特に当てはまります。もちろん、これはリスクを生み出します。TDD のようなプロセスや単体テストを自動化するツールが役に立ちますが、多くの古いシステムでは、システムの理解が不足しており、テストが不完全であることは避けられません。私の技術的理想主義者はこれが好きではありませんが、私のビジネス現実主義者はそれを受け入れます。
とはいえ、これは移行チームにとって大きな問題です。理論的には、これらのチームは「すべてを変えています」。VB6 から .NET への移行では、「変更内容をテストする」とは、すべてをテストすることを意味します。ああ。また、移行の機能要件は、多くの場合、「現在行っていることを新しいプラットフォームで行うこと」です。システムが正しく動作することを確認する方法は言うまでもなく、システムが行うすべてのことを人々が知らない/覚えていない場合は、あまり役に立ちません。私は、数百または数千のフォームとクラスに編成された数十万の LOC と、数千のメソッド、プロパティ、およびイベント ハンドラーを含む巨大な VB6 アプリを持っている複数の顧客と協力しています。これらのアプリには何万もの関数ポイントが含まれていると確信しています。移行チームに、VB6 を使用した場合にエラーを見つけるのにどれくらいの時間がかかるかを尋ねたいと思います。
これが、私がツール支援型の書き換え方法論の使用を提唱する理由です。このプロセスへの最も重要なインプットの 1 つは、本番環境でテストされたソース コードです。あなたまたはあなたの顧客がこのコードでビジネスを行っているため、このコードは「正しい」と想定しています。ソース コードは、 「システムは何をするのか?」という質問に対する非常に詳細で正式な完全な回答です。私たちのアプローチでは、移行チームは、完全な .NET ソースへの VB6 ソースの自動的で体系的な変換とリエンジニアリングを繰り返しカスタマイズ、調整、および検証します。翻訳、テスト、調整、繰り返します。そのたびに、機能の正確さと .NET コーディング標準への準拠という点で翻訳の品質が向上します。ツールの機能を検証して改善することは、方法論の中心です。
コードの品質を検証するために、コード レビューと「サイド バイ サイド」テストを使用します。コード レビューは、目や .NET コンパイラ、FXCop、NDepends などの他のツールを使用して .NET コードを検査することによって行われます。また、BeyondCompare などの製品を使用して、変換されたコードの連続した世代を比較して検証します。各変換チューニングの変更は望ましい効果をもたらし、望ましくない副作用はありません。サイド バイ サイド テストとは、その名のとおりです。一般的な考え方は、レガシ アプリと .NET アプリをサイド バイ サイド テスト環境で実行し、それらの結果と動作が一致することを確認することです。ここには、少なくともいくつかの課題があります。
最初の質問は通常、テスト データ、ユース ケース、および自動化された単体テストに関して回答されます。2 番目の質問は、アプリケーションの UI と、両方のシステムからの結果 (データ、Web ページ、レポート) を見て比較する (別名、承認ベースのテスト) という観点から答えられます。もちろん、テストツールは効率を高めるのに大いに役立ちます。大規模な移行は、テスト ツールの使用開始について話し合う絶好の機会です。
大規模で複雑なコードベースの移行を計画している場合は、テストについて非常に賢く計画する必要があります。ツール支援のアプローチが適切に行われると、本番環境に対応したコードが非常に効率的に提供され、リソースが解放されて QC アーティファクトを作成し、移行後も長く続く QC プロセスが改善されます。
免責事項: 私は Great Migrations で働いています。
あなたの質問のトーンから、あなたは答えを知っているように聞こえます! 回帰テストの完全なセット以外のものは、災害のレシピになると思います! 理想的には、古いバージョンと新しいバージョンの両方に対して同じ一連のテストを実行することをお勧めしますが、それができないように思えるかもしれません...
私の正直な答えは、サポートの問題を修正するために 24 時間体制で作業する準備ができているサポート/メンテナンス開発者がたくさんいることを確認してください!