タグ付けされた質問 「dry」

ユニットテストを書くときはいつでも、テストが失敗したときにデバッグを容易にするために、テストごとに1つのアサートをしようと常に試みてきました。しかし、この規則に従うと、各テストで同じコードを常にコピーしているように感じます。テストを増やすことで、読み取りと保守に戻るのが難しくなります。 シングルアサーションテストはDRYに違反していますか？ そして、メソッドごとに1つのテストを行うなど、良いバランスを見つけるために従うべき良いルールはありますか？* *私はおそらく、これに対するすべてのソリューションに適した1サイズではないことを認識していますが、これにアプローチする推奨方法はありますか？

12 testing  unit-testing  dry 

テストを書くことで自分自身を繰り返すことがなぜ非常に奨励されるのですか テストは基本的にコードと同じことを表しているため、コードの（概念ではなく、実装で）重複しているようです。DRYの最終的なターゲットには、すべてのテストコードの削除が含まれませんか？

11 testing  dry 

DRY Principle（Do n't Repeat Yourself）は、「すべての知識は、システム内で単一の明確な権威ある表現を持たなければならない」と述べています。ほとんどの場合、これはコードを指しますが、多くの場合、ドキュメントにも拡張されます。 すべてのソフトウェアシステムには、選択したかどうかに関係なくアーキテクチャがあると言われています。つまり、構築するソフトウェアには構造があり、その「構築された」構造がソフトウェアのアーキテクチャです。 構築されたソフトウェアシステムにはアーキテクチャが付属しているため、そのシステムのアーキテクチャ記述を作成することはDRY原則に違反していますか？ 結局のところ、アーキテクチャを知る必要がある場合は、常にコードを見ることができます...

11 agile  documentation  architecture  dry 

私は最近、コマンドとクエリメソッドの両方であるメソッドをリファクタリングしていました。 それを1つのコマンドメソッドと1つのクエリメソッドに分離した後、コマンドを呼び出してクエリから値を取得するコード内の複数の場所があり、これはDRYの原則に違反しているようです。 しかし、その一般的なコードをメソッドにラップすると、そのメソッドはコマンドとクエリの両方になります。これは受け入れられますか？

10 language-agnostic  refactoring  dry  cqrs 

オブジェクト指向言語（たとえば、Javaに限定されません）では、発生の範囲に応じて重複コードをどのように修正しますか？（例えば）から始めます 同じクラス（スコープ）でExtractメソッドのリファクタリングを実行（修正） 同じ階層のクラス（スコープ）でメソッドの抽出とプルアップを実行（修正） ...

10 object-oriented  dry 

現在、コーディングでこのDRY（Do n't Repeat Yourself）の概念に取り組んでいます。この関数を作成していますが、複雑になりすぎるのではないかと心配していますが、DRYの原則に従っています。 createTrajectoryFromPoint(A a,B b,C c,boolean doesSomething,boolean doesSomething2) 私が言ったこの関数は3つの入力パラメーターを取り、ブール関数の組み合わせdoesSomethingとを指定すると、関数は少し異なる動作をしdoesSomething2ます。しかし、私が抱えている問題は、このブール関数が追加されるたびに、この関数が非常に複雑になることです。 だから私の質問は、多くの同じロジックを共有するさまざまな関数（したがってDRYの原則に違反している）や、いくつかのパラメーターを指定した場合にわずかに異なる動作をするが、はるかに複雑にする1つの関数（しかし、 DRYを保存する）？

10 java  design  dry 

このアンチパターンの名前はどこかにあると思います。しかし、私はそれを知るためのアンチパターン文学に十分に精通していません。 次のシナリオを検討してください。 or0クラスのメンバー関数です。良くも悪くも、それはクラスメンバー変数に大きく依存しています。プログラマAがやってきて、をor0呼び出すのor0ではなく、クラス全体をコピーして名前を変更するような機能が必要です。私がor0言うように、それはその機能のためにメンバー変数に大きく依存しているので、彼女が呼び出さないと思います。または、彼女はジュニアプログラマであり、他のコードから呼び出す方法を知りません。これでor0、c0（コピーの場合はc）が得られました。私はこのアプローチでプログラマーAを完全に責めることはできません。全員が厳しい納期に直面し、コードをハッキングして作業を完了させます。 何人かのプログラマーがメンテナンスしているor0ので、バージョンになりorNます。 c0現在バージョンcNです。残念ながら、クラスを含むクラスを維持しているほとんどのプログラマーはor0完全に気付いていないようでしたc0-これは、DRY原理の知恵について私が考えることができる最も強力な議論の1つです。また、のコードの独立した保守もあった可能性がありますc。いずれにせよ、と思われるor0とc0、互いに独立して維持しました。そして、喜びと幸せ、エラーはで発生しcNていないのに発生していますorN。 だから私はいくつかの質問があります： 1.）このアンチパターンの名前はありますか？私はこれが起こるのを見たので、これが名前付きのアンチパターンではないと信じるのは難しいことがよくあります。 2.）私はいくつかの選択肢を見ることができます： a。）orN必要なすべてのメンバー変数の値を指定するパラメーターを取るように修正。次に、必要なすべてのパラメーターを渡しcNて呼び出すように変更しますorN。 b。）からorNに修正を手動で移植してみてくださいcN。（私はこれをしたくありませんが、現実的な可能性があります。） c。）orN-- cNagain、yuckに再度コピーしますが、完全を期すためにリストします。 d。）どこcNが壊れているかを把握し、とは独立して修復しorNます。 代替aは長期的には最良の修正のように見えますが、お客様がそれを実装することを許可するかどうかは疑問です。物事を正しく修正するために時間やお金を費やすことはありませんが、同じ問題を40または50回修復するための時間とお金は常に必要ですか。 誰かが私が考慮しなかったかもしれない他のアプローチを提案できますか？

10 terminology  anti-patterns  dry 

コードベースの抽象化が多すぎる（または少なくともそれを処理している）と感じている問題に直面しています。コードベースのほとんどのメソッドは、コードベースの最上位の親Aを取り込むように抽象化されていますが、この親の子Bには、これらのメソッドの一部のロジックに影響を与える新しい属性があります。問題は、入力がAに抽象化されているため、これらのメソッドでこれらの属性をチェックできないことです。もちろん、Aにはこの属性がありません。Bを異なる方法で処理する新しいメソッドを作成しようとすると、コードの重複のために呼び出されます。私の技術リーダーによる提案は、ブール型パラメーターを受け取る共有メソッドを作成することですが、これの問題は、これを「隠された制御フロー」と見なす人がいることです。 、また、この共有メソッドは、小さな属性に分割されたとしても、将来の属性を追加する必要がある場合、一度複雑になりすぎたり複雑になったりします。これはまた、カップリングを増やし、結束を減らし、チームの誰かが指摘した単一責任の原則に違反します。 基本的に、このコードベースの抽象化の多くはコードの重複を減らすのに役立ちますが、メソッドの拡張/変更が最高の抽象化を行うようになっている場合は難しくなります。このような状況ではどうすればよいですか？私は非難の中心にいますが、他の誰もが彼らが良いと思うことに同意することはできませんが、それは結局私を傷つけています。

9 object-oriented-design  class-design  abstraction  code-reuse  dry 

JavadocをDRYで記述したい。しかし、Javadocに関するOracleのドキュメントでは、オーバーロードメソッドのコメントに同じことを再度記述しています。繰り返しは避けられませんか？

9 documentation  comments  dry  javadocs 

これは私がしばらく行ったり来たりして検索して何も見つかりませんでした質問です：バックボーンのようなフレームワークを使用しているときに、Webアプリケーション用のJavascriptでドメインモデルを複製することに関して受け入れられているプラ​​クティスは何ですか？またはノックアウト？ サーバー側に一連のドメインモデルを持つ重要なサイズのWebアプリケーションがある場合、これらのモデルをWebアプリケーションに複製する必要がありますか（下部の例を参照）。または、動的な性質を使用してこれらのモデルをサーバーからロードする必要がありますか？ 私の考えでは、モデルを複製するための議論は、フィールドの検証を容易にし、存在すると予想されるフィールドが実際に存在することを保証することなどです。私のアプローチは、クライアント側のコードをほとんど別のアプリケーションのように扱い、些細なことをすることですそれ自体、データと複雑な操作（クライアント側にはないデータを必要とする）をサーバーに依存しています。クライアント側のコードをこのように扱うことは、ORMのエンティティとUIレイヤーのビューで使用されるモデルを分離することに似ていると思います。それらは同じフィールドを持ち、同じドメインの概念に関連しているかもしれませんが、それらは別個です事。 一方、サーバー側でこれらのモデルを複製することは、DRYの明らかな違反であり、クライアント側とサーバー側で異なる結果をもたらす可能性があるように思えます（一方が更新されても、もう一方は更新されません） ）。このDRYの違反を回避するには、JavaScriptのダイナミズムを使用して、必要なときにサーバーからフィールド名とデータを取得します。 それで、これらの状況で自分自身をいつ繰り返すか（そうでない場合）について、認められたガイドラインはありますか？または、これはプロジェクトと開発者に基づいた純粋に主観的なものですか？ 例 サーバー側モデル class M { int A DateTime B int C int D = (A*C) double SomeComplexCalculation = ServiceLayer.Call(); } クライアント側モデル function M(){ this.A = ko.observable(); this.B = ko.observable(); this.C = ko.observable(); this.D = function() { return A() * C(); } this.SomeComplexCalculation = ko.observalbe(); …

8 javascript  web-applications  dry 

ドライ原則は次のように述べています： 「すべての知識は、システム内で単一の明確な権威ある表現を持つ必要があります。」 ただし、コードのテストを作成するときは、システムの予想される動作を2回記述します（コードで1回、テストで1回）。私は両方の説明が異なる視点からのものであることを知っていますが、根本的なアイデアの多くを共有しています。 これについて何か考えはありますか？ 一般に、ユニットテストとDRYの原則はどちらも優れたアイデアであり、可能な限りそれらを適用しようとしています。この質問はもっと哲学的なレベルのものですが、誰かもこれについて考えているのではないかと思いました。

8 testing  dry