後方互換性

後方互換性とは

あるコンポーネントを変更する時、そのコンポーネントに依存する別のコンポーネントが、修正をせずに動き続けられるような性質

後方互換性は、１つのアプリケーション内のクラス間にも、サーバー・クライアント間にも、サーバーアプリケーション・RDBMSの間にも、「マイクロサービス」間にも、存在する

後方互換性のない修正は :shit: だ

なぜなら、その修正をリリースするためには、リリースのタイミングで、それに依存する全てのコンポーネントを更新する必要が生まれるから

趣味アプリなら好きなだけサービスを停止できるので可能かもしれない

じゃあどうすればいいの？

ケースバイケースではあるが、概ね以下の手順でやる

I/Fを変更したい気持ちになる

I/Fを変更しない内部実装の修正は自明に後方互換性を持つため、本記事のスコープ外である

新旧両方のI/Fをサポートする実装をリリースする

利用者側に、旧I/Fを利用しない実装に変更するように要請する

全利用者が新I/Fに移行し終わったタイミングで、旧I/Fを廃止する

例： JSON APIの場合

JSONのpropertyの名前を変えたいとき、以下の手順を踏む

古いpropertyを残しつつ、新しいpropertyを追加する

クライアントが古いpropertyに依存しなくなるのを待つ

古いpropretyを削除する

APIのEndpoint URLを変えたい

古いURLへのアクセスを新しいURLへリダイレクトするようにする

クライアントが新しいEndpoint URLに移行するのを待つ

古いURLを削除する