10

YAGNIの「原則」では、必要になる前に機能を提供することに集中すべきではないと述べています。

私は通常、どんなルールよりも常識を使用する傾向がありますが、正当な理由があれば、それを決して使用しない可能性がある場合でも、過度に設計したり、将来の証明に役立つと感じることがあります。

私が今手にしている実際のケースは、多かれ少なかれ次のようなものです。

単純な専用通信プロトコル(OSI レベル 4)で実行する必要があるアプリケーションがあります。このプロトコルには、アプリケーションに堅牢性を提供する望ましい特性のセット (NORM 仕様に従うなど) がありますが、厳密には必要ではありません (UDP マルチキャストは許容できるパフォーマンスを発揮できます)。

また、このアプリケーションは将来 (確実ではありませんが) 他のクライアントによって使用される可能性が高く、独自のソリューションにアクセスできないため、別のソリューションが必要になるという事実もあります。私は、アプリケーションの別のクライアントの可能性が高いことを知っています。

それで、あなたの考えは何ですか？プロプライエタリ プロトコル用に設計し、リファクタリングやインターフェイス抽出などは本当に必要なときに任せるべきですか、それとも(それほど遠くない) 未来を考えて今設計すべきでしょうか?

注:明確にするために、一般的な質問 (いつ YAGNI に違反するか) に対するあらゆる種類の意見を聞くことに興味がありますが、現在のジレンマについてのアドバイスや考えが本当に欲しいです :)

4

8 に答える 8

8

YAGNI がコードに適用される理由は、変更のコストが低いためです。適切にリファクタリングされた優れたコードを使用すると、後で機能を追加しても通常は安価です。これは、セイの建設とは異なります。

プロトコルの場合、変更を後で追加することは通常、安くはありません。古いバージョンは破損し、通信障害につながる可能性があり、他のすべてのバージョンに対してすべてのバージョンをテストする必要があるため、N^2 テスト マトリックスが発生する可能性があります。これを、新しいバージョンがそれ自体で動作するだけでよい単一のコードベースと比較してください。

したがって、あなたの場合、プロトコル設計については、YAGNI はお勧めしません。

于 2009-02-16T09:22:15.557 に答える
7

私見では

  • I'd say go YAGNI first. Get it working without the NORM specification using 'the simplest thing that would work'.
  • Next compare if the cost of making the 'design changes' in the future is significantly greater than making the change now. Is your current solution reversible ? If you can easily make the change tomorrow or after a couple of months don't do it now. If you don't need to make an irreversible design decision now.. delay till the last responsible moment (so that you have more information to make a better decision)

To close if you know with a considerable degree of certainity that something is on the horizon and adding it later is going to be a pain, don't be an ostrich.. design for it.
e.g. I know that diagnostic logs would be needed before the product ships. Adding logging code after a month would be much more effort than adding it in today as I write each function... so this would be a case where I'd override YAGNI even though I dont need logs right now.

See-also: T. & M. Poppendieck's Lean books are better at explaining the dilemma of bullet#2 above.

于 2009-02-16T09:13:45.030 に答える
5

Structuring your program well (abstraction, etc) isn't something that YAGNI applies to. You always want to structure your code well.

Just to clarify, I think your current predicament is due to over application of YAGNI. Structuring your code in such a way that you have a reusable library for using this protocol is just good programming practice. YAGNI does not apply.

于 2009-02-16T09:02:33.997 に答える
3

何かを学びたい場合、YAGNI は不適切かもしれないと思います :) YAGNI は専門家には適していますが、学生には適していません。学びたいときは、いつでもそれが必要になります。

于 2009-02-16T08:57:06.460 に答える
3

私はそれが非常に単純で明白だと思います：

YAGNI に違反するのは、それが必要になると完全に確信している場合です。

于 2009-02-16T09:18:44.067 に答える
2

I wouldn't worry. The fact that you aware of "YAGNI" means you are already thinking pragmatically.

I'd say, regardless of anything posted here, you are statistically more likely to come up with better code than someone who isn't analysing their practices in the same way.

于 2009-02-16T09:02:07.930 に答える
0

ギスとニックに同意します。

後でプロトコルの一部を設計すると、「くそー、私はこれをそのように行うべきだったので、今はこの醜い回避策を使用する必要がある」というような考えにつながることがよくあります。

しかし、それは誰がこのプロトコルとインターフェースするかにも依存します。
コントロールの両端があり、同時にバージョンが変更される場合は、通常のコードインターフェイスの場合と同じように、後でいつでもプロトコルをリファクタリングできます。

後で追加のプロトコル機能の実装を行うことについて、プロトコルを実装するとその設計を検証するのに大いに役立つことがわかりました。したがって、設計が必要な場合は、少なくとも、単純な非生産のコードサンプルを実行してテストすることをお勧めします。公式になります。

于 2009-02-16T13:58:44.473 に答える
0

YAGNI の直感に反することが理にかなっている場合もあります。

ここにいくつかあります：

プログラミング規約に従います。特に基本クラスとインターフェイス コントラクト。たとえば、継承する基本クラスが GetHashCode と Equals メソッドを提供する場合、GetHashCode ではなく Equals をオーバーライドすると、開発者が Equals をオーバーライドするときに従う必要がある、プラットフォームで文書化されたルールが破られます。GetHashCode が実際には呼び出されないことがわかった場合でも、この規則に従う必要があります。GetHashCode をオーバーライドしないことは、それを引き起こす現在の方法がない場合でも (不自然なテスト以外に) バグです。プラットフォームの将来のバージョンでは、GetHashCode の呼び出しが導入される可能性があります。または、ドキュメント (この例では、継承している基本クラスのプラットフォーム ドキュメント) を見た別のプログラマーは、コードを調べずに、コードが準拠していると当然期待するかもしれません。

カスタマイズをサポート。特に、ソース コードを変更しない外部開発者によるものです。これらの開発者が思いもよらなかったあらゆる種類のアドオン機能を実装できるように、適切な拡張ポイントを見つけてコードに実装する必要があります。残念ながら、外部開発者が最終的に使用することはほとんどないとしても、いくつかの拡張機能を追加することは当然のことです。(事前にすべての外部開発者と拡張性の要件について話し合うか、頻繁な開発/リリース サイクルを使用することが可能であれば、すばらしいことですが、これはすべてのプロジェクトで実現可能ではありません。)

アサーション、デバッグ チェック、フェイルセーフなど。このようなコードは、アプリケーションが正しく動作するために実際には必要ありませんが、コードが現在および将来改訂されたときに正しく動作することを確認するのに役立ちます。

于 2009-08-06T03:27:37.307 に答える