design-patterns - YAGNIを強制するのがなぜそんなに難しいのですか?

Question

私はいつもこのパターンを破っています。

YAGNI - あなたはそれを必要としません

私はジュニア開発者にすぎませんが、シニアレベルの開発者でさえ同じことをしていることがわかります。

「まあ、このシステムはそれを使用するかもしれません。これは、それを設計しましょう。」

時々、自分自身を捕まえますが、ほとんどの場合、暴走します。YAGNI に固執するためのヒントや、設計およびコーディング中にこの設計パターンをより適切に適用するためにできることはありますか?

score 25 · Accepted Answer

何かのためのデザイン

…とは全然違う

何かをデザインする。

何かのために設計するということは、コードを書く必要が生じた場合に備えて、将来の拡張のためにアプリケーションを設計していることを意味します (これは良いことです...つまり、ソフトウェアを拡張可能で保守しやすくしていることを意味します)。

何かをデザインするということは、それを実際に誰かが使うかどうかに関係なく、全体を書いているということです。それは必ずしも悪いことではありませんが、膨大な時間の浪費になる可能性があります。

どちらを行っているか注意してください。

score 9 · Accepted Answer

これは完璧主義と関係があります。完璧にしましょう。将来起こりうるすべてのシナリオに備えましょう。

それが必要になる可能性を決定するときは、実用的で冷静になることが役立ちます。作成してから、「はい」または「いいえ」のいずれかで答えてください。たぶんノーです。

それが必要になるという明確な証拠がなく (議題にあり、顧客から要求されている)、現在の設計でその将来の機能を考慮したほうがよいと思われる場合を除き、今は省略してください。

score 7 · Accepted Answer

TDDを使用するだけです!!!

必要のない機能のテストを書いていることに気付くことはめったにありません...

score 7 · Accepted Answer

YAGNI は原則であるため、万能薬ではありません
。ソフトウェア開発では、常に多くの要件のバランスを取る必要があります。1 つのことを正しく行うことではなく、多くの間違いをなくすことです。YAGNII だけではお尻を救うことはできません。

その意味で、YAGNI は次の落とし穴を回避するために存在します。

コンパイラが必要な場合は、自己コンパイルコンパイラフレームワークではなく、コンパイラを作成します (一般的な問題を解決するという当社の強みは、当社の弱点でもあります)。
実装の労力を過小評価しないでください。
アプリケーションの寿命と要件の安定性を過大評価しないでください

競合する要件のバランスを取ることは困難です。しかし、だからこそ、McConnell が痛烈に述べたように、ソフトウェア開発はエンジニアリングなのです。

他の原則も人なので他の
原則の原則 - より基本的な IMO - は、最小の驚きと複雑さのカプセル化の原則です: エンティティの公開インターフェイス/契約は、実装よりも単純でなければなりません - そうでなければ、関数を正しく呼び出すために私は自分でやるためには、必要以上のことを知らなければなりません。場合によっては、実装を完了する必要があることを意味します。

一例（あまり良いものではないかもしれません）：

/// Estimates the time required to comlete the batch.
/// If the time cannot be estimated reliably, the return value is -1
/// \returns [double] estimated time in seconds
double EstimateDuration(Batch & batch);

簡単な契約です。大戸、

/// Estimates the time required to comlete the batch.
/// If the time cannot be estimated reliably, the return value is -1.
/// This function does not support looping batches (right now, looping
/// batches only run under a servicve account with no UI, so it's not needed).
/// Also, when the moon is full, the return value is -1, but an estimate 
/// is found in batch.JeffsEstimate. This value is used only by Jeff's core 
/// build script which runs roughly once a month.
/// \returns [double] estimated time in seconds
double EstimateDuration(Batch & batch);

契約ではなく、実装の説明です。(問題が熱心すぎる YAGNI の結果なのか、それとも単純に悪い設計の結果なのかについて議論することもできますが、おそらくそれは、あなたが完全に YAGNI を設計したためです)

設計は害をなさない
アジャイルの出現により、「設計フェーズ」は何か悪い名前になりました。しかし、まったく計画を立てないよりも悪いことに、あなたの計画は破滅的なものでなければなりません。最大の危険は本当に悪い計画ではなく、すべての問題と変更要求を予測しようとすることです。YAGNIはここで非常に貴重です。

結局のところ、彼らは年配です。私は彼らを知りません。彼らの傾向は、昔ながらのウォーターフォール教化と変化への恐れによるものかもしれません。あるいは、彼らは自分の仕事を知っているために年配者なのかもしれません。彼らは、将来の不確実性のためにどの部分を犠牲にすることができるかを学びました。

score 6 · Accepted Answer

YAGNI を強制するのは非常に難しいのは、私たちのほとんどが逆の問題に悩まされていると思うからです。システムが複雑すぎたり脆すぎたりして、やりたいことを行うにはリファクタリングできないが、もう少し事前に考えていれば可能だったはずのシステムを見つけるということです。 . 中間点を見つけるのは難しい場合があります。

一般的に言えば、「[xyz] が必要かもしれない」と考えている場合は、それがコードの中で明確に役割を果たしているはずです。xyz をサポートするようにコーディングしない場合でも、xyz サポートを追加するためのリファクタリングが可能な限り実用的な方法でコーディングする必要があります。ただし、厳密に必要なものよりも一般的なものを作成することを意味する場合もあります。そのパスに沿って停止する場所を知ることは、おそらく、経験と組み合わされたドメイン固有の情報だけが教えてくれるものです.

score 4 · Accepted Answer

「基本に立ち返る」と「シンプルイズグッド」は、目の前のタスクにとどまり、なぜこの機能や拡張機能を構築するのかを理解するように促すフレーズです。おそらく起こらないこと。私が働いている場所では、私の名前は、過度に設計された、または過度に複雑なものを説明する方法としてよく使用されます。私はこれをもっと抑えようとしていますが、これは便利な場合もありますが、私の一般的な慣行になるには十分ではないことがよくあります.

要件を非技術的な用語で書き出すことも役立つ場合があります。これにより、最後に何を表示する必要があるかを知ることができ、細かい詳細について心配する必要がなくなります。たとえば、システムのユーザーは、私のソースコードを読んだり、私たちが使用する命名規則の使用をあざけったりすることはありません。彼らはそれが機能することを気にかけ、必要なことややりたいことを行います。

尋ねるべきもう 1 つの質問は、「彼らは本当にこれを求めたのですか?」ということです。機能についての仮定を最小限に抑えるようにしてください。リストにない場合は、除外しますが、必要かどうかを尋ねます。

score 3 · Accepted Answer

ライブラリ/ツールキット/プラットフォーム/フレームワークを構築している場合、YAGNI は別の意味を持ちます。

他の開発者があなたのツールをどのように使用するかはわかりませんが、製品をさまざまなシナリオで使用できるように、柔軟に設計する方がはるかに理にかなっている場合があります。上位互換性も大きな考慮事項です。

YAGNI は引き続き適用されますが、「それ」は機能レベルではなく、メタ機能レベルになる傾向があります。

score 2 · Accepted Answer

さて、私は昨日同じことに遭遇し、上級開発者の1人と大きな戦いをしました。私はいつも「誰かがこれを呼んだら、これがトムに変わったらどうなるかなど」でデザインしようとしています。そして彼はもう一方の極端です。「それを機能させて速くするだけです！」

答えは彼のアプローチと私のアプローチの間のどこかにあります。どうやって中途半端になりますか？人々が喜ぶ「完璧な」デザインを作ろうとするか、将来何かを変えなければならない場合に嫌うかの間。

IMHOの答えは、少なくともモジュールの設計中は、明確なインターフェイスの定義など、オブジェクト指向プログラミングの基本原則に要約されます。インターフェイスは、顧客からの要件と一致する必要があります。モジュールのメインインターフェイスには、要件にあるもの以外のものを「解決」するものがあってはなりません。「これが変わったら、明日も必要になる」などの理由で追加された「フリル」は少なくともある程度は削除できます。

これが明日誰か他の人に使われるかもしれないと思うのであなたが置くことを計画しているものは何時間も議論されなければなりません！現在名前すら持っていない人のために「景品」を追加するのには十分な理由があるはずです！

私はまだこの質問に対する決定的な答えが必要です。おそらく、大きなアプリケーションを設計し、この状況に100回直面したアーキテクトからです:)

score 2 · Accepted Answer

YAGNI については、実際にはもっと質問する必要があります。私たちは上級開発者として、常に YAGNI に違反しています。まさに「必要性」の問題です。それが必要ですか？「必要」を定義します。私はYAGNIドグマを使って開発されたひどい泥の玉を見てきました。

YAGNI が役に立たないと思っているわけではありません...「これが必要ですか」と尋ねることは常に価値があります。

score 1 · Accepted Answer

将来の機能を簡単に実装できるようにアプリケーションを設計することは良いことですが、実際には必要になるまで機能を実装しないでください。これを行う方法は、作業中のプロジェクトに完全に依存します。

score 1 · Accepted Answer

ピアレビューとピアプログラミングがこれに役立つと思います。あなたの推論に疑問を呈する別の目は、あなたが必要だと思うものをすぐに識別しますが、実際にはそうではありません.

score 1 · Accepted Answer

私たちの会社には経験則があります。新しい機能の設計について話し合っているとき、最初に答える質問は「誰が本当にこれを望んでいるのか?」です。顧客が背後にいる場合は、顧客が本当に望んでいることを理解しようとし、(新機能を追加するのではなく) 問題を解決する別の方法があるかどうかを理解しようとします。チームのメンバーがこの新機能を求めている場合は、正当な理由が必要です。そのために。パフォーマンスの問題やマーケティング上の懸念もその中にあり、コードベースに新しい機能を追加する前に、要求を完全に理解し、考えられるすべての代替案について話し合うよう努めています。

score 0 · Accepted Answer

アジャイルに従っている場合は、必要のないものに到達するまで、重要なものに取り組むことができます。YAGNI にたどり着く頃には、ほぼ完成した製品になっているはずです。その場合、開発をやめるように言うのはビジネス次第です。

score 0 · Accepted Answer

YAGNI はしばしば後知恵のことです。「YAGNI」が明らかになったときに「I」を削除するのに十分機敏であることを確認してください。

design-patterns - YAGNIを強制するのがなぜそんなに難しいのですか?

15 に答える 15

Related

Reference