共通化とは、閉じていたものを開くことだった

カードを追加するフォームと、編集するフォームを作りました。
最初はコピーして別々に作って、両方が動いてから1つにまとめました。
まとめてみたら、共通化という言葉の意味が自分の中で変わったので書いておきます。

最初から共通化しなかった

コピーで始めたのは、手を抜いたからではなくて、前日の実測が根拠でした。

同じ制作の中で、工程を4つの段階に割って進めたときは見積の 0.8倍で終わり、
割らずに進めたときは 4.8倍かかっていました。
未知の数を1つずつにすると速い、というのが手元の数字で出ていたので、
「動かす」と「まとめる」を分けることにしました。

編集フォームを作る時点で、未知は4つありました。
そこに共通化を足すと5つ目になります。動いてからまとめる、で進めました。

違いは2つしかなかった

動いた状態で2つのファイルを並べたら、違いは2つだけでした。

この2つを、外から渡す形に変えたら1ファイルになりました。
それだけでした。

フォームは「自分が何をするか」を知りません。渡された処理を呼ぶだけになります。
それが、まとめられた理由でした。
逆にいうと、この2つ以外は最初から同じものを2回書いていたことになります。

コミットは5ファイルで、追加が28行、削除が72行。
44行減りました。

まとめたら、閉じていた型を外に出すことになった

まとめた直後に、1つ作業が増えました。
片方のファイルの中に閉じていた型を、export して外から参照できるようにする必要が出たんです。
共通化したフォームに渡す値の型なので、別のファイルから要るようになりました。

最初、これを「まとめた代償」だと思いました。
公開する範囲が広がるのは、普通は避けたいことなので。
負けた気がしました。

でも書き終えてから、逆だと気づきました。
2つの場所から使われるものになった、というそのことが共通化の中身です。
型が1ファイルに閉じていられなくなるのは、代償というより定義のほうでした。

共通化とは、閉じていたものを外へ開くこと。
そう捉えると、「どこまで開くか」を決めるのが設計なんだと思えました。

同じ日に、まとめなかったものもある

ただ、共通化を礼賛したいわけではありません。同じ日に逆の判断もしています。

編集ページには、データベースの値をフォーム用に直す変換が3つありました。
形も似ているので、関数にまとめられます。まとめませんでした。
使う場所が編集ページの1つしかないからです。

「まとめられる」と「まとめるべき」は違う。
2箇所目が出たときが、関数にするときだと決めました。

フォームのほうは、追加と編集という2箇所が実際にありました。
変換のほうは1箇所しかありません。
同じ日に片方をまとめて、片方をまとめなかったのは、その差でした。
数の差です。