共有先が増えても触らないコードを決める
作成： ／ 公開： ／ 内容更新：
執筆：tamito0201 ／ 掲載・運営：プロマリ
丸い共有ボタンの裏側を掘る連載の第2回。共有先が増えても書き換えないコードを先に決め、共有先の違いを「名札カード」と呼ぶデータファイル（TOML）へ寄せた設計を、架空の共有先を1つ足した差分の実測と図12点でたどります。
触らないはずのコードに、手が入るとき
ここまで、うまくいった話ばかりでした。フェアではありませんね。この境目が効かない場面も、同じ精度で見ておきます。
名札カード（共有先ごとの TOML ファイル）で吸収できるのは、「どこへ何を渡すか」の違いまでです。クリックで何をするかの種類——新しいタブや小窓で開く、URLをコピーする、端末の共有画面を呼ぶ——の3つは、列挙型として決め打ちされています。
もし4つ目の種類が必要になったら（あくまで仮の話です）、生成器の列挙、TypeScriptの列挙、判断の分岐、実行の分岐と、境目の内側に次々と手が入ります。境目の位置は、「何が増えそうか」という見通しで決めています。共有先は増えると見込んだので差し込み口にし、動作の種類は増えないと見込んだので決め打ちにしました。見通しが外れたら、境目の内側に手が入ります。それを隠さずに書いておくことも、設計の一部だと考えています。
間違った宣言は、生成の時点で止まる
名札カード方式には、もう1つ心配の種があります。定義が「ただのデータ」なら、書き間違えても誰も気づかないのでは？ という心配です。
生成器は、名札カードを読み取るときに5つの門で検査します。名前が英小文字と数字だけか。名前がファイル名とそろっているか。アイコンと色の書式は正しいか。宛先と渡す項目の組み合わせに矛盾がないか。設定ファイルに知らない共有先が書かれていないか。知らない項目名が1つ混ざっているだけでも止まります。どれか1つでも引っかかれば、束を作らずに止まります。怪しいときは通さない側に倒すこの作法をfail-closedと言います。書き方の間違いは、ブラウザに届く前に止まるので、読者の画面で壊れたボタンが見つかる、という順番にはなりません。
考えてみる：検査を5つも置くと、共有先を足すのが面倒にならない？
正しく書いた名札カードは、5つの門を黙って通ります。手間が増えるのは書き間違えたときだけで、そのときは「どこが違うか」を教えてもらえます。面倒なのは、間違いが本番の画面まで届いてから、読者の報告で気づくほうです。検査は、足す人の手間を増やす仕組みではなく、足したあとの確認を肩代わりしてくれる仕組みだと考えると、置く場所が見えてきます。
手を動かして確かめる
今回の答え合わせは、手元でも再現できます。公開中のプラグインを複製し、架空の共有先を1つ足して、差分の数を数えてみてください。
git clone https://github.com/tamito0201/promari-toolkit.git
cd promari-toolkit && git checkout promari-sns-share-v4.0.0
pnpm install --frozen-lockfile
cd plugins/promari-sns-share
# destinations/example.toml を置き（x.toml を写して書き換える）、
# config/share_config.example.toml の [share.secondary] に example = true を1行足す
pnpm run check # 作り直し前は止まる
pnpm run build # tools/config.py --write で作り直す
pnpm test && pnpm run test:py
git add -N destinations/example.toml && git diff --stat合格条件は、web/src の差分がゼロであること。destinations/example.toml の中身は、x.toml を写して key・label・endpoint・[params]・色を書き換えれば作れます。Python は 3.13 以上が必要で、別の場所にある場合は PYTHON 環境変数で指定できます。3件のテスト失敗が出たら、この記事の答え合わせと同じところまで来た合図です。
開放閉鎖の原則の原典に当たりたい方は、Robert C. MartinによるThe Open Closed Principleが読みやすい入口です。URLの符号化の決まりはRFC 3986にまとまっています。
まとめと、次回
第2回のまとめです。共有先は、これからも必ず増えます。だから今回の実装は、書き始める前に増えるもの（共有先の名札カード）と、増えても変わらないもの（組み立て・判断・表示）を分け、共有先ごとの違いをすべてデータの側へ寄せました。実際に1つ足してみると、ブラウザ側のコードの差分はゼロ。作り直しの忘れと書き間違いは、生成器の検査が止めてくれます。一方で、動作の種類が増えるような変更には、境目の内側まで手が入ります。境目の位置は、何が増えそうかという見通しで決まるのです。
次は連載1.3「ADRに残すのは結論より、捨てた案と制約」です。今回「分岐のはしご」を選ばなかったように、設計には必ず選ばなかった案があります。結論だけを書き残すと、なぜその案を捨てたのかが、半年後の自分にも分からなくなる。その記録の残し方を、実際の決定記録を題材に見ていきます。それでは、次回もお楽しみに！
連載の全体像は本編の連載目次へ。前回の1.1「共有・保存・計測は、なぜ同じ責務にしないのか」とあわせて読むと、責務の分け方から拡張点の決め方までが一続きになります。
プロマリでは、Webサイトの制作に加えて、共有や計測のような「裏側のしくみ」の設計・導入、それらを運用できる人材の育成に取り組んでいます。自社サイトの部品設計を見直したい方は、お気軽にご相談ください。
記事で解説した拡張点の決め方を、実際のコードで確かめるための資料です。
この記事全体の感想・質問・設計へのコメント