概要
原著者の許諾を得て翻訳・公開いたします。
- 英語記事: Practicing YAGNI
- 原文公開日: 2018/01/17
- 著者: Jason McCreary
画像は英語記事からの引用です。
YAGNIを実践する（翻訳）
しばらく前に私はLaraconでYAGNIの実践についてスピーチしました。このような大きなカンファレンスで大勢の観衆を前にプレゼンしたのは名誉なことでした。以来、私のスピーチに多くの反応や関心が寄せられています。
私のスライドを共有したいという申し出を多くの方からいただきましたが、ほとんどの議論がスライドに対して行われたので、ブログ記事にまとめる方がよいと思えました。スライドをご覧になりたい方は、StreamAConで私のスピーチを視聴できます。
私は自分自身を「探求者」だと思っています。プログラミングの秘訣における聖杯、それさえ手に入れれば即座にスキルアップできるたったひとつの聖杯の探求です。そのような唯一無二の聖杯などありえないことは自分でも認識していますが、いくつかの秘訣なら存在すると信じています。そのひとつがYAGNIです。
YAGNIはエクストリームプログラミング（XP）の法則の1つです（私は日頃からXPを実践しています）。YAGNIは「You Aren't Gonna Need It（今必要でないことはやるべきでない）」の略語であり、プログラマーは本当に必要になるまでは機能を追加すべきではないと戒めています。理屈では簡単ですが、実践できているプログラマーはほとんどいません。
YAGNIの実践が困難な理由
YAGNIの話を続ける前に、YAGNIがどんな問題を解決するのかについて理解しておく必要があります。その問題とは「オーバーエンジニアリング（over engineering）」です。エンジニアはある時期、複雑であることにプライドを感じるようになるものです。寸分違わずピタリと合うデザインパターンを徹底的に追求したり、もっともっと複雑なアーキテクチャをあれこれ構想したりすることに取り憑かれてしまいます。
XKCDの漫画「一般的な問題」は、このオーバーエンジニアリングの問題を表しています。
この漫画が面白いのは、やってることは間違いではないからです。「とりあえず塩を渡してやればいいのに」と思わずにはいられませんが。
KISSの原則（Keep it simple, stupid）ではどんなことが起きたでしょうか？MVP（Minimum viable product）はどこがまずかったのでしょうか？その答えは「間違ってはいない」、ただそれだけです。私たちにはシンプルさに立ち戻るための方法が必要であり、それを助けてくれるのがYAGNIです。
YAGNIを実践する方法
YAGNIの実践方法をうまく説明しているのは、エクストリームプログラミングの共同提唱者であるRon Jeffriesの次の言葉だと思います。
実装は、それが本当に必要になるまでは行わないこと。「今後必要になる」という予見を理由に実装してはならない。
にもかかわらず、議論が最も白熱するのは「それはいつなのか？」という点です。実際に必要になるよりも前の段階でコードを書き続けるのはオーバーエンジニアリングであり、「予見」と「必要」を混同しています。
この2つを明確に区別するために、将来期間（time horizon）を設けるという方法があります。Kent Beckは、Full Stack Radioでのインタビューでうまい説明を与えています。
ちょっとした実験を行ってみたんです。設計上の将来期間を「6か月」に限定して、そこから先のことを予見しないようにしたらどうなるかと思って。これは自分にとってうまくいったと思います。オーバーエンジニアリングも減りましたし、進捗もはかどりました。心配の種も減りましたし、いろんなことがクリーンになって理解しやすくなりました。将来期間を「3か月」や「1か月」に変えたらどうなったと思います？実験中に期間の上限に達したことはついに一度もありませんでしたね。
このようにして、YAGNIの実践は「将来期間を実験で確かめる」という具体的な作業になります。将来期間を繰り返し短縮することで、私たちがコードを書きすぎないよう制限しやすくなります。理想的には、コードが実際に必要になるまではコードを書かないようになるまで、期間の短縮を繰り返します。これは、私たちがYAGNIの実践について考えているとか、YAGNIを実践したいとか、現在作業中のコードに関連しているからというだけが理由ではありません。私たちは、現在のコードが機能するうえで新しいコードの実装が真に必要になるまで待つのです。
これは私も認めざるを得ませんが、最初のうちはきっと面倒くさい気持ちになるでしょう。コードを書くことを意図的に避けろと命令されたような気持ちになるでしょう。ある意味それは本当です。ここで重要なのは、コードを書きたいと思ったタイミングは、コードを書いてもよいタイミングではないという点です。仮説を立てることで発生する可能性のあるあらゆる問題を、待つことによって防ぐのです。
YAGNIを実践すべきでないとき
YAGNIのメリットに気がついた人は、きっとあらゆる局面でYAGNIを実践しようとするでしょう（他のプログラマーに呪われるかもしれません）。「大いなる力には大いなる責任が伴う」ことを忘れてはいけません。YAGNIは「ノーと言う」ための方法ではなく、不要な複雑さを時が満ちるまで先延ばしにするためのものです。
そして、YAGNIを実践すべきでないときもあります。残念ながら、これを見極めるには経験が必要です。そこで、YAGNIの実践を開始するうえで役に立つシナリオをいくつかご紹介します。
- 新しいことを学ぶとき: 新しい技術を評価するときは時間を惜しんではいけません。その時間はきっと後で報われます。そして、誤った技術を選択して時間を無駄にするリスクを緩和できます。
- 将来の必要性に基いて現在の設計を決定するとき: YAGNIを仕事の妨げや怠けの言い訳に使うべきではありません。こういうときは、将来問題を起こさない設計を選び、ただし実装は現在の必要を満たすだけにとどめましょう。こうすることで、YAGNIを損なうことなく手戻りを減らせます。
- 外部依存性を抽象化するとき: 外部への依存が追加されると、プロジェクトがその分複雑になります。これまでの例と同様、十分時間をかけてこうした依存性を抽象化することで手戻りを回避し、複雑さを低下させることができます。
- テスト、セキュリティ、スケールアップ、ビジネス上の要求: 残念ながらYAGNIは、テストの作成やセキュアなコードの作成、スケールやビジネス上の要求を却下するフリーパスではありません。
私にとってYAGNIとは何か
私はYAGNIを実践することで自信を得られます。設計上の決定を行うのにふさわしいタイミングは（現在ではなく）未来なので、安心して設計上の決定を先延ばしにできます。コードがシンプルに保たれているので自信を持って方針を転換できますし、コードのリファクタリングや進化も容易になります。私はコード量を少なくすることを心がけています。率直に言えば「コードがない」のがベストのコードなのです。
詳しく知りたい方へ: Twitterで@gonedarkのフォローをお願いします。コーディングの便利なヒントや、さまざまなリソースを参照するリツィートなど、盛りだくさんの情報をお届けいたします。