Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

レガシーシステム洗い出し大作戦

 レガシーシステム洗い出し大作戦

Tomohiro Nishimura

August 18, 2018
Tweet

More Decks by Tomohiro Nishimura

Other Decks in Programming

Transcript

  1. システム移行の歴史 1. コア部分の開発 (Scala) ← 理想のはてブを作る 2. フロントエンド部分の開発 (Perl) ←

    理想のフロントエンドのベースを作る 3. データ移行 ← レガシーシステムのデータを理想の形に変換する 4. 面の移行 ← 実際に画面を移していく 5. それ以外の移行 ← 例えばAPIとか
  2. 面の移行時の洗い出し • 勘でIssueを登録していく ◦ 新たな仕様が発掘されたら Issueを追加する • Projectで管理 ◦ MAY/SHOULD/MUST

    ◦ BACKLOG/DOING/WAITING/確認/DONE ◦ まとめ・情報 • 依存関係は別のProjectを作って管理
  3. なぜこれまで出来なかったのか • 10年を超える歴史の中で増改築を繰り返した結果… • 膨大なコード量 ◦ → 全て洗い出すだけで年単位で工数が必要 ◦ →

    そんな工数取れないでしょという風潮 • 失われた経緯 ◦ → 考古学者のように辛抱強く過去を解きほぐす必要がある
  4. エンドポイント洗い出し時にあった方がよい項目 • Controller#Method (複数のURLが紐付いている可能性があるのでユニークな キーとして扱う) • エンドポイントのURL (複数あるなら検索用にそれも) • 調査時点のコードへのリンク

    (実装にすぐにたどり着きたい) • Issueへのリンク (対象について扱うIssueを作っておく) • 用途 (完全に理解したとしても翌日には忘れているので書いておく) • メモ (これ不要では???みたいなことを書く) • その他状態を表現するフラグ達
  5. エンドポイント単位でのリソース依存の洗い出し • 一行一依存として記録していくと扱いやすい ◦ → 後述 • まとめIssueを作って、各機能のIssueを紐づけていく ◦ →

    すべてのIssueがクローズされたら、そのリソースへの依存はなくなったとみなせる ◦ → まとめIssueに作戦を経緯として残し、各 Issueに細かい経緯を残す
  6. 視点 • 参照系の移行 ◦ → エンドポイント毎にリソースへの依存を明確にする ◦ → 依存の下流から移していけば安全 •

    更新系の移行 ◦ → グループ化して、グループ毎のリソースの依存と、グループ間の依存を明確にする ◦ → まとめて移行する必要がある ◦ → 依存の上流から移していけば安全
  7. まとめIssueからの洗い出し • 次はまとめIssueを起点に漏れていたものを調査する ◦ たとえば内部的な機能があったりする ◦ ステークホルダーを明らかにする • どんどんIssueを作ってまとめIssueに紐づけていく ◦

    すべてのタスクが洗い出せている状態を目指す • このタイミングで別の切り口のまとめIssueができるかもしれない ◦ 「ユーザー向けAPI移行作戦会場」とか「 XXX(サービス名)が使っているAPI一覧」とか ◦ ロール単位、機能単位、用途単位などのまとめ Issueが出来ていた
  8. ポイント • 最初に切り口を決めて、その中での優先度順に洗い出していく ◦ → すべてを洗い出すのは無理だし、どこから手を付けるかを決める ◦ → 機械的に洗い出せるところを起点にすると楽 ◦

    例「サーバーの移行が先決、このサーバーを潰すにはこのサーバーが管理しているリソースを使わ なくなればよい、エンドポイントごとにリソースの依存を洗い出そう」 • その結果を使って、別の切り口で関連するものを洗い出していく ◦ → 複数の視点で洗い出さないと漏れができる ◦ → 関連するものを見ればいいので取り掛かりやすい
  9. 機能廃止について • 断捨離のチャンスなので機能の整理をして、工数も削減するとよい ◦ 全ての機能を移行する必要はない ◦ もう使われていないものもある ◦ 依存が複雑すぎて移行の工数を考えると廃止した方がマシな場合がある •

    廃止したい機能一覧を作って、1つ1つ検討、調整をした ◦ 確定したものから廃止していく ◦ レガシーシステムから機能やコードを剥がせば剥がすほど移行は楽になっていく