重複コードを受け入れることができる例外的なケースはありますか？

私は、3つのAPIを構築する必要があるソフトウェアプロジェクトに取り組んでいます。1つはホームバンキングチャネル用、もう1つは代理店チャネル用、3つ目はモバイルチャネル用です。

エージェンシーAPIは、すべての機能を備えているため、最も完成度の高いAPIです。

ここでのアーキテクトは、共通層（すべてのAPIで共有されるクロスチャネルEJBサービス）を作成しました。ただし、APIは異なります。

現在のところ、API間に大きな違いはありません。大きなチームはエージェンシーチャンネルから始まり、現在はホームチャンネルに適応しています。私たちは、単にホームアプリ専用のオブジェクトを強化しています。それ以外の場合、コードはAPI間で95％類似しています。APIはSpring MVCの上に構築されており、（コントローラー、モデル、およびいくつかのユーティリティ）があります。

基本的に、コントローラーはBOをChannelObject（これを行うのに適切な場所ではないようです）、およびいくつかの追加のユーティリティとシリアライザーへのマッピングBOを実行しています。今のところすべてが重複しています。重複の理由は、APIを独立させたいからだと言っています。「明日、私たちが代理店や携帯電話とは異なる行動を家庭で望むなら、私たちは苦労しません！」

重複コードを受け入れる必要がある場合はありますか？

複製が可能ではなく、このような理由のために、行うには正しいものになります。

「コードベースのこれらの3つの場所は、現在は同じですが、同じように振る舞わせたい」と言うことは、大規模な複製の正当な理由ではありません。この概念はすべてのシステムに適用でき、重複を正当化するために使用できますが、これは明らかに合理的ではありません。

重複は、それを削除することが他の何らかの理由で現在全体的により高価になる場合にのみ許容されるべきです（今のところ良いものを考えることはできませんが、1つが存在する可能性があります-プログラミングの事実上すべてはトレードオフではなくトレードオフです法律）。

あなたがしていることについて、正しい解決策は、たとえば、現在複製されている動作を戦略またはクラスとして動作をモデル化する他のパターンに抽出し、同じクラスの3つのインスタンスを使用することです。そうすれば、あなたはときか 3ヶ所のいずれかで動作を変更したい、あなただけの新しい戦略を作成して、一つの場所にそれをインスタンス化する必要があります。そうすれば、いくつかのクラスを追加するだけで、残りのコードベースはほとんど完全にそのままです。

サンディメッツ、Rubyの生態系で有名なソフトウェアエンジニアと著者は、偉大持ちのブログ記事や話、彼女はまた、重複や抽象化との関係について語っています。彼女は次の結論に達します

複製は間違った抽象化よりもはるかに安価です

そして、私は彼女に完全に同意します。この引用文の背景を詳しく説明します。適切な抽象化を見つけることは非常に難しい場合があります。このような場合にはそれだけのために行くたくなる任意の重複を減らすために抽象化。しかし、後であなたの抽象化がすべての場合に当てはまるわけではないことがわかるかもしれません。ただし、すべてを再度変更して別のルートに移動するのはコストがかかります（はるかに良い説明については、彼女の話を見てください！）。

そうです、私にとっては、特に今後の予定が不明で要件が変更される可能性がある場合に、複製を受け入れることが正しい決定である例外的なケースがあります。あなたの投稿から、私は現在多くの重複があると思いますが、あなたの同僚はこれが変わる可能性があり、両方のアプリケーションを互いに結合しないことを示唆しています。私の意見では、これは有効な議論であり、一般的に無視することはできません。

人々が「if tomorrow」という言葉でデザインについて推論を始める場合、これは多くの場合、私にとって大きな警告サインです。特に議論が余分な仕事と努力を含む決定を正当化するために使用される場合返済し、反対の決定よりも変更や復帰が難しい。

コードの複製は、短時間だけ労力を削減しますが、コードの複製行の数に比例して、ほぼすぐに保守作業を増加させます。また、コードが複製されると、これが間違った決定であることが判明したときに複製を削除するのが難しくなることに注意してください。間違った決定でした。

大規模な組織では、DRY原則よりもさまざまなチームの独立性を優先することが有益な場合があると述べました。API 2の95％の共通部分を抽出して重複を削除する場合、新しいコンポーネントが2つの独立したチームの結合につながる場合、これは最も賢明な決定ではないかもしれません。一方、リソースが限られていて、両方のAPIを保守しているチームが1つだけの場合、二重の努力を行わず、不必要なコードの重複を回避することが彼ら自身の利益になると確信しています。

さらに、「Home」および「Agency」APIが完全に異なるアプリケーションによって排他的に使用される場合、または「Home」コンテキストで使用できるAPIの上にコンポーネントビルドを作成しようとする場合、違いが生じることに注意してください「代理店」コンテキストのように。この状況では、APIの共通部分がまったく同じである（共通部分が複製されていない場合にのみ保証できます）ことにより、そのようなコンポーネントの開発がおそらくはるかに簡単になります。

したがって、実際には異なるサブチームが存在し、各サブチームが各APIを担当し、各チームが異なるスケジュールとリソースを持つ場合、「万が一の場合」ではなく、コードを複製するときです。

カップリングを防ぐための複製。2つの大きなシステムがあり、それらに同じライブラリを使用するように強制するとします。両方のシステムのリリースサイクルを結合している可能性があります。これはそれほど悪くないかもしれませんが、あるシステムが変更を導入する必要があるとしましょう。もう一方は変更を分析する必要があり、影響を受ける可能性があります。時々それは物事を壊すかもしれません。両者が変更を調整できたとしても、マネージャー、テスト、依存関係、小規模な自律チームの終わりを経て、多くの会議になる可能性があります。

そのため、自律性と独立性を得るために、重複したコードの代価を払っています。