はじめに
記録時点: 2024-04〜2024-05
この時期は、機能を増やす前にフロントの作法を揃える判断を取りました。 初期にここを曖昧にすると、画面が増えたあとで統一コストが跳ね上がるためです。
当時の状態
立ち上げ直後は、画面ごとに実装の癖が分かれていました。 短期的には進んで見えますが、次の問題がすぐ出ます。
- 同じ入力系UIでも挙動が違う
- 小さな仕様変更で複数画面を同時修正する必要がある
- レビューで見る観点が担当者ごとに変わる
先に決めたこと
1. 開発サイクルを落とさない構成に固定する
起動とビルドの待ちを減らすことを最優先にしました。 初期開発は試行回数そのものが品質に直結するためです。
2. UI部品を早期に共通化する
見た目だけでなく、入力と検証の挙動まで揃える前提で部品化しました。 これで、画面追加時の差分がかなり小さくなります。
3. 画面統合前に崩れを拾える環境を用意する
コンポーネント単位で確認できる場を先に作り、画面で発見する不具合を減らしました。
判断の分岐で悩んだ点
全部を最初から厳密に統一するか
初期に厳密すぎるルールを入れると、実装速度が落ちます。 当時は、守るべき最小限だけ固定し、拡張しながらルールを育てる方針を取りました。
共通化をどこまで進めるか
共通化しすぎると、逆に変更しづらい層が増えます。 利用頻度の高い部品から順に共通化して、重心を間違えないようにしました。
基盤整備の効果が出た場面
- 新規画面の立ち上げが速くなる
- 仕様変更時に直す場所が読みやすくなる
- 画面統合時の手戻りが減る
どれも派手な成果ではありませんが、継続開発ではここが効きます。
まとめ
この時期に作ったのは、初期セットアップではなく開発の共通言語でした。 先に土台を揃えたことで、後続の編集機能を速度を落とさず進められています。