legacy-modernization

レガシーシステムのモダナイゼーション

稼働中のシステムを段階的に移行します。あらゆる判断を左右する制約は、システムが本番環境で稼働しており、変更中も動き続けなければならないことです。

手順

個々の手法よりも順序が重要です。それぞれの手順は、次の手順を安全に進めるためにあります。

1. 変更前に特性を把握する。 現在の動作を固定するテストを、バグも含めて作成します。コードが本来どう動くべきかをテストするのではなく、実際にどう動くかを記録し、動作の差分が見えるようにします。アサーションが間違っているように見えるなら、そこが重要な点です。記録し、そうだと明記しましょう。

   def test_domestic_lightweight():
       order = {"weight": 5, "destination": "domestic", "priority": False}
       # Current behaviour: nothing charged under 10kg. Looks like a bug —
       # pin it here, fix it as its own change after the migration lands.
       assert calculate_shipping_cost(order) == 0.0
   

   承認テスト（approvaltests、syrupy）やゴールデンマスターテストを使うと、複雑なコードを最も手早くカバーできます。最初にコードを理解する必要はなく、出力全体を記録できるためです。

   次に、テストの網が実際に機能しているか確認します。変更する予定のコードにミューテーションテストを実行してください。特性把握用のテストスイートは、十分に網羅しているように見えても、これから変更する分岐を見落としがちです。生き残ったミュータントを調べれば、インシデントが起きる前に見落とし箇所がわかります。

2. 継ぎ目を設ける。 抽象化による分岐を取り入れます。置き換える対象の上にインターフェースを導入し、古いコードに処理を委譲したまま、すべての呼び出し元をそのインターフェース経由にします。これは、それだけでリリースして検証できる、動作を変えない変更です。

3. 継ぎ目の背後に置き換えを構築する。 非公開にするか、フラグで無効にしておきます。まだトラフィックを処理していないため、間違っていても問題ありません。

4. フラグを使ってトラフィックを段階的に移行する。内部ユーザーから始め、次に一部の割合、最後に全体へと広げます。各段階はフラグを切り替えるだけですぐに戻せます。この性質があるからこそ安全です。移行率を上げる前に、ロールバックの条件を指標としきい値で決めておきます（「エラー率が5分間0.5％を超えたら、前の割合に戻す」）。問題の基準を発生中に決めると、移行率を戻す代わりに議論になってしまいます。

5. 新しい経路が本番環境で十分な期間、問題なく稼働してから、古い経路を削除する。 月末処理、季節的なピーク、年次報告など、処理に時間がかかるケースをカバーできる期間が必要です。早く削除すると、誰も覚えていなかったコードパスの存在に気付くことになります。

規約

• 一斉書き換えは行いません。 書き換えは動き続ける目標を追いかけることになります。新しいシステムが追いつく間も、古いシステムでは機能のリリースが続くからです。このプレイブックにあるモダナイゼーションがすべて段階的なのはそのためです。
• すべての手順をリリース可能にし、元に戻せるようにします。 完了して初めて機能する移行には、安全に中止できる時点がありません。長期にわたる移行は、必ず何かに中断されます。
• 金額や状態を計算するものは、切り替え前に並行稼働させます。 同じ入力を古いシステムと新しいシステムに渡し、出力を比較して差異を記録しながら、古い結果の提供を続けます。顧客から報告される差異より、目に見える差異のほうが適切です。
• 全体構成にはストラングラーフィグパターンを使います。 前面にファサードを置き、機能ごとに古いシステムか新しいシステムへ振り分けます。経路を一つずつ移行し、古いシステムに何も届かなくなったら削除できます。
• バグも含め、既定では動作を維持します。 風変わりな挙動にも、下流のシステムが依存している可能性があります。バグの修正は、個別の、わかりやすい変更として行います。動作の変更と移行の不具合を区別できなくなるため、移行に組み込んではいけません。
• データベースの移行は拡張と縮小の手順で進めます。 新しいカラムを追加し、二重書き込みを行い、既存データを埋め戻してから、読み取り先を切り替え、最後に古いカラムを削除します。各フェーズは単独でデプロイ可能で、その隣で稼働しているコードのバージョンとの互換性を保ちます。
• レガシーシステムを対象に書く新しいコードにも、現在の標準を適用します。 「一貫性のため」に周囲のスタイルへ合わせると、モダナイゼーションの結果、開始時よりレガシーコードが増えてしまいます。