レガシーソフトウェアの移行のための6つのステップ
（掲載 2023年8月31日）
Motif、MFC、Photon、または以前のQtバージョンから最新のQtバージョンにレガシー コードを移植することは、大きなチャレンジです。大規模な移植作業には多くの落とし穴があり、時間、コスト、複雑さは大幅に増加し、プロジェクトが頓挫するリスクがあります。サポートが終了している言語、フレームワーク、ウィンドウシステムがあったり、知識のある人材が見つからない場合があります。その上、レガシーなUIは、最近の滑らかなアニメーションや、コンテキストに異存したコントロール、応答性の高いインタラクションと比較すると非常に古く見える傾向があり、最新の状態にするには単純な移植以上に多くのことが必要であり、どこから始めればよいのかさえわからないかもしれません。
すでにレガシーソフトウェアの移行を決定しているとして、それでは次に何をすればよいのでしょうか？この記事では、レガシーソフトウェアの移行における最も重要な手順について説明し、独自の移行を実行できるようにします。
ステップ1：ビルドを通す
移行の最初のステップは、ソースコードをシステム上でビルドできるようにすることです。これには、ソースコードを一時的にコメントアウトしたり、必要でないサードパーティの依存関係を取り除いたり、フレームワークの互換性機能を有効にしたりすることが含まれるかもしれません。
アプリケーションをビルドするために必要なことはいろいろとあります。ビルドできない部分をスタブアウトしたり、モジュールが大きすぎてスタブアウトできない場合は一時的にMakefileから削除したり、プリプロセッサを使用してビルドから行ブロックを削除するなどです。
大切なことは、これを制御され、再現可能で元に戻せる方法で行うことです。適切に移行された後に再び元に戻せるように、一時的に削除したビットを正確に把握する必要があります。スタブアウトされたコードをすべて移行する必要はないかもしれません。長い間進化してきたプロジェクトのほとんどのコードベースには、多くののデッドコードが含まれており、移行はそれを発見して削除する絶好の機会です。
マイグレーション関連のコメントを適切に追跡するためには、TODOのようなものでなく非常に明確なラベルを使用することです。少し極端なようですが、
I_AM_STUBBING_THIS_OUT_BUT_IT_NEEDS_TO_GO_BACK_IN_LATER
のようなものが良い選択かもしれません。なぜなら、コードには既にTODOが散乱している可能性があり、ソース内の移行スタブを明確に区別する必要があるためです。コードの見栄えを気にする必要がありません。これらは全て作業が終われば削除されます。
ステップ2：基本的な機能から始める
ビルドが完了したら、主要機能の移行を開始します。他のすべての要素の基礎となるアプリケーションの主要な機能を特定するためにコード内に階層を確立し、それらの部分の完成を目指します。
Motifからの移行の場合は、コアを移植することから始めます。たとえば、まだ図面を作成できないからと言って、ユーザーが図面の表示方法を設定できる「環境設定」ダイアログで作業することはあまりおすすめできません。「環境設定」ダイアログから開始するよりも、メインウィンドウにコンテンツを描画させる方が合理的です。
MFCからの移行では、ダイアログや再利用可能なウィジェットを移植することから始めて、メインウィンドウで終了します。これは、ダイアログが一時的にQtを使用している間、メインウィンドウはMFCを使用し続けることができるためです。
Qtの古いバージョンからの移行では、移植はより水平的になります。たとえば、QPointerリストのすべての使用法を移植することから始めて、次にQCanvasのすべての使用法を移植するというように続きます。
ステップ3：テスト
移行されたコードをテストするために、開発者は準備ができていれば単体テストを実行し、基本的なインタラクティブテストを実行します。さらに、より体系的なテストを実行できる品質チームもありますが、そのためには、お客様からテスト計画、またはユーザーマニュアルなど、テスト計画を作成するのに役立つ文書を提供いただく必要があります。もちろん、私たちは顧客ほどアプリケーションについてよく知っているわけではないため、この種の情報を顧客から提供してもらうことが重要です。顧客がSquishなどによる自動テストをすでに導入している場合は、さらに良いでしょう。
テスト計画が完了し、すべてのテストを実行して期待どおりの結果が得られると確信できたら、おめでとうございます！これで移行は完了です。
ステップ4：自動化ツール
移行の中で自動化できる部分は、単純な検索/置換から非常に複雑な構文解析、置換操作まで多岐にわたります。KDAB社では、このための内部スクリプトとツールを開発しました。たとえば、MotifからQtへの移行では、次のようなコードが頻繁に発生する可能性があります。
XmToggleButtonGadgetSetState(_onoff, sc && sc->isEnabled(), false)；
これは、適切なツールを使えば、自動的に次のように移行できます。
ui->_onoff->setChecked(sc && sc->isEnabled())；
エンジニアにとって、毎回毎回すべての入力パラメータを入力するのは望ましいことではありません。しかし、この種の変換を自動化するインテリジェントなマクロがたくさん設定されているエディタは、非常に助けになります。エンジニアが状況を特定したら、手動でパラメータの順序を調べたり、別々のビットをコピー＆ペーストしたりする代わりに、コード変換をトリガーして結果を確認することができます。
ツール活用のもう1つの例は、変更されていない元のアプリケーションと移行中の新しいアプリケーションとの間でバージョンを切り替えることです。通常、2つのコードツリーを隣り合わせにしておき、KDAB社が設計したツールを使うことで、エンジニアは同じファイルの2つのバージョン間をすばやくジャンプして、特定のコード部分が古いバージョンでどのようになっていたかを確認したり、差分を含む別のウィンドウを開いたりすることができます。検索ツールもまた欠かせません。たとえば、カーソルを識別子の上に置き、キーの組み合わせを押すと、ソースツリー全体でその定義や参照をすぐに見つけることができ、非常に役立ちます。最新のIDEのほとんどはこのような機能を提供していますが、多くはソースが完全にビルドされないと機能しないため、移行作業には役に立ちません。複雑な正規表現を使用したテキストベースの検索は、形式の悪いソースコードであっても、的確な分析を行うための他の多くの方法を提供することができます。
また、KDAB社は、Qt 3互換機能や Qt アイテム用のMFCコンテナーなどの中間層を提供することで、移行を支援する実際の C++ ライブラリも開発しました。
ステップ5：新しい機能の追加
移行の途中では新しい機能を追加しないようにしましょう。初期バージョンと移行バージョンを比較できる必要があるため、両者は可能な限り同じように動作しなくてはいけません。もちろん、移行後に新しい機能を追加することは可能です。
移行中にクライアントが元のバージョンに変更を加える必要がある場合があるため、移行中に変更が発生することは避けられない場合もあります。このような場合、アプリケーションの元のバージョンの移植が完了した後で、お客様の変更をマージして移植できます。
ステップ６：KDABの支援
KDABでは、15年以上かけて移行プロセスを微調整し、さまざまなフレームワークからソフトウェアを移行することに成功し、その大部分はQへの移行でした。彼らの経験に基づいて、フレームワーク、オペレーティングシステム、言語に関係なく、すべての移行には確実に成功するための共通の手順があり、最善の努力を台無しにする共通の落とし穴があることも熟知しています。この認識のもと、彼らはプロセスをスピードアップするための社内ツールとノウハウを開発してきました。詳細については、SRAの営業担当もしくは問合せページにご相談いただくか、KDAB日本語ページより直接お問合せください。
出典：6 Steps for Legacy Software Migrations
【KDAB】
KDAB日本語トップページ