SRP――一つの共有先の定義は、一つの理由で変わるか

分けすぎると、1つの依頼が散らばる

ここまで読むと、「では、もっと細かく分けたほうが良いのでは」と思うかもしれません。名札カードの項目を、URL・表示名・色・アイコンと、1項目1ファイルに分けてみたらどうなるでしょうか。SRPの問いは、分けすぎの側にも答えを持っています。

X がロゴと色を変えたとします。項目ごとに分けた形では、x-color.toml と x-icon.toml の2枚を開くことになります。依頼主は X の1人なのに、変更はファイルをまたいで散らばります。この状態は散弾銃手術と呼ばれ、先ほどの発散的変更と対になる言葉です。今の形なら、x.toml を1枚開けば済みます。分ける線は、細かさではなく、依頼主の境目に引くのが SRP の答えです。

散らばることの困りごとは、開くファイルが増えることだけではありません。ロゴを変えて色を変え忘れる、という「一緒に変えるはずだったものの片方だけが変わる」事故が起きやすくなります。引っ越しの住所変更で、銀行には届けたのに携帯電話の会社には届け忘れた、という状態です。1か所にまとまっていれば、関連する項目を一緒に確認しやすくなります。

分ける細かさには、ちょうどよい目盛りがある

発散的変更と散弾銃手術は、同じ物差しの両端にあります。まとめすぎると別々の依頼がぶつかり、分けすぎると1つの依頼が散らばります。

物差しの目盛りを「細かいほど良い」「まとめるほど良い」のどちらかに合わせるのではなく、依頼主の境目に合わせます。このプラグインでは、それが「共有先ごとに1枚」でした。1つの SNS の決まりは1枚にまとまり、別の SNS とは別の紙に分かれます。細かさの正解は、ファイルの行数からではなく、依頼主の数から決まるのです。

依頼主は、変わる時期で見分ける

とはいえ、実際のファイルを前にして「これは別の依頼主か」を見分けるのは、慣れないうちは難しいものです。手がかりになるのが、変わる時期です。

SNS各社の変更は、各社の都合でやって来ます。サイトの運営者の変更は、キャンペーンやデザインの見直しに合わせてやって来ます。ブラウザと標準の変更は、ブラウザの更新に合わせて、保守する開発者の変更は、開発の予定に合わせてやって来ます。変わる時期がそろわないものは、別の依頼主を探す候補になります。逆に、いつも同じ時期に一緒に変わるものは、同じ依頼主の持ち物だと考えて、同じ場所に置きます。

変わった時期は、変更の履歴から読み取れます。git log に日付を出す指定を付けて、ファイルごとに並べてみると、「このファイルとこのファイルは、いつも同じ日に変わっている」「このファイルだけは、ほかと関係のない日に変わっている」といった傾向が見えてきます。いつも同じ日に変わる2つのファイルは、同じ依頼主の持ち物が分かれて置かれているのかもしれません。ほかと関係のない日に変わるファイルには、別の依頼主がいるのかもしれません。

ただし、日付は依頼主を断定する証拠にはなりません。年末の一括整形、依存ライブラリの更新、複数の機能をまとめたコミットでも、多くのファイルが同じ日に変わります。反対に、一つの仕様変更を数日に分けて実装することもあります。同じ日に変わったという印は、理由を読みに行くための手がかりです。

履歴から候補が見つかったら、コミット本文や関連Issueで、何を実現したかったかを確かめます。「この二つはいつも一緒だ」と気づいたあとに、「なぜ一緒だったのか」を一文で説明できるかを見ます。その一文が書けなければ、まだ分け方を決めず、調べる候補として置いておけます。日付の相関だけでファイルを移動するより、判断を急がないほうが確実です。

プラグイン全体にも、依頼主の境目がある

ここまでは名札カードと設定ファイルを数えてきました。同じ問いは、プラグインのコード全体にも当てられます。ブラウザで動く部分（web/src）は、仕事の種類ごとにフォルダが分かれています。それぞれのフォルダに、誰が変更を頼んでくるかを並べてみました。

domain には共有URLの決まりがあり、変わるきっかけは SNS 各社です。application には並び・言い回し・色の上書きのような、サイトの判断を形にするコードがあります。infrastructure はブラウザのコピーや共有画面を呼び出す部分で、ブラウザと標準が変わったときに直します。presentation はボタンの見た目、composition は部品の組み立て、generated は生成器が作るファイルです。

フォルダの境目は、おおむね依頼主の境目に沿っています。ここで「おおむね」と書いたのは、application と presentation の2つに、どちらもサイトの運営者の依頼が届くからです。ただ、application は「何を出すか」、presentation は「どう見せるか」と、同じ依頼主の中でも仕事の種類で分かれています。4ページ目で見た「データは依頼主で、コードは仕事の種類で」が、ここでも同じ形で出ています。1つのフォルダに、仕事の種類の違う複数の依頼主が来るようになったら、そこが次に分ける候補です。

SRPを確かめる4つの問い

ここまでの話を、ファイルを見るときの問いにまとめておきます。同じ4つの問いで、今の x.toml と、3ページ目で考えた「並び順入り」の x.toml を採点してみました。

このファイルに変更を頼むのは誰か。その人の変更は、このファイルだけで済むか。別の依頼主の変更で、ここを開くことはないか。中身は同じ時期に、同じ理由で変わるか。4つとも「はい」なら、ファイルの境目は依頼主の境目と重なっています。並び順入りの形は、2つ目の問いにしか「はい」と答えられません。

四つの問いも、設計の合否を自動で決める採点機ではありません。「はい」が並んだら、現在想定している変更に対して、境目の説明ができたということです。まだ来ていない依頼や、組織の役割の変化まで証明したわけではありません。図の印の横に、そう答えた具体的な変更を一つずつ添えると、あとで判断をやり直せます。

「別の依頼主はいない」と断言しにくいときは、その迷いも役立ちます。たとえばロゴの既定色はSNSの都合、読みやすくする色の上書きはサイトの都合、と言い直せば、同じ色という項目の中にも境目が見つかります。原則の名前を知っているかより、迷った例をどこへ置くかを話せることのほうが、実際のレビューでは役に立ちます。