# ストラングラーフィグ ## 定義 ストラングラーフィグパターン(strangler fig pattern)は、[[Martin Fowler]]が提唱・普及させた、レガシーコードベースを書き換え・移行するための技法である。単一のツールではなく手順の集合であり、(1) 新旧コードをつなぐ移行アーキテクチャを構築する、(2) インターフェースを定義する、(3) 移行対象の部分を抽出する、(4) 旧コードと新コードの両方にリンクする、(5) データソースを論理的に分離する、(6) 書き込みを新ソースへ切り替える、(7) データをバックフィルする、(8) 読み取りを新ソースへ切り替える、(9) 最後に旧コードを廃止する、という順序を踏む。すべての本番コードはいずれレガシーコードになるため、最初から観測可能な(observable)つなぎ目を持つコンポーネントを構築しておくことが将来の自分への贈り物になるとされる。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]]) *Observability Engineering* 第2版第2章では、この技法はキャプチャ・リプレイ、トラフィックスプリッタと並ぶ「ボーナスプラクティス」として、特性テスト(characterization testing)・プロパティベーステスト計画を補完する特殊用途の技法として位置づけられる。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]]) ## 横断的知見 - (現時点では本概念に関連する source は本ページの元になった1章のみ。他ソースとの突き合わせは今後の ingest で蓄積する。) ## 未解決の問い - ストラングラーフィグパターンの各段階(データソースの論理分離、書き込みの切り替え、バックフィル、読み取りの切り替え)を、オブザーバビリティのテレメトリでどう検証するのが実務上のベストプラクティスか。本章はこの技法を紹介するのみで、検証方法までは踏み込んでいない。 - トラフィックスプリッタ(新旧APIの応答を並行取得して比較する技法)とストラングラーフィグパターンを組み合わせた移行事例はあるか。両者とも本章の同じ節で紹介されるが、併用の具体例は記述されていない。 ## 関連 - 概念: なし(現時点で関連 concept は未接続) - エンティティ: [[Martin Fowler]] - ソース: [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]] ## 出典 - [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]] — "Bonus Practices: Traffic Splitters, Capture/Replay, Strangler Figs" 節