YAGNIは、You Aren’t Gonna Need It の略です。
日本語では「それはたぶん必要にならない」と考えると分かりやすいです。
一言でいうと
YAGNIは、今必要ではない機能や拡張ポイントを先回りして作らないための原則です。
「あとで使うかも」と思って作ったコードは、実際には使われないことがよくあります。
なぜ先回り実装が危ないのか
先回り実装は、親切に見えます。しかし、未使用コードは読む人に負担をかけます。
| 先回り実装 | 問題 |
|---|---|
| 使っていないオプション引数 | どの設定が必要か分からない |
| 未使用の抽象クラス | なぜ存在するのか分からない |
| 将来用の分岐 | テストされず壊れやすい |
| 予定だけの設定項目 | 実装済みと誤解される |
コードは書いた瞬間から保守対象になります。使わないコードにも、読み手の理解コストがかかります。
悪い例
type PaymentMethod = "card" | "bank" | "crypto";
function pay(amount: number, method: PaymentMethod) {
if (method === "card") {
return payByCard(amount);
}
if (method === "bank") {
throw new Error("not implemented");
}
if (method === "crypto") {
throw new Error("not implemented");
}
}
今カード決済しか使わないなら、銀行振込や暗号資産の分岐は不要です。未実装分岐があると、読み手は「対応予定なのか」「使ってよいのか」で迷います。
よい例
function payByCard(amount: number) {
return cardGateway.charge(amount);
}
必要なものだけがあります。別の決済方法が必要になったときに、実際の要件を見て拡張します。
YAGNIを使う判断
- 今の画面や機能で使うか
- テストできる要件があるか
- 使う予定が日付やチケットで決まっているか
- 作らないことで困る人がいるか
- あとから追加するコストが本当に高いか
「いつか使うかも」だけなら、作らない判断が安全です。
ただし設計を雑にする意味ではない
YAGNIは、何も考えずに書くという意味ではありません。今必要な範囲で、変更しやすく書くことは大切です。
たとえば、関数名を分かりやすくする、入力チェックを書く、テストを書くことはYAGNIに反しません。むしろ今必要な品質です。
まとめ
YAGNI原則は、今必要ではない機能を先回りして作らないための考え方です。
未使用コードは無料ではありません。読む、直す、テストするコストが発生します。
参考リソース
関連記事
← 一覧に戻るPR
PR
