デカップリングとYAGNI

Question

矛盾していますか？

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

あなたはどう思いますか？常にオーバーヘッドを切り離して対処しようとしていますか？

Answer 1

デカップリングとYAGNIは非常に補完的な美徳であるように思えます。 （私はちょうどロブの答えに気づきました、そして、私たちはここで同じページにいるようです。）問題はあなたがどれくらいデカップリングするべきであるかであり、YAGNIは答えを決定するのを助ける良い原則です。 （単体テストについて話す人のために-単体テストを行うために分離する必要がある場合、YAGNIは明らかに適用されません。）

「常に」と言う人を本当に心から疑います。デカップリング。たぶん、彼らはそれを考えるたびにいつもそうするでしょう。しかし、抽象化のレイヤーをどこにも追加できないプログラムを見たことはありません。そのようなプログラムの非自明な例があることを心から疑います。誰もがどこかに線を引きます。

私の経験から、私はコードを二重化しましたが、コードを結合したままにして、後で戻って変更しなければならなかったほど頻繁に追加の柔軟性を利用することはありませんでした。バランスが取れているのか、それとも両方向で同じように壊れているのかはわかりません。

Answer 2

YAGNIは経験則です（宗教ではありません）。デカップリングは多かれ少なかれテクニックです（宗教でもありません）。したがって、それらは実際には関連しておらず、互いに矛盾していません。

YAGNIはプラグマティズムです。必要になるまで、何も必要ないと仮定します。

通常、YAGNIを想定すると、デカップリングになります。そのナイフをまったく適用しない場合、それが真実であることを実証する前に、互いの行動についてすべてを知っているクラスが必要であると仮定することになります。

＆quot;デカップル＆quot; （または "loosely couple"）は動詞なので、作業が必要です。 YAGNIは仮定であり、もはや真実ではないことがわかったら調整します。

Answer 3

I（ほぼ）常に分離します。これを行うたびに、私はそれが有用であるとわかりました。そして、（ほぼ）毎回、後でそれをする必要がありませんでした。また、バグの数を減らす良い方法であることがわかりました。

Answer 4

そうではないと思います。デカップリングとは、コード内の不要な依存関係を減らし、明確で明確に定義されたインターフェイスを介してアクセスを強化することです。 ＆quot;あなたはそれを必要としませんよ＆quot;一般に、明白で現在のユースケースがないソリューションの過剰な拡張性と過度に広範なアーキテクチャに対して助言する有用な原則です。

これらの実用的な結果は、アプリケーション全体にうっかりリップル効果を引き起こすことなく個々のコンポーネントをリファクタリングおよび保守することがはるかに簡単で、設計に不必要に複雑な側面がないシステムがあることです-それは簡単です現在の要件を満たすために必要です。

Answer 5

デカップリングのためのデカップリングは悪い場合があります。 ただし、テスト可能なコンポーネントの構築は非常に重要です。

ストーリーの難しい部分は、いつ、どの程度のデカップリングが必要かを知ることです。

Answer 6

「単体テストが苦痛」の場合それからあなたはそれを必要とする と言うでしょう。ほとんどの場合、デカップリングは実質的にゼロのコストでも実現できるので、なぜそうしないのですか？

さらに、新しいコードベースで作業するときの最大のバグの1つは、どこかでインターフェイスの導入や依存関係の注入を使用すると時間を大幅に節約できる場合、ユニットテストの作成を開始する前にコードを分離する必要があることです

Answer 7

タグにあるように、非常に主観的です。あなたが「必要ない」ものを決めるのは、あなた自身のエンジニアリングの知恵に完全にかかっています。ある場合にはカップリングが必要かもしれませんが、別の場合には必要ありません。誰に伝えますか？もちろん、あなた。

非常に主観的な決定については、規定するガイドラインはありません。

Answer 8

まあ、YAGNIは人々が放り出す単純な単純なフレーズにすぎません。ただし、デカップリングはかなりよく理解されている概念です。ヤグニは、ある種の霊魂者であることを暗示しているようです。それは単なる決まり文句によるプログラミングであり、決して良い考えではありません。正直に言うと、YAGNIはおそらくデカップリングとはまったく関係がないというケースがあります。カップリングは通常、「キッカー」です。そして、あなたがあなたが分離されたソリューションを必要とするかどうかを知っている＆quot;とにかくXコンポーネントを変更するつもりはありません！＆quot;

Answer 9

YAGNI the mess :) ...本当に、すべてのコードを混合して「高速化」する必要はありません。

単体テストは、それが結合されているときの感覚に本当に役立ちます（単体テストと他のタイプのテストとが何であるかをよく理解している場合）。代わりに「コンポーネントを分離できません」でそれを行うと、考え方、必要ないものを簡単に追加できます：）

YAGNIは、現在の実装が要求する実際の使用シナリオを超えて、ロジックのねじれや変更を開始したときに登場します。たとえば、外部サイトへのリダイレクトで動作するいくつかの外部支払いプロバイダーを使用するコードがあるとします。すべてをきれいに保つ設計を持つことは問題ありませんが、統合および関連するものを処理する多くの異なる方法がサポートされるかどうかわからないプロバイダーについて考え始めることは問題ないと思います。ワークフロー。