16

仕事のやり方にアジャイル思考をどんどん吸収していくにつれて、ヤグニ (「あなたはそれを必要としない」) がますます重要になっているようです。見当違いの優先順位を除外し、次に取り組まないものを決定するための最も効果的なルールの 1 つであるように私には思えます。

しかし、ヤグニは、ここ SO ではほとんどささやかれている概念のようです。必須の検索を実行しましたが、それは 1 つの質問のタイトルにのみ表示され、その後は二次的な役割に表示されます。

どうしてこれなの？その重要性を過大評価していませんか?

免責事項。私が異議を唱えると確信している応答を先取りするために、ヤグニは迅速で汚いの反対であることを強調させてください. 貴重な時間と労力を、必要な部品を正しく入手することに集中することをお勧めします。

以下は、人が尋ねるかもしれないいくつかの最先端の進行中の質問です。

単体テストは、ユーザーの要件またはフレームワーク構造に基づいて選択されていますか?

フレームワークから外れているため、そこにあるだけの単体テストをインストール (およびテストと保守) していますか?

私のフレームワークによって生成されたコードのうち、私が一度も見たことのないものはどれくらいありますか?

ユーザーの問題ではなく、ツールの作業にどれくらいの時間を費やしていますか?

ペアプログラミングの場合、オブザーバーの役割値は「yagni」にあることがよくあります。

CRUD ツールを使用していますか? _RU_ ツールまたは C__D ツールとして使用することを許可しますか (いや、推奨しますか)、それとも 1 つまたは 2 つしか必要ないのに 4 つのコード (および 4 つの単体テスト) を作成しますか?

4

6 に答える 6

12

TDD はある意味で YAGNI を包含しています。TDD を適切に行う場合、つまり、必要な機能をもたらすテストのみを記述し、テストに合格する最も単純なコードを開発する場合、デフォルトで YAGNI の原則に従っていることになります。私の経験では、私が YAGNI に違反しているのは、TDD の枠の外に出て、テストの前にコードを書き始めたとき、本当に必要のないものをテストしたとき、またはテストに合格するための最も単純な方法以上のコードを書き始めたときだけです。 .

私の経験では、後者はTDDを行う際の最も一般的な失敗です.私は先に進んで次のテストに合格するためにコードを書き始めます. その結果、テストする必要があるものの要件ではなく、自分のコードに基づいた先入観を持つことで、残りのテストを妥協する結果になることがよくあります。

YMMV。

于 2008-12-15T22:32:37.697 に答える
4

Yagni と KISS (シンプルに、バカにしてください) は本質的に同じ原理です。残念ながら、私は「ヤグニ」と同じくらい頻繁に KISS について言及されています。

荒野の私の部分では、プロジェクトの遅延と失敗の最も一般的な原因は、不要なコンポーネントの不十分な実行であるため、あなたの基本的な感情に同意します.

于 2008-12-15T22:46:04.970 に答える
3

変更の自由はYAGNIを駆り立てます。ウォーターフォールプロジェクトでは、マントラはコントロールスコープです。範囲は、顧客との契約を確立することによって制御されます。その結果、顧客は、契約が締結されるとスコープの変更が困難になることを知って、スコープドキュメントに思いつく限りのことを詰め込みます。その結果、価値のある機能のセットではなく、機能の洗濯物リストを持つアプリケーションになってしまいます。

アジャイルプロジェクトでは、製品所有者は優先順位の高い製品バックログを作成します。開発チームは、優先度、つまり価値に基づいて機能を構築します。その結果、最も重要なものが最初に構築されます。最終的には、ユーザーが評価する機能を備えたアプリケーションになります。重要ではないものはリストから外れるか、実行されません。それがYAGNIです。

YAGNIは実践ではありませんが、優先順位付けされたバックログリストの結果です。ビジネスパートナーは、製品のバックログを反復ごとに変更して優先順位を付け直すことができるため、ビジネスに与えられる柔軟性を高く評価しています。YAGNIは、プロセスの後半であっても、変更をすぐに受け入れることで得られるメリットであることを説明するだけで十分です。

于 2009-05-12T19:44:50.127 に答える
1

私が見つけた問題は、YAGNI の下で DI コンテナーを使用して (コードベースに既に DI コンテナーがある場合を除く)、ファクトリを作成することさえバケツに入れる傾向があることです。私はそこでJBキングに同意します。私が YAGNI と一緒に仕事をした多くの人にとって、手抜きをしたり、ずさんなコードを書いたりするライセンスのように思えます。

たとえば、複数のモデル/メーカーの PINPad を抽象化するための PinPad API を作成していました。全体の構造がわからないと、単体テストも書けないことがわかりました。私はTDDの経験豊富な実践者ではないかもしれません。私がやったことが YAGNI かどうかについては、さまざまな意見があると思います。

于 2008-12-17T23:16:58.057 に答える
0

yagni の一種である時期尚早の最適化、または少なくとも ydniy を参照する SO に関する多くの投稿を見てきました (まだ必要ありません)。

于 2008-12-15T22:33:48.037 に答える
-1

私は YAGNI をクイック アンド ダーティの対極にあるとは考えていません。誰かが書いたソフトウェアが 50 年も持たなければならないような計画を立てるのではなく、必要なことだけを行っているのです。少なくとも私の心には、それについて尋ねる質問が実際にはそれほど多くないため、めったに来ないかもしれません. 「同じことを繰り返すな」や「単純でばかげたままにしておく」というルールに似ていますが、これらは一般的になっていますが、必ずしも 101 の方法で分析および分析されているわけではありません。いくつかのことは、通常、少し練習すればすぐに習得できるほど単純です。舞台裏で開発されているものもあり、振り返って見ると、物事を述べる別の方法であることに気付くかもしれません.

于 2008-12-17T22:39:37.603 に答える