共有先が増えても触らないコードを決める

宿題の答え合わせ：1つ足したときの差分

ここまでで、共有先は名札カード（共有先ごとの TOML ファイル）で宣言し、URLの組み立ては1か所にまとめる、という作りを見てきました。では、本当に共有先を1つ足しても、ほかのコードには触らずに済むのでしょうか。この問いは、前回（1.1）の最後に出した宿題でもあります。前回の「手を動かして確かめる」では、共有先を1つ足したときに、触ったファイルを置き場所ごとに数える宿題を出しました。合格条件は、保存と計測の置き場所に差分がゼロであることです。ここでは、その答えを実際に共有先を1つ足して確かめます。公開中のプラグインを手元に複製し、架空の共有先 example を1つ足して、差分を数えました。実際のプラグインには入れていない、この実験のためだけの共有先です。

1.1の宿題に寄せられたコメントもあわせてどうぞ。ほかの読者が数えた結果と、ここでの答え合わせを見比べられます。

手順は、プラグインの追加手順書（customization.md）の「Add a destination」に書かれているとおりの3つです。1つずつ見ていきましょう。

1つ目は、名札カードのファイルを1つ置くことです。destinations/ フォルダに、共有先の名前（key）と同じファイル名で TOML ファイルを作ります。名前とファイル名がそろっていないと、生成器が止めます。今回の実験で置いたファイルは次のとおりで、コメントと空行を含めて11行です。アイコンのSVGは長いので省いています。

# Example: 実験用の架空の共有先。
key = 'example'
label = 'Example'
brand_color = '#EF4056'
action = 'open'
endpoint = 'https://example.com/share'
icon = '<svg …>…</svg>'

[params]
url = 'url'
title = 'title'

2つ目は、設定ファイルに1行足すことです。名札カードを置いただけでは、共有欄にボタンは出ません。どの共有先を、大きなボタンと小さなアイコンのどちらに並べるかは、設定ファイルが決めているからです。今回は小さなアイコンの列（[share.secondary]）の最後に、example = true の1行を足しました。

[share.secondary]
hatena = true
linkedin = true
email = true
copy = true
native = true
example = true

3つ目は、生成器で作り直すことです。名札カードと設定ファイルを読み込み、ブラウザ用の一覧と束を作り直します。手順書のコマンドは tools/config.py --write で、プラグインではこれを pnpm run build から呼べるようにしてあります。

pnpm run build
# 中身は次のコマンドと同じです
python3 tools/config.py --config config/share_config.example.toml --write

足すのは、名札カード1枚と設定1行。あとは生成器が作り直すだけです。

差分が出たファイルは4つでした。新しい名札カードが11行、設定ファイルの1行、テストの期待値の3行、そして生成器が作り直したブラウザ用の束です。一方で、ブラウザ側のコード（web/src）の差分は0行でした。URLを組み立てる ShareDestination も、クリックの判断をする ShareActionPolicy も、共有欄を描く ShareBarView も、計測へ知らせる部品も、1行も変わっていません。触らないと決めたコードは、本当に触らずに済んだ。これが答えです。

保存と計測の置き場所は、もちろん差分ゼロで、前回の合格条件を満たしています。今回はもう一段踏み込んで、共有の箱の中でも「増えても変わらないもの」の棚に差分がゼロであることまで確かめたことになります。

作り直しを忘れたら、機械が止める

差分の数え方で、気づいた方もいるかもしれません。ブラウザ用の束は人が書くものではなく、生成器が作るものです。では、ファイルを足したあとで作り直しを忘れたら、どうなるのでしょうか。これも実際に試しました。

ファイルを置いただけの段階で、生成器の検査（–check）が「配布物が古くなっています。–write で再生成してください」と止まりました。ブラウザ用の束は、元のデータファイルから作られる生成物です。元が変わったのに作り直していなければ、検査が食い違いを見つけます。設定ファイルに1行足す前の時点で止まったのは、共有先の一覧がデータファイルから直接作られているためです。

–write で作り直してからもう一度検査すると、「配布物は最新です」と通りました。作り直しを、人の記憶ではなく機械の検査で守る。手順が1つ増えた代償を、忘れても止まる仕組みで払い戻している形です。

テストに差分が出るのは、悪いことではない

作り直したあとにテストを走らせると、Pythonのテストが3件失敗しました。一瞬ひやりとしますよね。ただ、中身を見ると事情が分かります。

失敗したのは、同梱している共有先の一覧を名指しで確かめるテスト、その並び順を確かめるテスト、設定ひな形の一覧を確かめるテストの3件でした。どちらも「何を同梱したか」をわざと固定して見張る役目を持っています。共有先を足したのですから、見張りが気づくのは正しい動きです。こうしたテストの期待値を3行直すと、すべて合格しました。ブラウザ側のテスト63件は、最初から最後まで全件合格のままでした。