古いコードを最新化するには、まず考古学が必要です

古いコードで最も難しいのは、構文が古いことではなく、時代が古いことです。プロジェクトには、build.xml、古い JDK、古いテスト フレームワーク、および古いパッケージ化メソッドが詰め込まれています。表面的には、いくつかのファイルの山のように見えますが、実際には歴史的な前提が何層にも積み重ねられています。コード自体は最外層にすぎません。多くの場合、実際に配信を妨げるのは、これらの前提がまだ存在するかどうか、再現できるかどうか、変更後に古い動作が失われるかどうかです。

「考古学」が「変容」に先立つのはこのためです。最初にビルド ファイルを確認し、次に依存関係、次に実行環境、次にテストを確認します。順序を逆にすることはできません。 build.xml はまだ存在しますが、pom.xml は存在しません。このようなシグナルは、プロジェクトが Ant 時代に生きていることを示すのに十分です。コードをコンパイルできるかどうか、テストを実行できるかどうか、製品を再構築できるかどうかが最初の証拠です。ここでのモデルの最も役立つ部分は、古いコードにすぐに新しいコードを書くことではなく、断片の山からこれらの証拠を特定することです。

環境も最初に固定する必要があります。古いコードには、古い JVM、古いコンテナ、古いアーキテクチャの前提条件が伴うことがよくあります。特にクロスアーキテクチャ環境では、それを今日のマシンに直接投入すると、問題が発生したときに新たなノイズが混入しやすくなります。つまり、コードが本質的に壊れているのか、それともトラブルの原因となっているのはエミュレーション、ミラーリング、ツールチェーンなのかなどです。この段階で「同じコードを同じ環境で安定して再現できる」ことさえ達成できなければ、その後のモダナイゼーションのアクションはすべて単なる推測になってしまいます。

このステップにおける AI の価値は明らかです。AI は文字レベルおよび構造レベルの翻訳に役立ちます。 Ant から Gradle への変換、古いビルド スクリプトの保守可能な形式への変換、反復的な XML とボイラープレートの束をより明確な場所に移動することはすべて、モデルに任せるのに適した候補です。高速で、何度も試行する意欲があり、あまり簡単ではありません。しかし、それは審判には向いていません。どの警告を最初に保持できるか、どのテストが実際に嘘をついているか、どのモジュールを最初に切断する必要があるか、どのクラスのみをパッケージ化して適応させる必要があるか。結局はやはり人が決めるしかないのです。

テストは人々をだます最も簡単な方法です。古いプロジェクトでテストに合格したからといって、そのシステムが理解されたことを意味するわけではなく、一部の古い動作が現在の環境にラップされているだけである可能性があります。その「オールグリーン」の感覚は、より大きな問題を覆い隠してしまうことが多いため、危険です。テストで検証されるのは、現在保存する必要があるビジネス セマンティクスではなく、特定の時代の実装の詳細です。本当に改革したいのであれば、まずこれらのテストを「飾りの安心感」から外し、何を守っているのかを再判断することだ。

したがって、このタイプのプロジェクトの最も安定した方法は、通常、一度に書き直すのではなく、最初に古い環境、古い動作、古い依存関係を修正するタイム カプセルを作成し、それを最も狭い亀裂に沿って削除することです。まずシステムを再現可能にし、次に反復作業を AI に渡して翻訳し、レイヤーごとに境界を剥がしていきます。順序が狂っている場合、モデルは古いプロジェクトを加速し、より深い混乱に押し込みます。順序が正しければ、モデルは真に有用な考古学アシスタントのようなものとなり、レンガを動かしたり、ほこりを掃除したり、証拠を比較したりする責任を負い、人々を汚れ仕事から解放し、判断を彼らの手に委ねることになります。