ページタイトルの表示が崩れていたので、直すことにしました。
対象は1ページでしたが、作業を進めていくうちに「どうせなら固定ページ全体のヒーロー表示を共通化しよう」という判断になりました。
コードとしてはきれいな方向性です。同じ構造をまとめて管理できるようになるので、今後の修正効率も上がるはず。そう思っていました。
ところが、共通化が終わった後に本当の作業が始まりました。
「きれいに終わった」と思っていたのに、確認コストがそのあとから一気に出てきたのです…！
この記事のまとめ
- 共通化は再発防止になるが、既存ページが多いほど確認コストが重くなる
- 「同じ見た目だからまとめる」ではなく「何度も同じ修正が入るか」で判断する
- 保守性はコードの整理だけでなく、検証体制込みで考える必要がある
1ページ直すつもりが共通化に進んだ
きっかけはシンプルでした。
ブログ固定ページのヒーローエリア（ページ最上部の大きなビジュアルと見出しが入るセクションのことです）でタイトル表示が崩れていたので直したかっただけです。
ただ、対象ページを直しながら気づきました。
似たような構造のページが他にもあるし、そのたびに同じ修正を入れるより共通のテンプレートにまとめたほうが、長い目で見ると管理しやすいよな…？
そう判断して、局所修正ではなく共通化の方向に進みました。
判断としては間違っていなかったと思います。が、その先に想定外の出来事が待ち受けていたのです。
共通化が終わった後に待っていた確認タイム
共通テンプレートを作って既存ページに当てはめると、実装としては完成です。
ただ共通化したということは、影響するページが増えたということでもあります。
「全ページで正しく表示されているか」を確認しないと、共通化が原因で別の崩れが起きていても気づけません。
実際に確認を進めてみると、ページによって細かい差分が出てきました。
・見出しの長さが違うページでは折り返しが変わる
・画像の縦横比が違うページでは余白のバランスが崩れる
・同じテンプレートを当てても、既存ページそれぞれの事情が出てくる
「共通化したら終わり」ではなく、「共通化してから全ページ確認するまでが作業」だと、このとき初めてはっきり見えました。
共通化のコストを甘く見ていた
振り返ってみると、失敗の構造はシンプルでした。
共通化すればきれいに終わる、という見積もりが甘かったです。
既存ページの数が多いほど、確認にかかる時間は増えます。
ページごとに微妙な差分があるほど、個別対応が必要な箇所が出てきます。
これは共通化を選んだ時点で決まっていたコストで、やってみるまで実感しにくかっただけです。
コードとしての「きれいさ」と、作業としての「コスト」は別の話でした。
きれいな構造が正しい判断とは限らない。そのことを、今回は身をもって確認しました。
「共通化すべきか」の判断基準
この経験から、共通化を判断するときに確認するようになったことがあります。
■同じ修正がこれから何度も入るか
もし今回だけの修正なら、局所対応のほうが軽い場合が多いです。
今後も同じ箇所を繰り返し直すことが見えているなら、共通化のコストをかける意味があります。
■既存ページに差分はどれくらいあるか
ページ数が多く、それぞれの差分が大きいほど、共通化後の確認コストは上がります。
ページ数が少なく差分も小さいなら、共通化のメリットが出やすいです。
■確認できる体制があるか
共通化はコードの問題ではなく、検証体制の問題でもあります。
実装が終わってから全ページを確認できる時間と手順がないと、問題が埋もれやすくなります。
この3点を先に整理しておくだけで、「共通化か局所対応か」の判断がだいぶしやすくなりました。
保守性はコードだけでは決まらない
共通化は、再発防止と今後の修正効率を上げるための手段です。
うまく機能すれば、同じ箇所を繰り返し直す手間がなくなります。
一方で、既存ページが多いほど初回の確認コストが重くなり、想定外の差分が見つかりやすくなるというデメリットもあります。
大事なのは、保守性をコードの整理だけで考えないことです。
きれいな構造が作れても、その後の確認体制が整っていなければ、問題は別の形で出てきます。
コードとしての正しさと、実際の作業コストを一緒に見ることが、保守性を上げる近道だと感じました。
おかげで今回も、とても良い勉強ができました…！！
