YAGNI原則とは
YAGNIは「You Aren't Going to Need it」の略。
一言で言うと「機能は実際に必要となるまでは追加しないのがよい」という意味。
YAGNIの読み方
YAGNI(ヤグニ)だと思います。
※けど、ヤゲニでも通じるはず
理解の仕方に注意
この原則は色々なサイトで色々な訳され方がされています。
例えばこちら、「必要なものは必要になったときに書きなさい」
ちょっと解釈の仕方を間違えると、以下のような理解にたどり着く可能性があり注意です。
「必要なものは必要になったときに書きなさい」
= 「必要なものは必要になったときに考えなさい」
= 「未来のことはその時に考えなさい」
= 「未来のことは今考えなくていいよ」
え、未来のこと考えなくていいの....😯？！
本当にそうなのか？
YAGNIの本質は以下に羅列されています。
- きっと使う"だろう"という予測で作られた機能は、実際には10％程度しか使われない。
- 余分な機能があると、仕事に時間がかかり、リソースを浪費する。
- 余分な機能は設計を複雑化させ、予期しない変更が起こった時、より多くの変更コストを支払うことになる。
- 人生の時間は貴重である。ゆえに、コードを書くためではなく、現実の問題に集中するために費やすべきだ。
- コードをすばやく実装する最も良い方法は、余分なコードを書かないことだ。
- バグを減らすために最も良い方法も、余分なコードを書かないことだ。
使うかわからない余分な機能は、デメリットが多いので実装する必要は無いと説いています
未来のことを考えなくていいと言っているわけではありません。
結論
YAGNI原則はフレーズだけが1人歩きしてしまい、誤って理解してしまう可能性があります。
決して未来のことは考えなくていいというわけではありません🙅
確定している未来の事象や、現実化する可能性が非常に高い近未来のことは考慮して、ソフトウェアの構成要素（クラス、モジュール、関数）をコーディング・設計するべきです。
そうすれば、後々容易に追加や拡張をすることができるはずです。
参照