古いシステムを最新化する際、Copilot はまず証拠を整理します

初めて 1.5 時代の Java プロジェクトを最新のマシンにプルしたとき、最初に現れたのはコードの問題ではなく、証拠の問題でした。ビルドを再現できるかどうか、テスト出力が同じかどうか、障害点が JVM、イメージ、またはソース コードに由来するかどうか、これらのことが「リファクタリングを開始する」よりも前にどのように進めるかを決定します。古いシステムを最新化するときに最も懸念されるのは、変更が遅いことではなく、変更後に何が起こったのかが分からないことです。

まずシーンを修正すると、その後のアクションが意味のあるものになります。このステップで最も価値があるのは、IDE での完了ではなく、繰り返し実行できるボックスです。古い JDK、古いビルド ツール、古い入り口、古いテスト コマンドはすべて Docker にロックされています。次のようなコマンドは見栄えは良くありませんが、機能します。

docker run --rm -v "$PWD":/src -w /src legacy-jdk8 \
  sh -lc './gradlew test 2>&1 | tee logs/baseline.log'

このコマンドの機能は 1 つだけです。「今日の失敗」を再現可能な証拠に修正することです。それがなければ、その後のすべての成功は、たまたま恵まれた状況の結果に過ぎないかもしれません。ここでの副操縦士の役割も非常に明確です。これは判断に代わるものではありませんが、トレースを整理するのに役立ちます。長いログで繰り返されるエラー、ビルド スクリプトで相互にエコーするパス、古いテストで繰り返されるいくつかのエントリはすべて、最初の大まかなスクリーニングに使用できます。ふるいにかけられるのは結論ではなく、出発点となる地図です。

実際にナイフを使う段階になると、変化の範囲は非常に狭くなるはずです。古いプロジェクトを覆す最も簡単な方法は、パッケージ名、ビルド、エントリ、テストをすべて一度に変更することです。結局のところ、どのステップがシステムを破壊したのかさえわかりません。より安定したアプローチは、最初に最小のギャップを確保することです。たとえば、古い入り口をアダプターの層で覆い、最初に新しいツール チェーンを古い世界の外側に立って構造を明確に確認してから、ゆっくりと内側に移動します。Copilot は、インポートの埋め込み、構成の移動、繰り返しフラグメントの抽出、および一時的なテスト スケルトンの生成など、この種の機械的な作業を処理するのに非常に適しています。モデルにこれらのことを実行させると、効率は確かに高くなります。しかし、この継ぎ目を切断すべきかどうか、また切断後にどのような動作を保持すべきかを決定するのは依然として人々に任されています。

テストに関しても、見た目に騙されやすいです。古いテストに合格したからといって、近代化が安全であるという意味ではなく、特定の歴史的な行為がまだ解体されていないことを意味するだけです。多くの古いプロジェクトのテストは、ビジネス セマンティック仕様というよりも動作スナップショットに似ています。緑は単なる緑であり、そのまま「システムを理解している」と解釈することはできません。変換中の最も重要なアクションの 1 つは、テストが「歴史的遺産」から「現在の制約」に徐々に変化するように、それぞれの小さな切開に新しく狭いテスト境界を追加することです。 Copilot は、古いアサーションを分解し、テンプレートを完成させ、重複したテスト シェルをロールアウトするのに役立ちます。ただし、テストでどのセマンティクスを維持する必要があるか、モデルはシステムに対して決定を下すことができません。

考古学の近代化において、最も信頼できる分業は実際には非常にシンプルです。環境と丸太は事実を解明する責任を負い、副操縦士はレンガを移動して翻訳する責任を負い、人々はどの歴史を保持すべきか、どの歴史を遮断すべきかを決定する責任を負います。システムの過去を説明するためにモデルが整理されると、証拠よりも推測の方が説得力を持つことがよくあります。それを証拠管理と機械的組織の位置に戻すと、より真に役立つアシスタントのようなものになります。