レガシー・コードとは

Michael Feathers氏は2004年に発表した著書『Working Effectively with Legacy Code』の中で、「テストのないコード」という別の表現をしています。¹レガシー・コードのこの定義は、プログラマーがコードが期待どおりに機能するかどうかを検証する方法がないことを意味します。多くのレガシー・システムには、その動作を理解するために不可欠な適切なドキュメントが不足しており、開発者にとってシステムの拡張や強化が大きな負担になっています。

レガシー・コードは技術的負債の原因となり、これは継続的なコード保守を通じて時間をかけて「返済」していく必要があります。レガシー・コードを維持する際に組織が直面する可能性のある一般的な課題は以下のとおりです。

●適応性

●コスト

● パフォーマンス

● 拡張性

● セキュリティーとコンプライアンス

レガシー・コードは時代遅れであるため、最新のシステムと互換性がなかったり、統合が困難だったりする場合があります。この適応性の欠如により、イノベーションが阻害され、ビジネスの成長が遅れ、企業は競争力を失う可能性があります。

レガシー・システムを維持するにはコストがかかる場合があります。これらの運用コストと保守コストは累積する可能性があり、古いソフトウェアおよびハードウェア・バージョンではサードパーティのサポート料金が増加する可能性があります。さらに、時代遅れのコンピューティング手法やプログラミング言語に精通した開発者を見つけるのは困難で、コストもかかります。

例えば、扱いにくいモノリシック・アーキテクチャーは、レイテンシーが高くなるだけではなく、応答時間が遅くなり、ダウンタイムが頻繁に発生します。こうしたパフォーマンスの低下はユーザー・エクスペリエンスに悪影響を及ぼし、顧客満足度を低下させる可能性があります。また、これらのシステムを操作および保守するチーム・メンバーの生産性と効率性も低下するかもしれません。

時代遅れのシステムは、ユーザーにかかる負荷を増やす可能性があります。こうしたシステムでは需要の急増に対応することが難しく、また、必要に応じて規模を拡大または縮小することが困難です。コンポーネントが密接に結合されているため、既存の機能のアップグレードや新機能の追加も難しくなります。

古いコードはセキュリティー・パッチによる更新がほとんどなく、最新のセキュリティー標準に準拠していない可能性があるため、サイバー攻撃や侵害に対して脆弱になります。また、レガシー・システムは、現在の規制に準拠していない可能性もあります。

一方、レガシー・アプリケーションのモダナイゼーションには、慎重な計画が必要です。プロセスを効率化するための5つのステップは以下のとおりです。

● コードベースの理解

● 分割統治

● 特性評価テストの作成

● リファクタリング、移行、または書き換え

● テストと文書化

最初のステップはコードベースを理解することですが、これは通常最も難しいステップです。仕様書、インライン・コード・コメント、コミット・ログや変更ログなどのバージョン管理履歴など、利用可能なドキュメントを確認することから作業は始まります。

必要なドキュメントが足りない場合は、コードを実行せずに自動的に検査する静的コード分析ツールを使用する必要があります。さらに、コード視覚化ツールはソース・コード構造のグラフィカルな表現を作成できるため、要素間の依存関係や相互作用をマッピングするのに役立ちます。

ソフトウェア開発チームがレガシー・システムを十分に理解したら、いよいよ本格的な作業の開始です。これらの広大なコードベースは対処するのが困難になる可能性があるため、コードベースをより小さく管理しやすいモジュールに分割し、一度に1つのモジュールで作業します。

テストは通常​​、コードの正確性と意図された動作を検証するために作成されます。ただし、特性評価テストは、コードが何を実行し、どのように機能するかを理解するために作成されます。これはレガシー・コードを理解するのに役立ちます。²  

企業がレガシー・コードをモダナイズする場合、一般的に、リファクタリング、移行、または書き換えの3つの選択肢があります。これらのアプローチを組み合わせることもできます。どちらの道を進むかを決定するには、ソフトウェア・エンジニアリング・チームとビジネス・リーダーシップ・チーム双方の意見を聞く必要があります。

コード・リファクタリングは、外部の動作を変更したり機能に影響を与えたりすることなく、ソース・コードの内部構造を変更します。こうした小さな変更によってバグが発生する確立を下げ、保守性が向上した明確でクリーンなコードが作成されます。

レガシー・コードの場合、チームは変数の名前変更、重複または未使用のメソッドの削除、フォーマットの標準化など、各モジュールの小さな変更から始めることができます。その後、大きなメソッドを小さなメソッドに分割したり、複雑な条件を簡素化したり、関数間で機能を移動して依存関係を減らし、凝集性を高めたりするなど、よりロジックベースの再構築を進めます。

移行は、レガシー・コードをモダナイズするためのもう1つの方法です。これには、モノリシック・アーキテクチャーからマイクロサービスへの移行や、オンプレミスからクラウドへの移行など、コードの全部または一部を新しいプラットフォームまたは技術スタックに移行することが含まれます。プラットフォームまたはテクノロジー・スタックとの互換性を確認し、移行中にプロバイダーがサポートを提供するかどうかを確認することが重要です。

レガシー・コードの書き換えは、古いコードを置き換えるためにまったく新しいコードを作成する必要があるため、最後の手段となることがよくあります。これはそれ自体が新しいプロジェクトであり、別個の開発チームによる対応が必要となる可能性のある大規模な取り組みです。

巨大なレガシー・コードベースの場合、移行と書き換えはどちらも困難な作業になる可能性があるため、チームは「ストラングラー・フィグ」戦略を検討することができます。³「ストラングラー・フィグ」戦略では、イチジク（フィグ）は木の表面の高いところで成長し、その根は地面まで降りて、ゆっくりと宿主の木を締め付ける格子で包み込み、最終的に枯れさせます。

レガシー・システムに関しては、コードベース全体が最新のフレームワークに切り替えられるか、現在のプログラミング言語で開発されるまで、チームは小さなコード・フラグメントを段階的に移行または書き換えることができます。ただし、チームは既存のコードと新しいコードが共存するための移行アーキテクチャーを構築する必要があります。移行または書き換えが完了した時点で、この移行アーキテクチャーを廃止します。³

リファクタリング、移行、または書き換えられたコードを徹底的にテストし、バグが発生しないことを確認することが重要です。開発者は独自の統合テストと単体テストを作成できますが、機能と動作が完全であることを確認するために、機能テスト、回帰テスト、エンドツーエンドテストを実行できるQAチームを関与させることも不可欠です。

文書化は、モダナイゼーションで重要なワークフローの一部です。インライン・コメントを通じてコードに注釈を付けたり、詳細な変更ログを作成したり、包括的なアーキテクチャーと設計のドキュメントやその他の技術ドキュメントを作成したりして、ソース・コードの変更を文書化します。

いくつかのツールは、レガシー・コードのモダナイズのプロセスを高速化し、自動化するのに役立ちます。一般的なものは以下のとおりです。

● 静的コード・アナライザー

● コードの可視化アプリケーション

● テスト・オートメーション・フレームワーク

● 移行プラットフォームとツールキット

● ドキュメント・ジェネレーター

静的アナライザーは、プログラミング上の欠陥、品質の問題、さらにはセキュリティー上の脆弱性を見つけるためのレガシー・コードのデバッグに役立ちます。多くの静的コード分析ツールは、C、COBOL、PL/I、RPGなどの従来のプログラミング言語をサポートしています。静的コード・アナライザーの例としては、CodeSonar、Klocwork、オープンソースのPMDやSonarQubeなどがあります。

コード・ビジュアライザーは、ソース・コードをグラフィカルに表現し、特に大規模または複雑なコードベースの場合の動作をよりわかりやすく示します。これらのグラフィカル表現には、コード・マップ、フローチャート、統一モデリング言語（UML）図など、さまざまな形式があります。コード視覚化アプリケーションには、CodeScene、CodeSee、Understandなどがあります。

これらのフレームワークは、自動テストを作成して実行し、それらのテストに関するレポートを生成します。一般的なテスト・オートメーション・フレームワークには、Webアプリケーション用のCypressやSelenium、モバイル・アプリ用のAppiumなどがあります。

これらのプラットフォームとツールキットは、レガシー・システムの移行ワークフローを簡素化および自動化するのに役立ちます。主要な移行プラットフォームとしては、AWS Application Migration Service、Azure Migrate、Google Cloud Migration Toolkit、IBM Cloud Transformation Advisor、Red Hat Migration Toolkit for Applicationsなどがあります。

これらのツールは、ソース・コードやその他の入力ファイルからドキュメントを自動的に生成します。ドキュメント生成ツールには、Doxygen、Sphinx、Swimmなどがあります。

人工知能（AI）は、レガシー・コードのモダナイゼーションに役立ちます。生成AIアプリケーションは、複雑または巨大なレガシー・コードベースを分析できる大規模言語モデル（LLM）によってサポートされています。

生成AIは、次のようなレガシー・コードのモダナイゼーションを支援するために使用できます。

● コードの説明

● コード・リファクタリング

● コード変換

● テストの生成と文書化

生成AIは、レガシー・コードベースの基盤となるコンテキストとセマンティクスを理解できます。これにより、背後にあるロジックと機能を概説し、プログラマーが理解できる方法でコードを説明できるようになります。

AIを活用したツールは、リアルタイムのリファクタリング推奨事項を提供できます。例えば、IBM® watsonx Code AssistantはIBM® Graniteモデルを利用してバグを検知し、最適化機会を特定します。次に、チームの確立されたコーディング規則に沿ったターゲットを絞った修正を提案し、コードのリファクタリングを簡素化および加速します。

AIシステムは、従来のプログラミング言語からより現代的な言語にソースコードを実装する方法を提案できます。例えば、IBM watsonx Code Assistant for Zは、自動化と生成AIを組み合わせて、開発者がメインフレーム・アプリケーションをモダナイズできるように支援します。これらの生成AI機能には、COBOL、JCL、PL/Iのコード説明と、COBOLからJavaコードへの変換が含まれます。

テスト・オートメーション・フレームワークと同様に、AIコーディング・アシスタントもテストを自動的に生成できます。また、特定のコード・フラグメントまたはスニペットの動作を文書化するためにインライン・コメントを作成することもできます。

他のAI搭載アプリケーション同様、プログラマーはレガシー・コードをモダナイズするためにAIを使用する場合にも注意を払う必要があります。出力の正確性を確認し、提案された変更や修正をテストしてください。