さて、今回はちょっと雑学です。
IT畑で生きている人はチラッと聞いたことがある人もいるかもしれませんが...
YAGNIの法則について僕が思っていることを書いてみます。
YAGNIの法則とは...?
YAGNIの法則はヤグニの法則と呼ばれることが多いですね。
これ、英語の省略系で、 もともとは"You Are not Gonna Need It"です。
つまり、"あなたにとってそれは必要にならないだろう"といったニュアンスです。
現時点では不必要なコード(だけど、あったら将来そうなった時に嬉しいコード)を書くかどうか悩んだ場合、それは追加しなくていい。
というものです。
例えば、文字列を表示したい場合に、エスケープ処理をすべきかどうか悩んだとします。
ただ、現時点ではエスケープ処理がなくてもうまく動いています。
将来的にもしかしたらエスケープ処理が必要な場面がくるかもしれません...
そんな場合は現状維持で、必要になった時に実装しなさい。
という教え的なものですね。
背景
コードは必要最低限だけ実装し、複雑にしないこと。
という考えが前提にあります。
現時点でプロダクトがうまく動いているのに、将来のことを考えて機能を追加しても、複雑になってメンテナンスコストは上がるが、実際の利益はゼロです。
やはり、実際に使われていないコードがたくさんあるようなプロジェクトはいやですよね...
また、実際に予測で作成されたコードが実際に使われる確率は極めて低いと言われています(明確なソースは見当たりませんでしたが...)。
そこらへんは肌感とかが多いのかな...?
実際にコード書いていると、あ、せっかくステータスAの取得関数作ったし、形もほとんど同じだからステータスBのもついでに作っとくか〜。
とか思ったりしませんか？
そんな時はこれを思い出すといいかもしれません。
注意点
なんとなくそんなもんなんだなっていうのはお分かりいただけたと思います。
しかし、こういった教えを盲信するのは危険です。
例えば...
すごい極端な例ですが、ログインの時にユーザーが変な値を入れるかもしれないから、バリデーションを追加しよう。
という場合...
現時点ではもしかしたら変な値を入れらていなかったため、動作的には大丈夫かもしれません。
しかし、実際に発生してから必要になったから実装しよう！
では遅いですよね...
そういった、高いリスクが見込める場合には、十分対策としてやっておくべきだと思います。
場合によってはそれを"必要最低限"に含めてのYAGNIだ！という方もいるかもしれませんが...
現時点で存在せずともうまく行く機能と定義した場合、盲信は危険です。
なので、僕の場合、先に述べたついでの関数実装等の軽い内容で悩んだ時は思い出し、必要になるのが自明である内容(ほとんどないと思いますが...100%ではなくても、比較的高確率で必要になると思われるもの等)に対しては場合によりけりって感じで考えています。
まとめ
YAGNIの法則についてみてみました。
こういったものは白黒はっきりしていないことが多く、派閥争いもあったりします...w
いや、俺は必要ないと思う！
いやいや必要だ！とか。
ただ、大切なことは一度考えてみること。
そして自分含めプロジェクトメンバーで納得した形で実装をしていくことだと思っています。
その考えてみるきっかけになるので、是非覚えて帰ってください！
そして、自分が実装した時、レビューでみた時、これってYAGNI的にどうでしょう？あったほうがいいですかね？まだいらないですかね？
と質問を投げかけてみて、話し合った上でよりよいほうを選べばいいと思っています。