共有・保存・計測は、なぜ同じ責務にしないのか
作成： ／ 公開： ／ 内容更新：
執筆：tamito0201 ／ 掲載・運営：プロマリ
丸い共有ボタンの裏側を掘る連載の第1回。共有・保存・計測という3つの仕事を、変更の理由・変わる速さ・背負う約束で見分け、分けた理由と払った代償の両方を、図12点と実装コードでたどります。
分けることは、無料ではない
ここまで、分けた利点ばかりを並べてきました。フェアではありませんね。分けた構成が払っている代償も、同じ精度で3つ並べます。
まず、取り決めが増えます。イベントの名前と中身は、決めた瞬間から守り続ける約束になります。次に、追いかける手間。1回の共有操作の痕跡が複数の置き場所にまたがるので、初めて読む人は「で、放送は誰が聞いてるの？」とファイルを行き来することになります。最後に、似た定義の重複。部品ごとに、よく似た型や設定を少しずつ持つ場面が出てきます。
どれも小さくない費用です。それでも今回の実装が分ける側に倒したのは、この部品が書き終えるものではなく、変わり続けるものだからです。共有先は増えるし、同意の作法も動く。変更が続く前提なら、変更のたびに払う確認の費用を下げる投資として、分ける費用は回収できると判断しました。
どこまで分けるか——分けすぎという失敗
とはいえ、細かく分けるほど良いわけではありません。分けるたびに先ほどの3つの代償が積まれるので、どこかで釣り合いが崩れます。私が線引きに使っている目安は、3つあります。
3つの目安のどれにも当てはまらないなら、その分割は先送りにします。境目は、引くこと自体が目的ではありません。迷ったときに私がやるのは、次に届きそうな変更依頼を1つ具体的に想像して、「その修正で、いま引こうとしている境目は役に立つか」と自問することです。想像の中でも役に立たない境目は、現実ではもっと役に立ちません。
考えてみる：「共有と保存はどちらもサーバーが関わるから、1つの責務では？」
関わる相手が同じでも、変更の理由が別なら責務は別です。共有はSNSの仕様というカレンダーで、保存は自分たちのデータ設計というカレンダーで変わります。逆に、変更の理由が同じなら、離れた場所にあるコードでも同じ責務の仲間です。置き場所の近さや使う道具の共通性ではなく、変更の理由で数える——これがこの記事でいちばん持ち帰ってほしい数え方です。
手を動かして確かめる
分け方が本当に効いているかは、感想ではなく差分で確かめられます。宿題：実際の変更を1つ選び、触ったファイルを置き場所ごとに数える。数えた結果は、このラベルからコメントに残せます。
合格条件はシンプルで、共有先を1つ増やしたとき、保存と計測の置き場所に差分がゼロであること。この実装では、置き場所の決まりが守られているかをアーキテクチャテストでも見張っています（実際の検査コード）。決まりは、書くだけでは守られません。破られたら赤くなる仕組みとセットにして、はじめて決まりとして生きてきます。
単一責任の原則の原典に当たりたい方は、Robert C. MartinによるThe Single Responsibility Principleが出発点です。原文でも、責務は「変更の理由」で定義されています。
まとめと、次回
第1回のまとめです。共有・保存・計測は、作業としては1つのボタン欄に見えても、変更の理由・変わる速さ・背負っている約束がすべて別物でした。だから責務を分け、連絡はイベントに限定し、そのぶんの取り決めの費用は「変わり続ける部品への投資」として引き受ける。これが今回の実装の答えです。そして、分ける・分けないの判断は原則の暗記ではなく、次に届く変更を具体的に想像することから始まります。
次は連載1.2「共有先が増えても触らないコードを決める」です。今回「共有の責務」とひとことで呼んだ箱を開けて、共有先を1つ追加するときに、どのファイルに差分が出て、どのファイルには出ないのか——今回の宿題の答え合わせを、実際のコードで行います。それでは、次回もお楽しみに！
連載の全体像は本編の連載目次へ。この回で扱った実装の裏付けは本編の記事と、下の関連リンクから確かめられます。
プロマリでは、Webサイトの制作に加えて、共有や計測のような「裏側のしくみ」の設計・導入、それらを運用できる人材の育成に取り組んでいます。自社サイトの部品設計を見直したい方は、お気軽にご相談ください。
記事で解説した責務の分け方を、実際のコードで確かめるための資料です。
この記事全体の感想・質問・設計へのコメント