参照されていないコードを削除する必要がありますか？
私は中規模（10万行）のコードベースに取り組んでいます。それはすべて比較的最近のコード（1年未満）であり、ユニットテストの範囲が十分です。
私は、どこでも使用されなくなったか、その特定のメソッドのみをテストする単体テストでのみ参照されるメソッドに遭遇し続けます。
不要になったことが確実な場合は、このコードを削除する必要がありますか？
削除する理由：
- 少ないコード、少ないバグ
- コードが少ないほど他の人が消化しやすくなります
- まだソース管理中です
それを保持する理由：
- 参考として使用できます
- いつか役に立つかもしれません
- クラスの機能を「丸める」ために作成された可能性があります
それを維持するあなたの理由のほとんどは完全に無関係です、簡単に言えば。コードを使用しない場合は、コードを破棄してください。コードを維持することに関する利点は、ソース管理から簡単に導き出すことができます。最大で、どのリビジョンを見つけるかをコメントで残してください。
簡単に言えば、コードをカットすればするほど、コードの保守、コンパイル、テストに時間を費やす必要がなくなります。これらの利点は、あなたが概説したささいな利点を大幅に上回っており、それらのすべてはとにかくソース管理から得ることができます。
それを削除する理由のすべてが立っています。
それを維持する理由：
- 参考として使用できます
- いつか役に立つかもしれません
- クラスの機能を「丸める」ために作成された可能性があります
それを維持するこれらの理由はすべて、ソース管理によって管理されます。ライブコードから削除すると、必要に応じて、必要なときに取得できます。
参照されていないコードは、トーチのために1日必要になった場合に備えて、バッテリーを少し平らに保つことと同じです。
なんらかのバージョン管理を使用している限り、それをライブコードからゴミ箱に捨て、有用であることが判明した場合に備えてバージョン管理の履歴を使用します。
現在使用されていないコードを保持するために私が見ることができる唯一の良い理由は、それが自己完結型モジュールの一部であるかどうかです：コードの一部は現時点では使用されていない可能性がありますが、将来的に使用されます。
これは、さまざまなプロジェクトで使用するライブラリに特に当てはまる可能性があります。特定のプロジェクトに必要なものに応じて、コードの断片を何度も出し入れしたくない場合：時間のかかるエラーが発生しやすいと思います。
私のアプローチは次のとおりです。（1）一度使用する場合は、本当に必要なものだけを保持してください。 （2）2回使用する場合は、2回目にそれをコピーして変更します。 （3）2回以上使用する場合は、明確で安定したモジュールを作成し、必要に応じてこのモジュールを使用します。
まとめ：それが設計した汎用モジュールの一部であり、何度か再利用することがわかっている場合を除き、未使用のコードはすべて破棄します。
注：もちろん、よりクリーンなソリューションは、ライブラリ用に個別のプロジェクトを作成し、プロジェクト間の依存関係を追加することです。
一般的に、私はこれについてYAGNIにお辞儀をします。 「必要ない」場合は、コードベース、ユニットテスト、アセンブリのスペースを占めるだけです。あなたはそれを必要とするかもしれませんが、今からあなたがそれのような何かを必要とするとき、多くのものが変わる可能性があるので、あなたはそれを完全に書き換える必要があるかもしれません。
ただし、一般的な使用を目的としたユーティリティまたはAPIを作成している場合は、多少異なります。ソフトウェアのエンドユーザーが意図した方法でソフトウェアと対話することを期待できないのと同じように、コードの利用者がコードを意図したとおりに使用することを期待することはできません。そのような場合、「オブジェクトとやり取りするのに有効な方法です」でメソッドの存在を正当化できる限り、それはおそらく入る必要があります。なぜなら、それが必要ない場合でも、可能性は高いでしょう。
コードベースが1年未満であることを考えると、おそらくまだ流動的です（はい？）-したがって、近いうちにいくつかのビットを復活させる必要があるかもしれないという考えは不合理ではありません。
そもそも正しく理解することが難しく、復活する可能性が高いと思われるビットについては、ソース管理よりも少し「ライブ」にしておくとよいでしょう。人々はそれらが存在することを知らない/覚えていない-「ソース管理でそれを見つけることができる」と言うことは、それがそこにあることを知っている/覚えていると仮定する！このような場合は、非推奨（ "assert（false）"ショートッパーを使用）またはコメント化することを検討してください。
「リファレンスとして使用できます」未使用のコードを残す正当な理由であることに同意する傾向はありません。多くの場合、未使用のコードのごく一部だけが実際に興味深いものを示しています。有用だが未使用のコードを文書化して保存する方法はいくつかあります。
バージョン管理には、後でコードが必要であると判断した場合に特定の機能を簡単に復元できる履歴が含まれますが、バージョン管理履歴を調べて、前のリビジョンが何であるかを知っているxyまたはzを見つける必要があることを知っています。少し面倒で、探しているものがかなり具体的な考えがない限り見過ごされがちです。
いつコードが削除されたのか、なぜ単にコードから削除されなかったのかについてのメモを付けて、コードをコメント化することができます。ただし、これは一般に悪いスタイルと見なされており、使用されておらず、適切に維持されていないコードは、後でコメントを外すとあらゆる種類のバグを引き起こす可能性があるため、リファクタリング中の一時的なデバッグ/テスト手順としては、製品コードを残す方法。
削除されたコードを保存するための私のお気に入りの方法は、将来役立つと思われる場合、価値のある削除されたコードのさまざまなチャンクをすべて含む2次参照ドキュメントを作成することです。コードの各ブロックには、それがどこから来たか、またはいつ削除されたか、コードの最後にあったリビジョン番号など、覚えておくべきことについての簡単な言及が付けられています。削除されたものの「潜在的に有用な」ものはすべて1か所にあり、簡単に検索できますが、継続的に保守およびテストするために常に努力する必要はありません（テストはコードが再導入された時点まで延期されます）。
コードが簡単で興味をそそらない場合は、ソフトウェアシステムの不要な慣性を取り除くためにコードを捨てます。
興味深いコードの死体については、バージョン管理システムでarchiveブランチを使用しています。
未使用のメソッドを保持する1つの理由は次のとおりです：これらは他のブランチ/タグで使用できます！
削除する前に、アクティブなブランチとタグをすべて調べてください。
私は比較的頻繁に、私が必要とする機能を正確に実行するように見える関数を見つけ、それが長い間製品化されているので機能することを信頼し、実際に使用されていないことを知るだけの経験があります数年。使用されていないコードは維持されず、何年も前に機能していたかもしれませんが、その周りのAPIは十分に変更されており、信頼できません。
せいぜい、あなたは多くの時間を費やして、実際にそれがあなたの望むことを実際に果たしていることを確認することになります。最悪の場合、後で厄介なバグに噛まれるまで機能し、「本番テスト済み」のコードが機能すると想定して問題が新しいコードの別の場所にあると想定しているため、追跡に時間がかかります。私の経験では、ほとんどの場合、自分で新しい関数を書くだけの方が速いです。
削除しても、実際に必要になる比較的すぐにわかる場合は、ソース管理にあります。それがソース管理にあることを覚えていないほど長い時間が経過するまでそれが必要ない場合は、とにかく最初からそれを書く方が良いでしょう。
何もコードがないほど時間を消費しません。
コードベースに飛び込む必要がある場合は、そのコードが何のために使用されているのかを理解するための時間が必要です。また、何も使用されない場合は、さらに時間が必要です。
わかりました-これはコメントで修復できますが、削除する必要があるかどうかにかかわらず、誰もがこの未使用のコードがコードベースに残っている理由を説明します。
何もなければ、誰もそれで時間を失うことはありません。
正しく理解するのが難しい場合は、このコードが存在することを示す適切なドキュメントが必要ですが、コードベースがいくつかの反復で進化する場合、再アクティブ化すると機能しなくなる可能性があります。
未使用のコードを削除します-混乱を減らし、理解を深めます。あなたのバージョン管理システムが面倒を見ます。また、メモ帳よりも優れたものを使用している場合、ご使用の環境では参照用に古いコードを使用できます。
古いコードの長いコメントは混乱を招き、ナビゲートを困難にします。
よろしく
この単純なアルゴリズムに従ってください：
- SCMでバックアップされていますか？はいの場合は、3に進みます。
- SCMをセットアップします。
- ものを捨てる。
削除を支持するすべてのポイントは有効です。
SCMでそれを調べたり復元したりすると、混乱を避けるためのすべてのポイントが無効になります。実際、SCMは、コードが適切に使用されている場合、そのコードがここにあり、使用されていない理由を特定するのに役立つはずです。
理由により「デッドコード」と呼ばれています。死なせて、安らかに眠らせてください。
バージョン管理システムを使用している場合は、コードの履歴を確認して削除された部分を見つけるだけなので、将来の参照について心配する必要はありません。そうでなく、いつか使用されると思われる場合は、そのままにしておいてください。ただし、コメントされた理由を説明する説明を付けてコメントするにします。
ただし、今後使用しないことが確実な場合は、単純に削除します。あなたが言及した理由は、コードが削除されるのは非常に簡単だと思います。
ただし、削除する前に、使用されていないことを確認してください。 Visual StudioにはFind All Referencesという機能があり、ソリューション全体を検索して、現在の変数、メソッド、プロパティ、クラス、インターフェイスなどへの参照を見つけます。参照が設定されていないことを常に確認しますコードの一部を削除する前に。
私の経験では、未使用のコードを削除すると、逆効果になる可能性もあります。あなたはそのコードがあったことを忘れるかもしれませんし、歴史の中でそれを探すことはありません。または、誰かがそのコードを実装して後で削除したことさえ知らないかもしれません。繰り返しますが、履歴でそれを探すことはありません...
間違いなく、未使用のコードは悪臭です。
PDATE： Ed Staubが非常によく似た答えを出したことに気づきました。
ソース管理にとどまります。アクティブなコードベースに留まってはいけません。
1つの例外は、コードがデザインを完成させ、コードを使用していないときに、最終的にコードを公開することを計画している場合で、他の人がその基本的な機能を必要とする場合があります。次に、テストを設計して、他の人がコードのこれらの部分を使用することを提案する方法を模倣するコードのこれらの部分が機能することを確認します。ただし、コードの削除を検討していて、コードを保持する確かな理由が見つからない場合は、それで問題ありません。未使用のコードは、誰にとってもより多くの作業になります（コードを読み取るのが難しくなります。コードが壊れる可能性があります。維持するための作業が増えるなど）。