テクニカルYAGNI原則とはどうも、畜産ペンギンです。ペナントレースがヤバすぎて夜も眠れないなんて事は無いけど頭から離れないわ胃が痛いわのこの頃です。今回は、YAGNI原則という物について語って行こうと思います。It)原則とは、どうせ使わないよといった感じで、必要な機能だけを追加していきましょうという考え方です。元々はエクストリームプログラミングにおいて提唱された考え方で、今現在具体的に使う訳ではないが将来必要になるかもしれないとか、あれば便利なんじゃないかといった思いで実装するのはやめましょうという感じみたいです。日常に置き換えると、例えばこんな感じです。「分かってます!今どんな調味料でも渡せるシステムを開発中です。「もう20分も待ってるんですけど。「長期的には時間の節約になりますから。間違いとは言えないかもしれませんが、とりあえず塩渡してやれよって思いますよね。※↑はxkcdって漫画の「一般的な問題」というのを引用してます。他にも色々日常から仕事までのアンチパターンになりそうな事書いてあって面白いですよ。要件には無いけど、、、これあった方がよくない?とか、ちょくちょく話はしてるなーて思い、実際使われてないで終わってるんじゃねってのもあったと思います。前者は可読性が落ちたり、後者は余計なテストまでしなくてはならず工数の膨らみが大きくなりますね。必要無い事はやめましょうという感じですね。YAGNIをサボりの口実に使ってはいけない上のようにYAGNIを紹介すると、拡張性とか保守性とか無視してとにかく作っちまおうぜって捉えがちかもしれませんが、以下のような事が起きると後々自分が泣きを見るか、後続の開発者に呪われるでしょう。・とあるサービスを提供する際に最初はプランが一つだけだったが、後々複数のプランに増えていった。プランに関する処理を一つのクラスに処理をダダ書きしていったが、後々共通部を重複して書く事になったり、中身が違うだけで処理の流れは同じなのに関数の粒度や実装上では全然違う書き方になっているという事になった。この場合、共通部や処理の流れを予め設計しておき、インターフェースや親クラスを準備しておくべきだったでしょう。・金額をユーザーに入力させる箇所に対し要件が無いので入力チェックを行わなかったら、ユーザーが全角で金額を入力したが、そのまま別システムにIFされそちらでエラーが起こった。ユーザーとしては既に入力が完了しエラーには気づいていない。ログ上にもエラーとしては”不正な値”としか出ておらずユーザーの入力値が何だったのかがわからないという事態になった。お金関連でここまでズサンになる事は無いと思いますが、この場合当然入力チェックは必要でしょう。書くと、結局何も省けないなって気にもなってきますが大事なのは本当に必要なのかを考える&確認すると言う所でしょうか。プランが本当に一つにしかなりえないのであればわざわざ拡張性を気にする必要もないし(インターフェースは実装の数が問題では無いという考え方もありますが)金額の入力も値を保持しユーザーに見せるだけ、また編集も容易だったらわざわざ入力チェックを入れる必要も無いかもしれません。不要な事はするなというのは、何が不要なのかの見極めが重要といった感じでしょうか。まとめまぁでも振り返ってみると、誰も好き好んで不要な事はしませんよねって話なのでわざわざ言われるまでも無い事かとも思いました。何が必要で何が不要なのかあなたはわかってますか?と聞かれるとちょっと怖いなって感じです。