コードの再利用とコピー/貼り付けのベストプラクティスは何ですか？
再利用の問題は、再利用されたコードを変更すると、他の多くの機能に影響を与える可能性があることです。
これは良いことと悪いことです。変更がバグ修正または有用な拡張である場合は良いです。古いバージョンに依存していた（または新しいバージョンにバグがある）ために、他の再利用コードが予期せず壊れた場合は問題があります。
場合によっては、コピー/貼り付けの方が優れているように思われます。貼り付けたコードの各ユーザーは、結果なしにカスタマイズできるプライベートコピーを持っています。
この問題のベストプラクティスはありますか。再利用には防水ユニットテストが必要ですか？
コードのすべての行にはコストがかかります。
調査によると、コストはコードの行数に比例せず、指数関数的です。
コピー/貼り付けプログラミングは、ソフトウェアを再利用するための最も費用のかかる方法です。
「再利用には防水ユニットテストが必要ですか？」
いいえ。
すべてのコードには、適切な単体テストが必要です。すべてのコードは再利用の候補です。
複数の場所で使用され、ある場所では変更される可能性があり、別の場所では変更されない可能性があるコードは、スコープの適切な規則に従っていないように思えます。2 つの異なる機能を実行するために「同じ」メソッド/クラスが必要な場合は、そのメソッド/クラスを分割する必要があります。
コピー/貼り付けしないでください。1 か所のコードを変更する必要があることが判明した場合は、おそらく継承、オーバーロード、または必要に応じてコピー アンド ペーストを使用して、コードを拡張できます。ただし、類似のセグメントをコピーして貼り付けることから始めないでください。
コピー アンド ペーストを使用することは、ほとんどの場合、悪い考えです。あなたが言ったように、何かを壊した場合に備えてチェックするテストを行うことができます。
要点は、メソッドを呼び出すときは、メソッドがどのように機能するかではなく、メソッドが何を行うかを気にする必要があるということです。メソッドを変更して動作を変更する場合は、新しいメソッドにするか、このメソッドが呼び出された場所を確認する必要があります。
一方、変更によってメソッドが行うこと (方法のみ) が変更されない場合は、他の場所で問題が発生することはありません。もしそうなら、あなたは何か悪いことをしました...
コピー アンド ペーストの非常に適切な使用法の 1 つは、三角測量です。あるケースのコードを書き、いくつかのバリエーションを持つ 2 番目のアプリケーションを確認し、コピーして新しいコンテキストに貼り付けますが、これで終わりではありません。そこで止まってしまうと大変なことになります。このコードを複製すると、おそらくわずかな変更を加えるだけで、コードに必要ないくつかの共通機能が明らかになります。両方の場所でテストされ、両方の場所で動作するようになったら、その共通点を 1 つの場所に抽出し、元の 2 つの場所から呼び出して、(もちろん) 再テストする必要があります。
複数の場所から呼び出されるコードが脆弱性のリスクをもたらすという懸念がある場合は、関数が十分に細分化されていない可能性があります。過度に粗粒度の関数、機能が多すぎる関数は、再利用が難しく、名前を付けるのもデバッグするのも困難です。機能のアトミック ビットを見つけて名前を付け、再利用します。
コピー/貼り付けは、機能の相違につながります。コードは最初は同じかもしれませんが、時間の経過とともに、1 つのコピーの変更が他のすべてのコピーに反映されないことがあります。
また、非常に単純なケースではコピー/貼り付けは「OK」に見えるかもしれませんが、プログラマーはコピー/貼り付けが問題ないという考え方に陥り始めます。それが「つるつる坂」です。プログラマーは、リファクタリングが適切なアプローチである必要があるときに、コピー/貼り付けを使用し始めます。前例を設定し、将来の開発者に送信するシグナルについて常に注意する必要があります。
私よりも経験豊富な人からの引用もありますが、
「コーディング中にコピー アンド ペーストを使用すると、おそらく設計エラーを犯している可能性があります。」
-- デビッド・パーナス
コピーと貼り付けは決して良い習慣ではありません。かなり質の悪いコードベースでの短期的な修正の方が良いように思える場合もありますが、適切に設計されたコードベースでは、次のようにして簡単に再利用できます。
コードベースがこれらの特性を示している場合、コピーと貼り付けは決して良い選択肢とは思えません。そして、S Lott が言うように、コードベースのサイズを不必要に大きくすると、莫大なコストがかかります。
この問題のベスト プラクティスはありますか。再利用には防水単体テストが必要ですか?
はい、はい。すでに一度正しく実行したコードを書き直すことは、決して良い考えではありません。コードを再利用せずに書き直すと、バグが倍増します。多くのベスト プラクティス タイプの質問と同様に、Code Completeによって私の仕事のやり方が変わりました。はい、能力を最大限に発揮して単体テストを行い、コードを再利用してCode Completeのコピーを入手すれば、準備は完了です。
したがって、消費者 (再利用者) コードは再利用されたコードに依存しています。その通りです。
この依存関係を管理する必要があります。
これは、バイナリの再利用 (例: dll) とコードの再利用 (例: スクリプト ライブラリ) にも当てはまります。
コンシューマーは、再利用されたコード/バイナリの特定の (既知の) バージョンに依存する必要があります。
消費者は、再利用されたコード/バイナリのコピーを保持する必要がありますが、直接変更してはならず、安全な場合にのみ新しいバージョンに更新してください。
再利用されたコードベースを変更するときは、慎重に検討してください。重大な変更のためのブランチ。
Consumer が再利用されたコード/バイナリを更新したい場合、最初にそれが安全かどうかをテストする必要があります。テストが失敗した場合、Consumer は常に最新の既知の (そして保持されている) 正常なバージョンにフォールバックできます。
したがって、再利用の恩恵を受けることができ (たとえば、1 か所のバグを修正する必要があります)、それでも変更を制御できます。しかし、再利用されたコード/バイナリを更新するたびに、テストから逃れることはできません。
単体テストを作成する必要があります。もちろん、コードのクローンを作成することで、変更が他の多数のルーチンに影響を与えていないという安心感を得ることができますが、それはおそらく誤った安心感です。基本的に、あなたの安心感は、コードがどのように使用されているかを知らないことから生まれます。(ここでの無知は軽蔑的なものではなく、コードベースに関するすべてを知ることができない結果として生じます) コードがどこで使用されているかを知るために IDE を使用することに慣れ、コードを読んでその方法を知ることに慣れてください。使用されています。
あなたが書く場所：
再利用の問題は、再利用されたコードを変更すると、他の多くの機能に影響を与える可能性があることです。...場合によっては、コピー/貼り付けの方が良いように思われる場合があります-貼り付けられたコードの各ユーザーには、結果なしにカスタマイズできるプライベートコピーがあります。
コピペに関する懸念を覆したと思います。コードを 10 か所にコピーした後で動作を少し変更する必要がある場合、10 か所すべてを変更することを覚えていますか?
残念なことに、私は大量の大きくずさんなコードベースに取り組んできましたが、一般的に、同じ 4 行のコードの 20 バージョンという結果が表示されます。それらの一部 (通常は小さな) サブセットには 1 つの小さな変更があり、他のいくつかの小さな (部分的に交差するサブセットのみ) には他の小さな変更があります。これは、バリエーションが正しいからではなく、コードが 20 回コピーされて貼り付けられ、ほとんど変更が適用されたためです。 、しかし完全に一貫しているわけではありません。
その時点に到達すると、これらのバリエーションのどれが理由で存在し、どれが間違いのために存在するかを判断することはほとんど不可能です (そして、多くの場合、省略の間違い - 何かを変更するのではなく、パッチを適用するのを忘れる - があるためです。証拠やコメントではない可能性があります)。
別の機能が必要な場合は、別の関数を呼び出します。同じ機能が必要な場合は、あなたをフォローする人の正気を保つために、コピペは避けてください。
コードを測定するために使用できるメトリックがあり、適切なしきい値を決定するのはユーザー (または開発チーム) 次第です。Ruby on Rails には「Metric-Fu」Gem があり、コードをリファクタリングして最高の状態に保つのに役立つ多くのツールが組み込まれています。
他の言語で利用できるツールはわかりませんが、.NET 用のツールはあると思います。
一般に、コピー アンド ペーストはよくありません。ただし、他の規則と同様に、これには例外があります。例外はルールよりもよく知られていないため、私見で重要なものを強調します。
デザイン パターンや OO を使用して複雑にしたくないものに対して、非常にシンプルなデザインを使用している。2 つまたは 3 つのケースが無数の微妙な方法で異なります。つまり、ここに線があり、あちらに線があります。問題の性質から、2 つまたは 3 つ以上のケースが発生する可能性は低いことがわかっています。このような比較的単純な問題を解決するために徹底的に設計するよりも、カット アンド ペーストする方が 2 つの悪のうち小さい方である場合があります。コード量にはコストがかかりますが、概念の複雑さも同様です。
今のところ非常によく似たコードがいくつかありますが、プロジェクトは急速に進化しており、2 つのインスタンスが時間の経過とともに大幅に分岐し、共通であり続ける機能のかなり大きく因数分解可能なチャンクを特定しようとする点にまで達すると予想されます。これらを再利用可能なコンポーネントにリファクタリングするだけでは、その価値よりも多くの問題が発生します。これは、1 つのインスタンスに異なる変更が加えられる可能性が、共通の機能に変更が加えられる可能性よりもはるかに高いと考えられる場合に適用されます。