問題タブ [code-duplication]

最近、いくつかのレガシー コードのリファクタリングを開始し、座標グリッドを描画するための 2 つの関数に出くわしました。問題は、これらの関数が扱う直交変数のみが異なることです。

したがって、アンチエイリアシングや単に描画鉛筆を変更するなどの派手なものを追加することにした場合、それらの両方に同じコードを配置する必要があり、それはコードの重複であり、その理由は誰もが知っています。

私の質問は、この問題を回避するために、これら 2 つの関数を 1 つの関数にどのように書き直しますか?

多くの場合、ユーザー インデックスのプロパティまたは一部のデータの一連のインデックスを持つビジネス オブジェクトを使用します。このオブジェクトをフォームまたはその他のビューに表示する場合、ユーザーのフルネームまたはデータのその他のプロパティが必要です。通常、別のクラス myObjectView などを作成します。このケースを処理する最善の方法は何ですか?

さらに明確にするために: クラスに課題トラッカーがあり、課題のクラスにプロパティとして IxCreatedByUser と IxAttachment 値のコレクション (添付ファイル レコードのインデックス) があるとします。これを Web ページに表示するときに、IxCreatedByUser の代わりに John Doe を表示し、ページに添付ファイルとファイル名へのリンクを表示したいと考えています。そのため、通常は、Attachment オブジェクトの Collection と CreatedByUserFullName プロパティなどを使用して新しいクラスを作成します。ページにデータを表示するためにこの 2 番目のクラスを作成するのは間違っているように感じます。おそらく私は間違っていますか？

class X内部メンバーへのアクセスを返したい場合、次のようなものがあるとします。

2 つのメンバー関数X::Z()とX::Z() const中括弧内のコードは同じです。これはコードの重複であり、複雑なロジックを持つ長い関数ではメンテナンスの問題が発生する可能性があります。

このコードの重複を避ける方法はありますか?

少し前にいくつかの単体テストを台無しにして、それらをよりDRYにするためにリファクタリングしました。各テストの意図はもはや明確ではありませんでした。テストの可読性と保守性の間にはトレードオフがあるようです。重複したコードを単体テストに残しておくと、読みやすくなりますが、SUTを変更すると、重複したコードの各コピーを追跡して変更する必要があります。

このトレードオフが存在することに同意しますか? もしそうなら、あなたのテストが読みやすいものであること、または保守可能であることのどちらを好みますか?

かなり大きなコード ベース (C++ の 400K LOC) があり、コードの重複が問題になっています。重複したコード ブロックを効果的に検出できるツールはありますか?

理想的には、これは開発者が時々実行して問題の場所を確認するのではなく、開発中に使用できるものです。また、そのようなツールを CruiseControl と統合して、チェックインごとにレポートを提供できるとよいでしょう。

少し前にDuplocを見たことがありますが、グラフはきれいでしたが、それを使用するには smalltalk 環境が必要で、自動的に実行するのはかなり困難でした。

無料のツールもいいですが、商用の優れたツールがあれば興味があります。

私の質問では、「モックイスト」TDD プラクティショナーとして、テスト対象のメソッドと同じクラスの他のメソッドをモックする必要がありますか? Avdi 氏は、「個人的には、自分自身を嘲笑することは、ほとんどの場合、コードの匂いだと思います。それは、動作ではなく実装をテストすることです」と答えました。彼は正しいかもしれませんが、多くの場合、実装と動作を区別できません。

役立つ答えにつながる可能性のある別の例 (Python スタイルの疑似コード) があります。

ここでの考え方は、get_components_from_spec_file コンポーネント クラス メソッドがコンポーネントのリストを読み取るファイルへのパスを取得するために、get_components メソッドが spec_filepath メソッドを呼び出すというものです。次に、spec_filepath メソッドが spec_dirpath を呼び出します。spec_dirpath は、スペック ファイルを含むディレクトリを VCS システムから同期し、そのディレクトリへのパスを返します。(このコードのバグを探さないようにしてください。結局のところ、これは疑似コードです。)

これらのメソッドをテストする方法についてのアドバイスを探しています...

spec_dirpath のテストは非常に簡単です。VCS クラスをモックし、モック オブジェクトを返して、適切なメソッドが呼び出されていることを確認します (そして、spec_dirpath メソッドがモックの dirpath メソッドが返すものを返すことを確認します)。

しかし、spec_filepath のテスト中に spec_dirpath をモックしない場合、spec_filepath テストで spec_dirpath コードから同じテスト コードを複製しないようにするにはどうすればよいでしょうか? また、get_components のテスト中に spec_filepath をモックしない場合、spec_filepathとspec_dirpath の両方からテスト コードが重複しないようにするにはどうすればよいでしょうか?

C# で正確で柔軟かつ高速な Equalsを実装する最善の方法について考えてみました。パフォーマンスのためには、特殊な Equals (実際のクラスのオブジェクトをパラメーターとして受け取る) が必要であると考えました。コードの重複を避けるために、一般的な Equals は特殊化された Equals を呼び出す必要があります。継承されたクラスであっても、null チェックは 1 回だけ実行する必要があります。

私は最終的にこのデザインを思いつきました：

重要なアイデア:

• 「as」演算子の使用。このようにして、一般的な Equals で null をチェックする必要がなくなります。間違ったクラス タイプは null に縮小され、特殊化された Equals に分類されます。
• 派生クラスであっても、正確に 1 点で Null チェックを行います。
• 属性を次々に確認すると、明確な構造が得られます。

この概念に欠陥はありますか、それとも条件を逃しましたか?

コードの重複を減らす/回避するようにコードを構成しようとしていますが、興味深い問題に遭遇しました。コードがストアド プロシージャを呼び出すたびに、ユーザー名、ドメイン、server_ip、client_ip など、ストアド プロシージャに共通のいくつかの変数を渡す必要があります。これらはすべて HttpRequest オブジェクトまたは system.environment オブジェクトから取得されます。

これらはすべてのストアド プロシージャに渡されるため、最初に考えたのは、データベース ラッパーであり、これらを毎回初期化して渡すユーティリティ クラスを作成することでした。そのため、コードでそれを行う必要はありません。問題は、c# クラス (App_Code フォルダー内) が Httprequest オブジェクトを認識しないことです。もちろん、これを引数としてラッパーに渡すこともできますが、それではラッパーを作成する目的全体が無効になります。ここで何か不足していますか？

ストアド プロシージャを呼び出すたびに 4 行のコードを繰り返すのは大したことではないことはわかっていますが、非常に早い段階でコードの重複を排除したいと考えています。

私は、どこにでもコードが重複しており、明らかにリファクタリングが必要な、本当のネズミの巣である研究コードをいくつか持っています。ただし、テーマの新しいバリエーションを考え出し、それらをコードベースに適合させるにつれて、コードベースは進化しています。私がリファクタリングをこれほど長く先延ばしにしてきた理由は、良い抽象化を考え出すのに数日を費やした瞬間、どのデザインパターンがどこに適合するかを確認するなど、新しい予期せぬアイデアを試してみたいと思うからです。私の抽象化は完全に不十分になります。言い換えれば、コードが進化する速度のせいで、(おおよその) 重複が不足することはなく、コードの一般的な乱雑さにより、何かを追加することが現実的になっているにもかかわらず、抽象化の行がどこに属するのか、私にはまったくわかりません。痛み。