URL リファクタリングの影響範囲と対応方針を考えてみた

Tadashi Shigeoka ·  Sat, August 3, 2019

URL を変更するリファクタリングをおこなう上で考えられる影響範囲についてリストアップしてみた内容をご紹介します。

Refactoring | リファクタリング

前提条件

https://example.com/item/123

という URL を

https://example.com/items/123

という風に item から items に変更するリファクタリングをしたいとします。

このリファクタリングをおこなう上で、考えられる影響範囲について以下にリストアップしてみました。

?そもそも、URL が変わるような修正を『リファクタリング』と呼ぶべきか、否かはここでは議論していません。

外部サイト・チャネル、サイト分析ツールへの影響

URL リファクタリングをおこなう上で、

  • 外部サイト
  • メルマガ
  • SNS

などからリンクされた URL のことを気にかけておかないといけません。何も考えずに URL を変更するとデッドリンクになってしまいます。

また、Google Analytics などのアクセス解析サービスの数値にも影響があります。アクセスログを集計していれば、その集計プログラムも更新する必要があるでしょう。

対応方針

そもそもリファクタリングしない

まず、このリファクタリングの費用対効果について考えましょう。

単数形から複数形へ変更する、s 無しから有りへの変更によって、得れるもの・失うものを比較して、得れるものが多ければリファクタリングすれば良いと思います。

しかし、「s がある方が正しいから」とかエンジニアのエゴだけで安易に変更すると、元の URL にアクセスできなくなるという盛大なバグを発生させることがあります。

301 redirect

  • AWS ALB や Nginx などで /item/:id へのリクエストを /items/:id へ 301 redirect する設定をする
  • ソースコードで /item/:id へリクエストさせるコードを全て書き換える

この二段構えで対応するといいと思います。

以上、URL リファクタリングによってデッドリンクになったり、機能が動かなくなることは絶対に避けたい、現場からお送りしました。