Premature Optimizationは、早すぎる最適化という意味です。
速くすること自体は大切ですが、まだ問題になっていない箇所を先回りして複雑にすると、保守しにくいコードになります。
一言でいうと
早すぎる最適化とは、計測せずに「速そう」なコードへ複雑化してしまうことです。
最適化は、問題が見えてから、測定して、効果がある場所に行います。
悪い例
function isAllowedRole(role: string) {
return role.charCodeAt(0) === 97 && role === "admin";
}
少しでも速くしようとして、読みづらい条件を追加しています。多くの場合、この程度の差は実用上問題になりません。
読みやすい例
function isAllowedRole(role: string) {
return role === "admin";
}
意図が明確です。実際にここが遅いと分かってから最適化を考えれば十分です。
早すぎる最適化の問題
| 問題 | 説明 |
|---|---|
| 読みにくい | 意図よりテクニックが目立つ |
| バグが増える | 複雑な実装ほど間違えやすい |
| 効果が薄い | 本当のボトルネックではない |
| 変更しにくい | 最適化前提の構造になる |
| テストが難しい | 細かい挙動に依存する |
高速化したつもりでも、実際にはDB、ネットワーク、画像、外部APIのほうが遅いことがよくあります。
最適化の順番
- まず正しく動かす
- 読みやすく保つ
- 遅いと感じたら計測する
- ボトルネックを特定する
- 小さく最適化する
- もう一度計測する
最適化は「勘」ではなく「計測」から始めます。
最適化してよい場面
- 実際にユーザー体験へ影響している
- ログや計測で遅い箇所が分かっている
- 処理回数が非常に多い
- コストが大きい外部I/Oを減らせる
- 可読性を大きく犠牲にしない
このような場合は、最適化に価値があります。
学習時の考え方
初学者は、まず分かりやすく正しいコードを優先します。アルゴリズムの基本や計算量は重要ですが、日常のWebアプリでは、読みやすさと正しさが先です。
速度の話をするなら、実行時間を測る習慣を付けます。
まとめ
早すぎる最適化は、まだ問題になっていない箇所を複雑にしてしまうことです。
まず正しく読みやすく書き、遅いと分かったら計測してから最適化しましょう。