問題タブ [dry]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
3 に答える
267 参照

mysql - DRY および同様のクエリ

特定のアプリケーションに取り組んでいると、非常によく似たクエリを何度も書き続けます。それらはまったく同じではありませんが、非常に似た形式であり、ほぼ同じコードのチャンクに埋め込まれています

その後、別の場所で...

...そして別の場所で別の...など。

これは本当に DRY に違反しているのでしょうか? この種のクエリを実行するためのクラスを作成し (テーブル、列、バインドされた変数などのコンストラクターパラメーターまたはセッターを使用)、それをアプリ全体で再利用するのは意味がないようです。しかし同時に、自分自身を繰り返しているというしつこい気持ちを振り払うことはできません.

おそらく、単純なクエリを記述する方法が非常に多く、このような一定量の繰り返しが予想されるだけです。

考え?

0 投票する
4 に答える
1701 参照

.net - 循環依存と DRY

core.xml.dll と core.string.dll という名前の 2 つのアセンブリ (とりわけ) を含む再利用可能なクラス ライブラリを設計しています。

xml アセンブリは、いくつかの文字列ヘルパー メソッドを使用するために、文字列アセンブリを参照します。

ただし、xml アセンブリに含まれるメソッドを使用することでメリットが得られる文字列メソッドが存在するようになりました。

文字列アセンブリから xml アセンブリを参照すると、循環依存関係が作成され、ソース コードから両方のアセンブリをビルドできなくなります。(つまり、ニワトリと卵の問題)。

「自分自身を繰り返さない」という原則に従うために、両方のアセンブリで機能が重複することを避けたいと思います。実装にバグが見つかった場合は、1 か所だけ修正したいと考えています。

アセンブリを 1 つにマージすることはできますが、アセンブリの結合性が低下するため、これは理想的ではありません。

特定のクラスにわずかな変更を加えるだけで、アセンブリ全体を再構築して再展開する必要があります。また、最終的には、非常に多くの依存関係があるため、1 つの巨大なライブラリ アセンブリになってしまう可能性があります。

では、再利用可能なライブラリ アセンブリのセットのコンテキストでは、ここで使用する最善の方法は何でしょうか? また、.NET フレームワーク自体はこの問題にどのように対処していますか?

(Reflector では、System.Configuration.dll が System.XML.DLL を参照しているように見えます。逆もまた同様です。これは実際に正しいのでしょうか?もしそうなら、循環依存関係はどのように管理されていますか?)

0 投票する
3 に答える
368 参照

linq-to-sql - 共通の列を持つテーブルの DRY LINQ ステートメント

ここに興味深い問題があります。指定されたテーブルに列 x、y、z が含まれていることだけを知っているが、コンパイル時にどのテーブルを扱っているかを知らないテーブル UPDATE を実行できる LINQ to SQL を使用してコードを記述する方法はありますか?

DBスキーマにいくつかの列を共有するいくつかのテーブルがあり、どのテーブルを扱っているかに関係なく、論理手順が同一のセットベースのUPDATE操作を適用する必要があります。

簡単な例を次に示します。隣接モデル階層を実装する 3 つのテーブルがあるとします (つまり、各行には主キー ID と自己参照の親 ID 列が含まれます)。各テーブルには、「無効」のブール フラグもあります。これらのエンティティのいずれかのインスタンスを無効にすると、子アイテムをカスケードする必要があります。

UPDATE MyTable SET 無効 = 1 WHERE ID = @ID または Parent_ID = @ID

エンティティごとにこの種の LINQ ステートメントを記述したくありません。DRY に違反しています。この例では些細なことのように思えるかもしれませんが、例が複雑になるにつれて、重複するコードの量が増えていきます。インターフェイスとおそらくジェネリックを使用してそれが可能であるに違いないと確信していますが、エレガントなソリューションを考え出すのに苦労しています。

0 投票する
8 に答える
1219 参照

sql - SQLスクリプトでDRY(Do n't Repeat Yourself)をどのように適用しますか?

次のようないくつかの更新を含むスクリプトを使用してデータベース(Oracle)を変更しています。

この場合、DRY(Do n't Repeat Yourself)をどのように実施しますか?

私は特に、次の2つの繰り返し発生する問題を解決することに興味があります。

  • サブクエリを抽出するために、このスクリプトからのみ使用可能な関数を定義しますSELECT id FROM category WHERE code = 'ABC'

  • 一連の置換ルール(一般的なプログラミング言語のように見える可能性があります{"X_Y": "yx", "X_Z": "xz", ...})を作成し、それに対して単一の更新クエリを繰り返します。

ありがとう!

0 投票する
6 に答える
255 参照

coding-style - コード DRYer ツールはありますか?

私は大規模なコード ベースを持っており、あちこちに繰り返される、またはほぼ繰り返されるコードがたくさんあります。コードが取得できるのと同じくらい unDRY ですが、「重複」を追跡するのは難しいので、何かツールがあるかどうか疑問に思っていました。可能性のある DRYable コード (差分ツールやハミング距離アナライザーなど) を見つけるのに、言語固有の知識などは必要ありません。

では、このようなツールとしての手がかりはありますか?

0 投票する
6 に答える
991 参照

code-analysis - どの重複検出しきい値を使用していますか?

重複は悪であり、避けるべきであることに全員が同意します (同じことを繰り返すなという原則)。そのためには、Simian (多言語) やClone Detective (Visual Studio アドイン) などの静的解析コードを使用する必要があります。

Ayende の神戸に関する投稿を読んだところ、彼は次のように言っています。

神戸の8.5%はコピペコード。これは、感度を高く設定した場合です。しきい値を 3 に設定すると、私がよく行うように、12.5% まで上がります。

閾値としての 3 は非常に低いと思います。私の会社では、高品質のコード分析をサービスとして提供しています。重複のデフォルトのしきい値は 20 に設定されており、多くの重複があります。3にしてしまうと、お客様が修正など考えられないなんて想像もできません。

Kobe に関する Ayende の意見は理解できます。これは公式のサンプルであり、「Web 2.0 アプリケーションおよびサービスの計画、設計、および実装をガイドすることを目的としている」として販売されています。そのため、品質への期待は高いです。

しかし、あなたのプロジェクトでは、重複のためにどのような最小しきい値を使用していますか?

関連する質問 :コードの重複をどれだけ熱心に排除しますか?

0 投票する
2 に答える
329 参照

ruby-on-rails - Rails-2つのコントローラーまたはアクションの追加?

管理セクションと公開セクションを備えたWebアプリの設計。「インデックス」と「ショー」のためだけに公開されているコントローラーを持っているように感じますが、少し冗長です。私が読んだすべての提案は、adminの名前空間を示唆しています。これは問題ありません。「list_public」などの追加アクションを備えたコントローラーを1つ持つべきかどうか疑問に思います。

Railsは初めてなので、何も気にしないかもしれません。これらすべてのコントローラー、ビュー、同じ名前のヘルパーをプロジェクトディレクトリ全体に散らばらせるというアイデアは好きではありません。

誰かがこれについて何か洞察を持っていますか?前もって感謝します。