私の同僚は、私たちが一緒に取り組んでいるプロジェクトに新しい機能を実装していました。彼は、同じプロジェクトから同様の機能の実装を含むファイルを取得し、そのコピーを作成して、すべてのグローバル宣言の名前を変更し、実装。そのため、名前の変更を除けばほとんど同じである2つの大きなファイルになりました。
私は、プロジェクトの保守が難しくなることを説明しようとしましたが、彼はそのような方法でプログラミングする方が簡単であり、コードを修正する理由がない場合は修正する理由がないと言って、何も変更したくありません。壊れた」。
そのようなコードの重複は悪いことだとどうやって彼に納得させることができますか？
これはこの質問に関連していますが、私は技術者（別のプログラマー）を対象とした回答にもっと興味があります。たとえば、本のような信頼できる情報源への参照は素晴らしいでしょう。私はすでに簡単な議論を試みましたが、成功していません。
コードにバグを見つけたらどうするかを尋ねます。彼は今それを修正する必要がある場所はいくつありますか？
この質問に対する答えを彼に示すこともできます（コードの「コピーアンドペースト」が危険なのはなぜですか？）。
彼がコーヒーを欲しがっているときは、カップ全体ではなく、コーヒーポットから一度に一口ずつ飲ませてください。これは、彼がクリームと砂糖を加える場合に特に効果的です。これは、反復的なタスクが非常に面倒で面倒なことを示しているはずです（1つではなく20個のコードを修正するなど）。
次に、彼にこの投稿へのリンクを送信して、彼があなたの背中を持っている他のすべての人々を見ることができるようにします。
ここには2つのオプションがあります。
彼は単純にあまり経験がない合理的な人です。この場合、おそらくあなたのコード内の他の誰かのコード重複のより明確な例を彼に示すことによって、あなたはおそらくあなたの議論を合理化することができます。また、元のコピーにバグ（またはさらに良いことにいくつかのバグ）を見つけて、コードが壊れているので修正する必要があることを彼に伝えることもできます。
彼は頑固なお尻です：それならあなたは彼にエネルギーを無駄にすべきではありません。上司のところに行き、上司に面倒を見てもらいましょう。そんな人もいます。
最初のオプションの方が明らかに優れていますが、選択の余地がない場合もあります。そして、重要なクライアントが地球の反対側で叫び始めたために、最終的に午前3時にコードを維持する必要がある場合は、それは間違いなくあなたの問題であり、上司がそれを処理する必要があります。
そして最後に、上司があなたが間違っていると思った場合、あなたはおそらく間違った場所にいます。
彼にリファクタリングのコピーを渡してください。
彼が嫉妬に不満を感じるようにコードのバージョンを大幅に改善してから、「私のコードにリンクしたばかりの場合は...」と言ってください。
バグを見つけたら、2か所で変更する必要があるからです。新しい機能を追加する場合は、2か所に追加する必要があるためです。
あなたの同僚は、組織の長期的な有効性を犠牲にすることによって、彼の短期的な有効性を最適化しています（たとえば、残りの同僚と彼自身）。最初のファイルで必要な変更は、2番目のファイルでも必要になる可能性がありますが、誰も覚えていません...これにより、1回ではなく2回の検索と修正が行われます。
コードに対してクローン検出器を実行し、その結果をマネージャーに表示することができます。
リストについては、重複コードに関するWikipediaを参照してください。
CloneDR検出器を使用して、さまざまな言語のクローン検出のサンプルを確認できます。これは、一貫した名前変更でコードの大きなブロックを検出するように設計されており、何が起こったかを正確に示すことができます。
技術的な理由で上司にアピールします。上司があなたの同僚の方法に同意する場合、および/または上司にそれを修正させない場合、理由に訴えることがうまくいかない場合、あなたができることはほとんどありません。
それはあなたの友人に今これを直させることではありません。それはあなたのチームを成長させることです。
彼がチームとプロジェクトに不公平であることを彼に認識させます。それでも同意できない場合は、コーヒーを1杯飲んで、それをすすって座ってもらいます。その間、キーボードを持って、実際に彼の前のコードを修正することができます。
彼は恥ずかしくて、次回はそれをしないかもしれません（大勝利）。私はこれを4回使用しましたが、常に機能しています。
幸運を。
コードを複製しない正当な理由はたくさんありますが、質問してください...あなたのチームは10万行のコード（コードの複製あり）を維持したいですか、それとも5万行のコードを維持したいですか？この時点でのコードの重複は最小限に見えるかもしれません。そのため、同僚はDRYの概念の重要性を認識していませんが、今後5年間でコードの重複が増えるかどうか想像してみてください。誰がそのコードを維持するのですか？あなたのチーム？ある日仕事を辞めたらどうなりますか？あなたのチームはこのがらくたを維持したいですか？:)そうでない場合は、「重複が増える」=「将来的にバグが増える傾向がある」ことは言うまでもなく、コードを複製しないという非常に説得力のあるケースをすでに作成しています。
彼があなたより優れている（または監督している）場合は、より多くの説明を求めてください-コンテキストについてもっと知ることは可能です...おそらくコードをリファクタリングする価値はありません（おそらく小さなプロジェクトです）。
彼があなたと同等である場合、この解決策（より良い解決策）を提案することにより、あなたは上司に報告することができます。
あなたが彼より優れているなら、あなたのやり方をするように彼に「頼む」だけです...
アプリケーションがビジネスのどこに行くことができるかわからないことを彼に伝えてください...単純なテストアプリケーションは時々何度も変更され、最終的には頻繁に使用されることになります...私はこれを小さな会社でよく見ます。そして、以前は修正できたはずのことをやり直して時間を無駄にする代わりに、今は簡単に、短くて甘いものにすることができますが、それは...
彼はおそらくそれが壊れていないと思っていて、そうではないでしょう。また、完璧は善の敵です。彼はコピー/貼り付けの危険性に気づいていないと思います。彼はエラーの可能性についてあなたとは異なる評価をしているだけです。
おそらく、それがいかに簡単かを示すために、彼のためにそれを破ることができます。できない場合は、おそらく彼は正しいです。
まず、彼が正しいことを認めます。コピー＆ペーストは実際に高速になりました。
次に、問題は長期的にはコストであり、複製を行うとシステムの秩序が悪くなるため、コストが増加するとします。彼は無秩序、混乱をもたらしています、そしてあなたが持っている無秩序が多ければ多いほど、それはシステムで働くのが難しくなります。それをより良く組織化するために今、いくらかの努力を適用することは、（通常）長期的に見返りがあります。机や部屋を整理しておくようなものです。
これは、IvarJakobsonのソフトウェアエントロピーの考え方です。