コピー/貼り付けパターンを修正する方法は？

私が働いている場所では、人々（コンサルタント）はできるだけ早く機能をリリースするよう迫られています。そのため、物事を正しい方法で行う方法を考えたり、何かを壊したくないために時間をかけすぎたりする代わりに、コードは異なるモジュールからコピーされ、修正されます。

コードベースは会社全体に公開されているため、これを防ぐのは簡単ではありません。多くの人々がこれに取り組んでいます。

混乱がすでにあるので、あまりにも壊さずにそれらの冗長性を削除する最良の方法は何ですか？

答えの一部はリファクタリングです。

まず、ユニットテストの作成を開始して、変更内容を誤って壊さないようにします。その後、設計の改善、重複の削除などを小さなステップで開始し、各ステップの後にユニットテストを実行し、テストのいずれかが失敗した場合は問題を修正し、簡単に解決できないほど大きな問題が発生した場合はすぐに元に戻します。

他の部分は教育です。

人々は悪いコードを残さないように教えられなければなりません。これは確かに長期的な戦いです。習慣や思考プロセスを変えるのは難しい（時には不可能なこともある）からです。ただし、それなしでは、リファクタリングを行うために絶叫する悪いコードの無限の供給を得続けるでしょう。

グループコードレビューを行って、良いコーディング習慣と悪いコーディング習慣に関する議論を開始し、前者のメリットを広げることができます。「このようなコードを書かなければならない」と言うだけでは十分ではありません。論理と確固たる事実で人々を説得する必要があります。同様に、「あなたは方法のこの作品は、コードベースの上に重複している場合のn 倍を、あなたはチャンスはバグがその方法で発見された場合、それはメソッドのコードの各コピーに固定されることがあるかと思いますか？」

あなたの会社はまた、コンサルタントのインセンティブと受け入れ基準を修正する必要があるかもしれません-彼らがずさんなコードを書くことで逃げることができれば、彼らは確実により簡単な道を選び続けるでしょう。会社が長期的な保守性に関して「高速配信」を重視し続けている場合、何も変更されません。理解し、維持する。の省略のリファクタリングがあなたのクレジットカードに借金を集結のようなものです。あなたはしばらくそれで逃げることができます、しかしあなたがあなたの購入習慣と負債を積極的に管理していないならば、それは必然的にあなたの肩で崩れます。ソフトウェアプロジェクトの存続期間において、破産とはプロジェクトが保守不能になることです。既存のコードベースに新しい機能を追加するよりも、ゼロから書き直す方が簡単になります。または、ユーザーは劣ったレベルのサポートと機能にうんざりして、単に競争に切り替えます。

@Peterのような教育の一環として、PMDのようなコピー＆ペースト検出器を導入し、ビルドサイクルの一部として使用して、コーディング標準のこの部分を実施することができます。

プロジェクトのコーディング標準がこのパターンをカバーしていることを確認して、ディスカッションを開始するためのベースラインを用意してください。

人々（コンサルタント）は、できるだけ早く機能をリリースするよう迫られていると感じる

あなたには技術的な問題はなく、社会的な問題があります。実際、管理上の問題があります。

コードベースは会社全体に公開されているため、これを防ぐのは簡単ではありません。多くの人々がこれに取り組んでいます。

「コードベースは会社全体に公開されています」は問題ではありません。関係ありません。

重要なのは、コピーアンドペーストのための管理報酬システムがあることです。根本的な原因は、人々がコピーアンドペーストに対して報酬を与えられている（つまり、支払われている、賞賛されている、昇進または延長されている）ことです。

文化を「可能な限り迅速に機能をリリースする」から「適切で十分にテストされたコードベースの変更を行うことに対する報酬」に根本的に変更しない限り、これを破ることはできません。

必ず

1. 報酬を強化するマネージャーとともに、トップから始めます。現在のプラクティスを公開し、コストとリスクを文書化する必要があります。コストとリスクを削減する代替案を提案する必要があります。

2. その組織での残りの在職期間について、容赦なく文書化し、コストとリスクを明らかにする必要があります。容赦ない。事実ベース。コストとリスク。毎週、コピーアンドペーストによるコストとリスクが増大します。

3. あなたはマネージャーが彼らを良く見せ、あなたが無視される新しいアプローチを信用するのを助ける必要があります。

コピーアンドペーストを減らすことが非常に重要です。しかし、組織の文化を変えることは困難です。あなたは多くの事実を提供する必要があり、あなたはあなたに同意しないマネージャーに何度も何度も主張しなければなりません。

私はそれから腐り始めていたコードベースを今持っています。モジュールごとに10個以上の静的関数があり、それらは他のモジュールの同じ静的関数と基本的に同じでした。それぞれがただ振る舞った可能な限り迅速に物事を行うために、異なる、新しい化身を保証します。

今日、私はさらに別の機能を追加する必要があり、それ以上利用できませんでした。新しいライブラリを作成し、100 +関数をビットフラグに基づいて動作をわずかに変更する10個のリエントラント関数に組み合わせてから、一連のテストを作成して、そのライブラリへの変更が他に影響しないことを確認しました。

合計時間：4時間。必要に応じて20時間のマラソンに行く準備ができていたので、どんどん大きくなって混乱を抑えていたのに驚いた。ボーナスとして、一連のヘッダー依存関係の問題を後で修正する方が簡単でした。さらに、私たちの所有物の多くはリンク用の静的オブジェクトになっているため、以前よりも多くのソースコードにアクセスできる顧客を提供できます。

私のアドバイス：弾丸を噛んで、それが本当に悪くなる前に今混乱するリファクタリング。おそらくあなたが思うほど長くはかかりませんが、念のために新しいブランチを自分用に作成してください。

さらに、基本的な問題を修正しながら、コピー/貼り付けで機能を公開できます。完了したら、貼り付けたものをリッピングして、代わりに新しいライブラリを使用します。

これまでの回答に同意します。あなたがすべき：

• 単体テストを作成する
• リファクタリング
• 教育する
• コーディング標準に力を入れ、違反を検出する

しかし他方では、人々がコピーペーストをコピーして修正する原因を調べる必要があります。

• 多くの場合、コードは適切に再利用できない可能性があります
• 人々は彼らが使用できるライブラリがあることを知らないかもしれません
• ライブラリコードは十分に一般的ではない可能性があり、独自のバージョンを作成することは既存のライブラリを使用するよりもはるかに簡単です
• 適切なバージョン管理（ソース管理ではない）戦略が存在しない場合があり、汎用ライブラリを変更すると、他の多くのアプリケーションもテストされる可能性があります。

したがって、再利用を容易にするために必要なコピー/貼り付けパターンを停止すると思います。

• ライブラリを発見しやすく文書化する
• ライブラリをすべてから独立させる
• 適切なバージョン管理戦略を考える
• 後方互換性を確保する
• ライブラリの簡単な拡張性について考える

フレームワーク設計ガイドラインを読む

お役に立てれば。

「有害と見なされるコピーペースト」という強い態度があります。良いと思いますが、行き過ぎです。2つのメソッドまたはクラスの類似点と相違点を発見するための演習としてのコピーペースト- 三角測量プロセスのステップとして-私は健康だと思います。しかし、完全な三角測量（コピーペーストによって生じる重複を排除する）をやめることは、本当に有害です。

その微妙な態度を使用して、開発者に「それは悪いことではありません！」ではなく、「それは不完全です。リファクタリングを完了するために私と協力してもらえますか？」

私はここで同じ問題に関心があり、それに対する私の考え方は、それを前もって回避しようとせず、悪化しすぎた場合にリファクタリングすることです。

私が現在startetで作業しているモジュールは、別のモジュールのコピーとして、今では異なる必要があるものすべてを変更しています。これが完了し、新しいモジュールが完成したら、元のモジュールと比較し、どの部分が多かれ少なかれ変更されず、ライブラリ、抽象親クラスなどに移動する必要があるかを見つけます。

責任者は誰でも責任を負います。1人の人がすべてのコード行をレビューすることは期待できませんが、標準と時間枠を設定します。

請負業者（またはプロジェクトの短期的な人）は、最初に作業を行った場合にのみ報酬を受けるという立場に置くことができます。できるだけ早くそれを成し遂げるインセンティブがあります。コピーされたコードを変更する必要はないかもしれませんが、変更された場合は変更されません。

自分の時間に修正するように強制することもできます。その後、彼らは最初からそれを始めますが、それから物事を成し遂げるために時間の取るに足らない量を取ります。AmmoQには、問題を引き起こしているものをリファクタリングするという正しい考えがあると思います。

コピー/貼り付けコードを排除する唯一の方法は、（IMHO）コードレビューであり、コードをチェックする人（またはそれ以上）があり、コピー/貼り付けアクションに由来するコードを見つけた場合、プログラマーにリファクタリングを許可します。

提案されているように、これは主に組織の問題です。人々を教育することから始めてみてください（あなたの位置の上の直接管理層を忘れないでください）。電車に1人か2人乗せて、ウイルスを広めるのに非常に役立ちます。大多数がこれが良い考えだと思うとき、それを説明させて、それがこのようにとどまることを保証するためにレビューを紹介しようとします。これは非常に時間がかかる退屈なプロセスですが、すぐには変更できません。最初は余分な時間がかかりますので、経営陣が長期目標を知ってサポートすることが重要です。

@Anders K.レビューは、練習を適切に保つための良い手段です。人々にコードの記述を強制するとき、彼らはそれを信じないので、多くの摩擦が生じます。できる限り早く、彼らは古いハビットに戻ります。勢いをつけるには、教育から始めるべきだと固く信じています。