こちらの発表を聞いたメモｋ＿￥ レガシーソフトウェアの定義を「動き続けてもらわないと困るが、面倒なことになっているソフトウェア」とと定義する
- 確かにこういうのあるな...
発表者の Tokotaso さんの（前職の）記事
- 挙動を可能な限り維持しながら移行するためのノウハウ
- 問題が起きる範囲を最小限にする移行戦略の立案や、性能問題・考慮漏れを想定した移行の実施
重要なポイントは4つ
Hyrum の法則
API の仕様書やドキュメントがあったとしても、実際は考慮されていない挙動はどこかに存在しており、利用者はその挙動に依存したコードを書いてしまっていることがある。
- 本当は順序保証が無いのに、API利用者が順序に依存した挙動を実装してしまっている、など。
この点に気をつけながら移行を進める。
仕様化テスト
『レガシーコード改善ガイド』に出てくる話
挙動がわからないコードが出てきたときに、徹底的にテストコードに落とし込む
- レガシーコードをリファクタリングした時に常にリグレッションテストを実行できるようになる
ダークローンチ
実際のユーザーから発信したトラフィックをコピーして新サービスに送信して差分を見る。
これで判明した使用を仕様化テストに落とし込む。
ストラングラーフィグパターン
新サービスの割合を徐々に増やしていく移行方法。
