カテゴリ: 原則
種類: ソフトウェア開発の原則
起源: エクストリームプログラミング、1999年 / リファクタリング、1999年
別名: YAGNI、You Aren’t Gonna Need It、You Aren’t Going to Need It
種類: ソフトウェア開発の原則
起源: エクストリームプログラミング、1999年 / リファクタリング、1999年
別名: YAGNI、You Aren’t Gonna Need It、You Aren’t Going to Need It
クイックアンサー — YAGNIの原則（You Aren’t Gonna Need
It）は、実際に必要になるまで機能を追加しないようプログラマーに助言するソフトウェア開発のガイドラインです。1990年代後半にエクストリームプログラミング（XP）の実践者によって普及したYAGNIは、「万一に備えて」精巧なシステムを構築するという一般的な傾向に対抗する役割を果たします。この原則は、時期尚早な一般化は複雑さを増し、開発時間を消費し、実際の要件が予測と異なる場合、多くの場合無駄な努力に終わると論じています。
YAGNIの原則とは
YAGNIの原則は、現在のコードベースやユーザーベースによって実証的に必要とされるまで、機能や機能性の実装を控えるよう助言する設計ガイドラインです。頭字語YAGNIは「You Aren’t Gonna Need It」（時には「You Aren’t Going to Need It」）を表し、「仮定の将来のシナリオに対する柔軟性を構築する誘惑に抵抗せよ」という原則の核心メッセージを捉えています。「実際に必要になったときに常に実装せよ。必要になると予測したときには決して実装するな。」— ケント・ベック『Extreme Programming Explained』この原則は、単純さ、フィードバック、勇気をコアバリューとして強調したエクストリームプログラミング（XP）メソドロギーから生まれました。XPの実践者は、開発者が様々な将来のシナリオを予測した「柔軟な」システムの構築にかなりの時間を費やすことが多く、そのシナリオの多くは決して実現しないことを観察しました。将来の要件が実際に到来した場合、それらは予測とは十分に異なることが多く、準備作業は無駄になってしまうのです。 YAGNIは「技術的負債」の概念と密接につながっています。必要になる前に書かれたすべてのコード行は、保守、理解、デバッグが必要な負債です。実際の要件が明確になったとき、時期尚早な抽象化はきれいにフィットしないかもしれず、必要な機能を直接実装するよりも多くの時間がかかるリファクタリングが必要になります。YAGNIはより単純な道を主張しています。今必要なものを実装し、要件が明確になったときにリファクタリングするのです。
YAGNIの原則を3つの深さで理解する
- ビギナー: 「将来proofing」コードを追加したくなったとき、立ち止まって自問してください。「これは実際に使うのか、それとも推測しているだけなのか？」推測なら、スキップしてください。必要が証明されたときにいつでも追加できます。
- プラクティショナー: テスト駆動開発を使って、実際の要件を引き出してください。すべての可能なユースケースを事前に想像するのではなく、テストから本当に必要な機能性を明らかにさせてください。
- アドバンスド: YAGNIと、コードのリファクタリングが必要な「兆候」に注意を払うことのバランスを取ってください。必要が差し迫っていて準備が正当化されることもありますが、 genuine なシグナルと投機的な予測を区別してください。
起源
YAGNIの原則は、1990年代後半に革命的なソフトウェア開発アプローチとして登場したエクストリームプログラミング（XP）メソドロギーの中で明確に述べられました。この用語を作り出し、XP運動を率いたケント・ベックは、YAGNIを従来のソフトウェア開発メソドロギーとXPを区別するコアプラクティスの一つとして説明しました。 この原則は、マーティン・ファウラーの影響力のある書籍『リファクタリング』（1999年）で顕著に取り上げられ、YAGNIがリファクタリングプロセスとどのように関連するかが議論されました。ファウラーは、必要が差し迫っている場合はリファクタリングによる柔軟性の追加は適切だが、時期尚早な一般化は不必要に複雑なコードにつながると論じました。 YAGNIの普及のタイミングは、ドットコムブームと一致しており、ソフトウェアプロジェクトはしばしば迅速な配信に対する強い圧力に直面していました。この原則は、迅速な開発の混沌に対する実用的な回答を提供しました。精巧なシステムを構築する衝動に抵抗し、当面のニーズを満たすことに集中し、将来の要件は到着したときに対処できると信頼する、というアプローチです。このアプローチは多くのプロジェクトで効果的であることが証明され、XPコミュニティを超えて主流のソフトウェア開発へのYAGNIの採用につながりました。要点
応用場面
機能開発
ユーザーやステークホルダーから明示的に要求された機能のみを構築してください。すぐに有用でない設定オプション、フック、拡張ポイントの追加を避けてください。
API設計
想像された将来のユースケースではなく、現在のニーズのためにAPIを設計してください。それらを予測してではなく、要件の出現に応じてエンドポイントとパラメータを追加してください。
データベーススキーマ
現在の要件のためにデータベース構造を作成してください。すべての将来のニーズを予測しようとするのではなく、アプリケーションの進化に応じてテーブル、カラム、リレーションシップを追加してください。
フレームワーク選択
現在のプロジェクトニーズに基づいてフレームワークとライブラリを選択してください。「万一に備えて」複雑なフレームワークを追加するのを避け、現在の要件に単純なソリューションで十分かどうかを検討してください。
事例
Stripe、オンライン決済処理会社は、初期開発でYAGNIの原則を有名に受け入れました。将来のニーズを予測して精巧な不正検出システム、国際化機能、高度な分析ツールを構築する代わりに、Stripeは一つのことを非常にうまくやることに集中的に焦点を当てました。シンプルで信頼性の高いオンライン決済を可能にすることです。会社が成長し、要件が明確になるにつれて、機能を段階的に追加していきました。このアプローチにより、Stripeは包括的なプラットフォームの構築に何年も費やした競合他社よりも速く動くことができました。Stripeが新機能を追加したとき、それらは推測的な将来の要件ではなく、実際の顧客ニーズによって推進されており、市場のニーズによりよく一致する製品となりました。境界と失敗モード
YAGNIの原則は価値がありますが、誤用される可能性があります。第一に、一部の要件は本当に予測可能です。予想されるスケールに対応するためのインフラや、既知の規制へのコンプライアンスを構築することは、推測的ではない「準備」を正当化するかもしれません。 第二に、YAGNIは良い設計実践を無視することを意味するのではありません。クリーンでリファクタリング可能なコードを書くことは、推測的な機能を構築することと同じではありません。この原則は、追加の機能性を構築することに対して警告しているのであり、コード品質の維持に対してではありません。 第三に、一部のドメインでは、ある種の先読み思考が本質的です。セキュリティシステムは攻撃ベクトルを予測する必要があります。安全クリティカルなシステムは障害モードを考慮する必要があります。YAGNIは、これらの文脈で思慮深く適用されるべきです。よくある誤解
YAGNIは決して事前に計画しないことを意味する
YAGNIは決して事前に計画しないことを意味する
YAGNIはアーキテクチャについて考えることを禁止していません。不要な機能を構築することを禁止しているのです。既知の要件をサポートする良いアーキテクチャは、依然として価値があります。
YAGNIは悪いコードを書くことを意味する
YAGNIは悪いコードを書くことを意味する
YAGNIは機能のスコープに関するものであり、コード品質に関するものではありません。現在のニーズに対応するクリーンで保守可能なコードは、YAGNIに関係なく、常にメッシュなコードより優れています。
YAGNIはDRYと矛盾する
YAGNIはDRYと矛盾する
DRYとYAGNIは一緒に機能します。DRYは重複が存在するときにそれを抽出します。YAGNIは重複が証明される前に抽象化を作成するのを防ぎます。両方とも異なる方法でコードを単純化します。
関連コンセプト
KISSの原則
YAGNIとKISSはどちらも単純さを提唱します。YAGNIは不要な機能の追加を防ぎ、KISSはそれらの機能を複雑にするのを防ぎます。
DRYの原則
DRYは重複が存在した後にそれを抽出します。YAGNIは不要な重複の作成を防ぎます。両者は単純なコードベースの維持において互いを補完します。
Minimum Viable Product
MVPは、価値を届けるために必要な機能のみを構築することでYAGNIを体現しています。追加機能はフィードバックに基づいて追加されます。
技術的負債
YAGNIは、不要なコードを防ぐことで技術的負債の蓄積を回避するのに役立ちます。使用されない機能はそれぞれ、保守負担に加算されます。
テスト駆動開発
TDDは、テストをパスするために必要な機能のみを引き出すことで、自然にYAGNIをサポートします。