YAGNI原則とは

どうも、畜産ペンギンです。

 

ペナントレースがヤバすぎて夜も眠れないなんて事は無いけど頭から離れないわ胃が痛いわのこの頃です。

 

今回は、YAGNI原則という物について語って行こうと思います。

目次は以下の通り。

 

目次

・YAGNI原則とは ・YAGNIをサボりの口実に使ってはいけない ・まとめ

 

YAGNI原則とは

YAGNI(You Ain’t Gonna Need It)原則とは、どうせ使わないよといった感じで、必要な機能だけを追加していきましょうという考え方です。

元々はエクストリームプログラミングにおいて提唱された考え方で、今現在具体的に使う訳ではないが将来必要になるかもしれないとか、あれば便利なんじゃないかといった思いで実装するのはやめましょうという感じみたいです。

 

日常に置き換えると、例えばこんな感じです。

訳すと、

 

「塩ください。」

「あのー？」

「分かってます！今どんな調味料でも渡せるシステムを開発中です。」

「もう20分も待ってるんですけど。。。」

「長期的には時間の節約になりますから。」

 

といった感じです。

間違いとは言えないかもしれませんが、とりあえず塩渡してやれよって思いますよね。

 

※↑はxkcdって漫画の「一般的な問題」というのを引用してます。他にも色々日常から仕事までのアンチパターンになりそうな事書いてあって面白いですよ。

 

開発業務においても、実際に今は機能コレしかないけど拡張性考えたらここ共通化しといた方が良くない？とか、

要件には無いけど、、、これあった方がよくない？とか、

ちょくちょく話はしてるなーて思い、実際使われてないで終わってるんじゃねってのもあったと思います。

 

前者は可読性が落ちたり、後者は余計なテストまでしなくてはならず工数の膨らみが大きくなりますね。

ので、必要無い事はやめましょうという感じですね。

 

YAGNIをサボりの口実に使ってはいけない

上のようにYAGNIを紹介すると、拡張性とか保守性とか無視してとにかく作っちまおうぜって捉えがちかもしれませんが、以下のような事が起きると後々自分が泣きを見るか、後続の開発者に呪われるでしょう。

 

・とあるサービスを提供する際に最初はプランが一つだけだったが、後々複数のプランに増えていった。

 

プランに関する処理を一つのクラスに処理をダダ書きしていったが、後々共通部を重複して書く事になったり、中身が違うだけで処理の流れは同じなのに関数の粒度や実装上では全然違う書き方になっているという事になった。

 

この場合、共通部や処理の流れを予め設計しておき、インターフェースや親クラスを準備しておくべきだったでしょう。

 

・金額をユーザーに入力させる箇所に対し要件が無いので入力チェックを行わなかったら、ユーザーが全角で金額を入力したが、そのまま別システムにIFされそちらでエラーが起こった。ユーザーとしては既に入力が完了しエラーには気づいていない。

 

ログ上にもエラーとしては”不正な値”としか出ておらずユーザーの入力値が何だったのかがわからないという事態になった。

 

中々お金関連でここまでズサンになる事は無いと思いますが、この場合当然入力チェックは必要でしょう。

 

こう書くと、結局何も省けないなって気にもなってきますが大事なのは本当に必要なのかを考える&確認すると言う所でしょうか。

プランが本当に一つにしかなりえないのであればわざわざ拡張性を気にする必要もないし(インターフェースは実装の数が問題では無いという考え方もありますが)

金額の入力も値を保持しユーザーに見せるだけ、また編集も容易だったらわざわざ入力チェックを入れる必要も無いかもしれません。

 

不要な事はするなというのは、何が不要なのかの見極めが重要といった感じでしょうか。

 

まとめ

まぁでも振り返ってみると、誰も好き好んで不要な事はしませんよねって話なのでわざわざ言われるまでも無い事かとも思いました。

ただ、何が必要で何が不要なのかあなたはわかってますか？と聞かれるとちょっと怖いなって感じです。

 

今回はここまでです。

 

さようなら。