両方欲しくなるのが自然
設計を考え始めると、
必ず出てくる欲張りな願いがあります。
- 壊れにくくしたい
- でも、変更には柔軟に対応したい
どちらも正しい要求です。
ただし、同時に最大化することはできません。
壊れにくさを優先しすぎた結果
壊れにくさを重視しすぎると、
次のような状態になりがちです。
- 条件分岐が多すぎる
- 抽象化が深すぎる
- 触る場所が分からない
結果として、
「安全だけど動かしにくい」コードになります。
柔軟さを優先しすぎた結果
逆に、柔軟さを優先しすぎると、
- 何でも受け取れる関数
- 想定外でも動く処理
- ルールのない拡張
が増えていきます。
一時的には便利ですが、
時間が経つほど壊れやすくなります。
トレードオフを意識する
重要なのは、
どちらかを選ぶことではありません。
- 今はどちらを優先すべきか
- このコードはどこまで変わるか
状況ごとに重みを変える ことが設計です。
判断の目安
迷ったときの目安があります。
- コア処理 → 壊れにくさ優先
- 周辺処理 → 柔軟さを許容
- 境界部分 → 明示的に制限
すべてを同じ基準で作らないことが、
結果的に全体を安定させます。
作って分かったこと
このテーマを通して分かったのは、
- トレードオフは避けられない
- 迷った形跡を残すと後で助かる
- 判断を固定しないことが大事
ということです。
おわりに
この話は、
壊れにくさと柔軟さの間で
どう判断するかを整理した記録です。
次は、
設計編のまとめとして、
「実務で設計が必要になる瞬間」を扱います。
コメント