AHAは、Avoid Hasty Abstractions の略です。
日本語では「急いだ抽象化を避ける」と考えると分かりやすいです。
一言でいうと
AHA原則は、まだ変化の方向が見えていないコードを急いで共通化しないための考え方です。
DRYを意識しすぎると、似ているコードをすぐ1つにまとめたくなります。しかし、早すぎる抽象化はあとから壊しにくい構造を作ります。
抽象化とは何か
抽象化とは、複数の具体的な処理から共通部分を取り出し、名前を付けて扱えるようにすることです。
function calculateDiscountPrice(price: number, rate: number) {
return price - price * rate;
}
割引計算という意味を関数に閉じ込めています。これはよい抽象化になり得ます。
ただし、どの割引にも同じ計算式が使えるとは限りません。会員割引、クーポン、期間限定セールは、将来別々のルールになるかもしれません。
AHAが必要な理由
早すぎる抽象化は、次の問題を生みます。
| 問題 | 説明 |
|---|---|
| 引数が増える | 利用元ごとの差を吸収しようとする |
| 分岐が増える | 共通関数内でケースを判定し始める |
| 名前が曖昧になる | processData のような意味の薄い名前になる |
| 直しにくい | 1箇所の変更が全利用元へ影響する |
抽象化は強力ですが、間違えるとコード全体を縛ります。
AHAとDRYの関係
DRYは、同じ知識を重複させない考え方です。AHAは、共通化する前に「本当に同じ知識か」を待って見極める考え方です。
| 原則 | 役割 |
|---|---|
| DRY | 同じ知識の重複を減らす |
| AHA | 急いで間違った共通化をしない |
この2つは対立ではありません。DRYを正しく使うために、AHAが役立ちます。
実務での判断
次の状態なら、まだ抽象化を待ってもよいです。
- 似たコードが2箇所だけ
- 仕様がまだ固まっていない
- 名前が自然に決まらない
- 共通化するとオプション引数が増える
- 片方だけ変わる可能性がある
逆に、同じ変更を3回以上繰り返しているなら、抽象化を検討します。
よくある誤解
重複はすぐ消すべき
すべての重複が悪いわけではありません。少しの重複は、変化を見るための余白になります。
抽象化は高度だから良い
難しい抽象化ほど良いわけではありません。読み手が意図を理解できる抽象化だけが役に立ちます。
汎用的な部品ほど価値が高い
汎用的すぎる部品は、何のための部品か分かりにくくなります。まずは具体的な名前を優先します。
まとめ
AHA原則は、急いで抽象化しないための考え方です。
似ているコードを見つけても、すぐ共通化せず、同じ変更理由が見えるまで待つ判断が大切です。
参考リソース
関連記事
← 一覧に戻るPR
PR
