YAGNI原則とは？ざっくりと3行で
- You Aren’t Gonna Need It（それ、きっと要らなくなるよ）の略で、「今必要な機能だけを作れ」という教訓のことだよ。
- 「将来使うかもしれないから」という予想でコードを書くと、大抵は予想が外れて無駄なゴミコードになるからやめよう、という考え方なんだ。
- これを守ることで、プログラムがシンプルになり、バグが減り、開発スピードが圧倒的に速くなるね。
【深掘り】これだけ知ってればOK！
YAGNI（ヤグニ）は、エクストリーム・プログラミング（XP）という開発手法における重要なプラクティスの一つです。優秀なエンジニアほど、「あとで拡張しやすいように汎用的に作っておこう」と考えがちですが（オーバーエンジニアリング）、仕様変更が激しい現代において、その「あとで」が来る確率は高くありません。未使用の機能は、テストの手間を増やし、コードを読みづらくする「技術的負債」にしかならないのです。
会話での使われ方
将来的にPDF出力も必要になるかもしれない？いや、それはYAGNIでいこう。まずはCSV出力だけで十分だ。
このクラス設計、汎用性を考えすぎて複雑になってない？ YAGNI原則に従ってもっとシンプルにしよう。
お客様の要望が変わったけど、YAGNIで作っていたおかげで修正が最小限で済みました。
【まとめ】3つのポイント
- 予知能力はない：未来のことは誰にもわからないので、今の推測でコードを書かない
- 今に集中：現在、確実に必要とされている機能（価値）を最速で届けることに注力する
- 維持コストの削減：書かないコードにはバグは存在しない。コード量は少ないほど正義
よくある質問
- QYAGNI原則とKISSの原則（Keep It Simple, Stupid）の違いは？
- AYAGNIは「機能の範囲（何を作るか）」の話で、KISSは「設計の単純さ（どう作るか）」の話です。「要らない機能は作るな」がYAGNI、「作るなら単純に作れ」がKISSです。
- QYAGNI原則は「拡張性を考慮しなくていい」という意味ですか？
- A違います。「拡張しやすいきれいな設計」にはすべきですが、「まだ使わない拡張機能そのもの」を実装してはいけない、という意味です。変更に強いシンプルなコードを保つことが重要です。
- QいつYAGNI原則を適用すべきですか？
- Aアジャイル開発のように「仕様変更が頻繁に起こるプロジェクト」で特に有効です。逆に、一度決めた仕様が絶対に変更されない（ウォーターフォール型の）厳格なプロジェクトでは、初期設計が全てなので注意が必要です。
- QYAGNIの反対語はありますか？
- A特定の用語はありませんが、「オーバーエンジニアリング（過剰設計）」や「フューチャークリープ（機能の肥大化）」などが対義的な状況を表します。
コメント