デカップリング対YAGNI

Question

矛盾しますか？

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

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

Answer 1

デカップリングとYAGNIは非常に補完的な美徳です。 （私はロブの答えに気付きました、そして、私たちはここの同じページにいるようです。）質問はあなたがすべきデカップリングの程度であり、YAGNIは答えを決定するのに良い原則です。 （単体テストについて話している人のためにユニットテストを行うためにデカップリングが必要な場合は、YAGNIは当然適用されません）

私は本当に誠実に「常に」デカップルと言う人を疑う。たぶん、彼らはいつも彼らがそれを考えるたびに行動します。しかし、私は抽象概念の追加レイヤーをどこかに追加できないプログラムを見たことはありませんでした。私はそこにそのようなプログラムの例があることを心から疑っています。誰もがどこかに線を引く。

私の経験から、私はコードをデカップルした後、コードを結合したままにしておいて、その後に戻ってそれを変更しなければならないほどの柔軟性を、決して利用しませんでした。バランスが取れているか、両方向に均等に壊れているかどうかはわかりません。

Answer 2

I（ほぼ）は常にデカップリングします。私がこれを行うたびに、私はそれが有用であることを発見しました、そして、（ほとんど）私が後でそれをやらなければならないたびに。また、バグの数を減らすための良い方法だとわかった。

Answer 3

YAGNIは、人々が投げ捨てる偽の単純なフレーズではありません。しかし、デカップリングはかなりよく理解されている概念です。 YAGNIは、ある人が何らかの霊魂であることを暗示しているようです。それは決して良い考えではない決意でプログラミングです。正直言って、YAGNIはおそらくデカップリングに関連していないと思われるケースがあります。カップリングは典型的には「より速く」、「分離されたソリューションが必要かどうかを誰が知っていますか、とにかくXコンポーネントを変更するつもりはありません！

Answer 4

デカップリングのためにデカップリングが悪い可能性があります。しかし、テスト可能なコンポーネントをビルドすることは非常に重要です。

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

Answer 5

あなたのタグが言うように、それは非常に主観的です。それは、あなたが "必要としない"ものを決めるためにあなた自身の工学的知恵に全面的に依存しています。あるケースではカップリングが必要かもしれませんが、別のケースではカップリングしません。誰が教えてくれる？ もちろん、です。

このように主観的な決定をするには、処方のガイドラインを作成することはできません。

Answer 6

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

これらの実践的な結果は、アプリケーション全体にうっかり波及効果を引き起こさずに、個々のコンポーネントをリファクタリングして維持することがずっと簡単で、設計にとって不必要に複雑な側面がない場合です。現在の要件を満たすために必要な単純なものです。

Answer 7

私は本当に、私たちはすべてのコードを混ぜて "高速"にする必要はありません。

単体テストは、それが結合されたときの感覚に本当に役立ちます（単体テストと他のタイプのテストとがよく分かれば）。 「あなたはコンポーネントを分けることはできません」という考え方ではなく、必要としないものを簡単に追加することができます:)

私はYAGNIが、現在の実装で必要とされる実際の使用シナリオを超えています。外部サイトにリダイレクトする両方の外部支払いプロバイダを使用するコードがあるとします。すべてをきれいに保つ設計は大丈夫ですが、統合と関連するさまざまな処理方法がたくさんあるサポートされているかどうかわからないプロバイダを考え始めるのは大丈夫だとは思いませんワークフロー。

Answer 8

「ユニットテストはお尻の痛みです」と言えば、はが必要です。ほとんどの場合、デカップリングは事実上ゼロコストでも達成できます。なぜそれをやりたいのですか？

さらに、私の最大のバグベアの1どこかのインターフェイスの導入や依存性注入の使用は、時間の多くを救うことができるときに私はユニットテストを書き始めることができます前に、コードを分離する必要がされた新しいコードベースに取り組んで

Answer 9

YAGNIは経験則です（宗教ではありません）。デカップリングは多かれ少なかれ技術（宗教でもない）です。彼らは本当に関連しておらず、お互いに矛盾していません。

YAGNIは約プラグマティズムです。あなたがするまであなたは何かが必要ではないと仮定します。

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

「デカップル」（または「疎結合」）は動詞なので、作業が必要です。 YAGNIは推定であり、もはや真実ではないと分かったときに調整します。