この記事は長い間私の仕事リストに載っていました。 しかし、今日になってようやく、それを実現する力と時間があるように思えます。 偶然かどうかはわかりませんが、最初の記事を最近公開したのと同じカフェにいます。 おそらく、彼らはここで提供される飲み物に何かを混ぜて...

それで何？ ひげを生やした、良いアドバイス-ベストプラクティスに従ってください？ 私たちは常にそれらについて耳にします。 DRYやKISSなどの短いニックネームも付け、技術的な会話のためにマシンで使用します。 私たちはこのコンセプトに夢中になっており、もし誰かが誤って、または単に無知からそれを遵守したくない場合、私たちは彼らに汚い批判のバケツを注ぎます。 私たちはこれらの信念の虜であり、適切なタイミングでそれらに背を向けることを拒否します。

もちろん、DRYのような原則が悪いことをほのめかしません。 これは間違いなくそうではありません。 状況次第だと思う。 強く。 DRYに関して、これは論理的な結論につながります。「実際、私は時々、抽象化ではなく、他の人を複製する傾向があります。」

はい、あなたはそれを正しく読みました。 コードの複製（コピーと貼り付けとも呼ばれます）は良い習慣です。 特に、コードの繰り返し部分を置き換える抽象化が、それを理解しようとすると痛いとき。

プログラマーの時間はどのように割り当てられますか

私が生計のために何をするかを人々に話すとき、私は一種の奇妙であるように思えます、私はキーボードを1日10時間以上叩きます。

私自身はすべてが順調であるとは確信していませんが、10時間連続してコードを記述しないと確信しています。 一番下の行は、プログラマーとして、 コードを書くのではなく、 コードを読むことに多くの時間を費やすということです。 あなたがこの種の情報に出会ったことがあるかどうかはわかりませんが、研究とロバートC.マーティンは、この種の活動にはある程度の割合があると主張しています。 そして、例えば、私は顕著な違いを見ます。 コードを書く1時間ごとに、コードを読むのに10時間 （自分のコードまたは他の人のコード）の時間があります。

これは非常に重要です。 1日の仕事に費やした努力は、主に読書に費やされます。 もちろん、コードを読むだけでは十分ではありません。 あなたはまだそれを理解する必要があります。 そしてこれは、明確で簡潔で読みやすいコードを作成するために、可能なすべてのことをしなければならないことを意味します。 これは、将来的に自分自身を含むすべての人にとって有益です。 後でこの考えに戻るので、これに留意してください。

DRYに関する注意

DRYという用語に慣れていない人にとっては、「自分自身を繰り返さないでください」という意味です。 このプログラミングの原則、または必要に応じて最高のテクニックは、各繰り返しコードの上に抽象化を作成することを提唱します。

DRYには多くの利点があります。 最初に、抽象化は、将来変更が必要になった場合、それらを1か所-抽象化自体で処理する必要があると言います。

別のモジュール、誰かのAPIなどの機能を吸収する インターフェース（または抽象化）がどのように見えるかだけを気にします。 基礎となる実装について心配する必要はありません。 したがって、インターフェイステンプレートなどのソフトウェアデザインテンプレートを使用すると、他のユーザーが使用する抽象化を妨げることなく、実装を簡単にリファクタリングできます。

したがって、抽象化は適切であり、DRYは完全に正当化されます。 次に、なぜいくつかのシナリオでコードをコピーすることを主張するのですか？

まあ、という理由だけで...

抽象化の価格

抽象化ごとに支払う必要があります。 すぐにコストを見積もることはできません。 しかし、時間が経つにつれて、彼らはポップアップします。

抽象化には、メタデータの追加レイヤーが含まれます。 メタデータ、その存在は、原則として、あなたには明らかでないかもしれません（特にあなたがそれを書いていない場合）。 新しい情報はそれぞれ、脳の認知的負荷を高めます。 そして、その結果、そのようなコードを読むのに費やす時間が増加します。

深いウサギの穴

DRYの問題とこの原則の狂信的な崇拝は、小さなプロジェクトでは目立ちません。 しかし、中規模および大規模で顕著です。

そのようなプロジェクトでは、コピーごとに抽象化が1つしかない場合は非常にまれです。 プロジェクトが開発され、新しい要件が現れると、古いコードは常に修正する必要があるためです。

そのようなシナリオを想像してください。 新しいプロジェクトに参加して、初めてコードを表示します。 構築方法に慣れ、すべてがどのように機能するかを理解したら、新しいオプションの実装、古いオプションの変更などを開始します。 既存のコードと抽象化を変更します。 このすべてを書いたわけではありませんが、それはそこにあります。 そして、これには、おそらく、非常に正当な理由があります。

サンディ・メッツが言ったように：

すでに記述されたコードには強力な権限があります。 その存在そのものが、その正しさと必要性を証明しています。

彼はあなたに彼に触れたくないようにします。

現在、新しい機能では、すでに存在する優れた抽象化を確実に使用できます。 しかし、結局のところ、抽象化には少し改良が必要です。 この特定のユーザーシナリオ用に設計されていません。 あなたがそれを少し変更することができれば...または、おそらく、追加の繰り返しロジックをカプセル化する既存の新しい抽象化の上に書いてください、m？ はい、それは正しい決断のようです！ それがDRYの意味です...

この狂気を絶対的な極限までもたらすことができる方法を明確に見ることができます。 すべてが抽象化でカプセル化されている極端な例。 そして、それらはさらに複雑な抽象化に包まれています。 そして無限に続く...

そのような場合、抽象化はその価値を失います。 私たちが盲目的に従うという信念のために存在します。 そして、それは抽象化を不正確にします。 私たちがそれを作成する機会を持っているからこそ存在します。

すでに述べたように、抽象化には脳に認知的負荷がかかります。 ほとんどの場合、解読に必要な障壁と時間を支払います（書き込みよりもコードの読み取りに多くの時間を費やしていることを思い出してください）。 しかし、誤った抽象化は、単なる抽象化よりもさらに悪いものです。

不正確な抽象化はボールであなたを打つだけでなく、彼らはまだ笑いながらその時曲がっています。

DRYitかどうか

重複コードをカプセル化する場合としない場合

答えは基本的に簡単です。 しかし、実用的な観点からは、まったく真実ではありません。 しかし、これには経験も伴います。

抽象化が重複コードよりもあなたにとって高価であることが判明しない場合は、常に抽象化します。

つまり、別のプロジェクト参加者があなたが書いた抽象化を理解しようとして何時間も費やしている場合、おそらく何か間違ったことをしていることになります。 これを行う能力があるからといって、抽象化を作成しないでください。 この特定の部分にコードが重複するかどうかを予測し、適切な決定を下します。

複製は、さまざまなメソッドのネストされた呼び出しのツリーをたどったり、渡されたパラメーターや可能な副作用などを追跡するよりも時間がかかりません。

自己防衛の最終的な考え方

この記事が「このDRYやその他のたわごとで地獄に！」と叫ばないことを願っています。 私は無条件にそれを良いプログラミングの原則と考えています。 しかし、それでも盲目的にそれに従わないことをお勧めします。 コンテキストで学習するすべてを考慮し、常にアイデアとアクションの妥当性に疑問を投げかけます。 これはプロ意識を向上させる唯一の合理的な方法です。

（ ナタリアベースによる翻訳）