問題タブ [yagni]

ウィザードは機能をキックスタートできます。また、コードを難読化することもでき、アンチ YAGNI です。

結局、魔法使いの方が便利だと思いますか、それとも有害だと思いますか?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

彼らは矛盾していますか？

デカップリングは素晴らしいものであり、達成するのは非常に困難です。ただし、ほとんどのアプリケーションでは実際には必要ないため、高度に結合されたアプリケーションを設計でき、「コンポーネントを分離できない」、「単体テストは苦痛」などの明らかな副作用以外はほとんど変わりません。 arse」など。

どう思いますか？常に分離してオーバーヘッドに対処しようとしていますか？

私は IoC と DI について多くのことを読みましたが、ほとんどの状況でそれらを使用することで多くの利益が得られるとは確信していません。

プラグ可能なコンポーネントを必要とするコードを作成している場合、その価値はわかります。しかし、そうでない場合は、依存関係をクラスからインターフェイスに変更することで、タイピングの増加以外に本当に何かが得られるかどうか疑問に思います。

場合によっては、IoC と DI がどこでモッキングに役立つかがわかりますが、モッキングや TDD を使用していない場合、どのような価値があるのでしょうか? これはYAGNIのケースですか？

他に使用できる可能性がある場合は、常にインターフェイスを作成する必要がありますか、それとも実際に必要になるまで待ってから、インターフェイスを使用するようにリファクタリングする必要がありますか？

インターフェイスへのプログラミングは一般的に適切なアドバイスのように思えますが、YAGNIがあります...

多分状況次第だと思います。現在、レシピやその他のフォルダーを含めることができるフォルダーを表すオブジェクトがあります。Folderを直接使用する代わりに、IContainerのようなものを実装することを心配する必要がありますか？将来、他のサブレシピを参照するレシピが必要な場合に備えて（たとえば、パイクラストレシピのコンテナでもあるアップルパイレシピ）

コードでは、通常、新しいクラスを追加して追加機能などを提供するのは非常に簡単です。私はコードのリファクタリングとその内容についてかなりよく理解しているので、YAGNIは一般的に私にとって理にかなっています。

私がよく知らないのは、デプロイされたリレーショナル データベースの操作と更新です。早期リリース、頻繁にリリースを実践することを計画している小さなペットプロジェクトを開発しています。初期リリースでは使用されないが、計画された機能リストにあるデータを検討する必要があるかどうか疑問に思っています? 新しいクラスを追加するのと同じくらい簡単に、テーブルを追加してスキーマを微調整できますか? それとも、おそらく使用できるものの、当面は計画していないもののためにテーブルをセットアップする必要がありますか?

G'day、

将来起こりうる変更に備えて過剰設計することについてここでこの質問について考えている間、私は考えさせられました。

「将来のある段階で他の場所で使用したいと思うかもしれない」という理由でデザインを吹き飛ばすことを主張する人々に、どのような理由を提供できますか？

同様に、人々が要件を受け入れてから、あなたが求めていなかった余分な「ベルとホイッスル」がたくさんある肥大化したデザインで戻ってきたとき、あなたはどうしますか？

現在または近い将来に存在する要件または考えられる用途に意味があることがわかっている場合、設計を拡張することは理解できます。そして、私は、要件のリストを簡単に受け入れて、不足していると思われるものについてのフィードバックを提供せずに、それを明示的に実装することを主張しているのではありません。

私は、人々が「将来のある段階でそれをどこかで使用するかもしれない」ために、無関係な機能を追加したり、持ったりすることを主張するときにどうするかについて話している。

新しいシステムのコードを書くとき、私は決して必要としないかもしれない不必要な複雑さを設計に導入したくありません。そこで、私はここで YAGNI に従っていますが、柔軟性を高める必要があるか、責任がより明確になるにつれてリファクタリングを行っています。これにより、私はより速く動くことができます。

しかし、若手の開発者には、いつリファクタリングを行うべきか、どこで設計を構築するべきかを認識できないという問題があります。既存の設計にコードを追加するだけです。

それで、これに取り組む最善の方法は何ですか？何も追加する必要がない場合でも、追加するときに彼らが従うべき良い例になるように、より将来性のある設計をより頻繁に構築する必要がありますか? それとも、コードのレビューや教育などをさらに進める必要がありますか? または両方？

この種の問題を経験したことのある人はいますか? どのように解決しましたか？