共有・保存・計測は、なぜ同じ責務にしないのか

もし、ぜんぶ一緒に書いたら

分けた理由を語る前に、分けなかった世界を歩いてみます。共有も保存も計測も、1つの大きな置き場所に書いてしまう。最初の1週間は、これがいちばん速いんです。ファイルは1つ、行ったり来たりもない。正直に言うと、試作の段階では私もそう書いていました。

問題は、最初の変更依頼が届いた日に始まります。SNSの共有URLの決まりが変わった、というよくある知らせが届いたあとの道のりを追ってみましょう。

直したいのは共有の数行だけ。なのに、その数行は保存の処理と計測の処理のあいだに挟まっています。編集そのものより、「関係ない行を巻き込んでいないか」の確認に時間を取られる。この形の置き場所には神クラスという少し大げさな呼び名が付いています。呼び名の大げささのわりに、生まれる過程は地味で、「とりあえず近くに書いておこう」の積み重ねだけでこうなります。

変更の理由は、別のカレンダーでやってくる

それでは、3つの仕事の「変わる理由」をもう少し丁寧に見比べると、それぞれの変更を持ち込む相手が違います。

共有はSNS各社の都合で変わります。共有画面のURLの形式が変わる、サービスの名前そのものが変わる。どれも自分たちでは時期を選べません。保存はデータの都合です。二重登録を防ぐ決まりを強くしたい、保存先の形を見直したい。これは自分たちの計画で進みます。計測は法律と規約の都合で変わります。同意の取り方は法律やガイドラインの改定で、解析ツールの扱いは提供元の規約の改定で見直しが入ります。どちらも自分たちでは時期を選べない、また別のカレンダーです。

カレンダーが別ということは、変更が同時にやってこないということです。共有の修正日に保存のコードを開く必要はないし、同意の見直し日に共有URLを触る必要もない。同居させておく理由が、変更の側から見ると何もないのです。

直す場所と、確かめる範囲

分ける・分けないの差がいちばんはっきり出るのは、修正のあとに「どこまで確かめれば安心できるか」という範囲です。同じ修正を2つの構成に当ててみました。

分けない構成では、共有の修正でも保存と計測のコードが同じファイルの中にあります。ということは、手が滑って隣の行を消していないか、共有のつもりで共通の変数を書き換えていないか、3つ分の目視と3つ分の動作確認が要ります。うっかり別の機能を壊してしまう事故にはリグレッションという名前が付いているくらいで、これは珍しい失敗ではなく、混ぜて書いた構成の標準装備なんですね。

分けた構成なら、共有の置き場所だけを開き、共有の確認だけで閉じられます。修正の大きさは同じでも、安心を買い戻すための費用が違う。この費用は毎回の変更で払うので、積み重なると設計の差がそのまま速度の差になります。