公開した瞬間、相手のコードが自分の仕様になる

関数の引数を1つ増やす作業を考えます。自分のリポジトリの中だけで使われている関数なら数分です。引数を増やし、呼び出し箇所をたどって全部直し、型検査で直し漏れが無いことを確かめる——それで完了です。

同じ変更を、公開したライブラリの関数に行うとどうなるか。**作業そのものは同じ数分で、難しくなったわけではありません。**変わったのは、呼び出し箇所を全部たどるという手順が実行できなくなったことです。公開したAPIを変えられないのは、呼んでいるのが誰かを列挙する手立てが無いからです。

だから境目は「外に出したかどうか」であって、版番号でも社内/社外でもありません。列挙できない呼び出し元が1つでもあれば、そこから先は変えられない側です。

ここまでで対処が見えた気がします。公開範囲を宣言し、書いたことだけを守り、書いていないことは自由に変える——閉じそうに見えます。

ところがこの閉じ方には、規格ではなく観察として報告されている綻びがあります。hyrumslaw.com の著者はこう要約しています。

With a sufficient number of users of an API, it does not matter
what you promise in the contract: all observable behaviors of
your system will be depended on by somebody.

突き詰めるとこうなる、として挙げられているのが Given enough use, there is no such thing as a private implementation です。例が分かりやすい。応答の速さは何も保証していないのに、利用者は実装が出している速さを期待するようになる、と。速さは約束の外側ですが、外から観測はできます。観測できるものは依存されうる。

右列で起きているのは、検査の場所が自分の手元から利用者の側へ移ったということです。移ったあとは、壊したかどうかを出す前に知る手立てがありません。だから「どの変更が破壊的か」を事前に判定する必要が生まれます。**判定表が要るのは、判定しないと分からなくなったからです。**判定そのものは既存のAPI設計クイズ群が扱います。