参照されていないコードを削除する必要がありますか?


118

私は中規模(10万行)のコードベースに取り組んでいます。それはすべて比較的新しいコード(1年未満)であり、ユニットテストのカバレッジが良好です。

どこでも使用されなくなったメソッドや、特定のメソッドのみをテストする単体テストでのみ参照されているメソッドに出くわします。

不要になったことが確実な場合、このコードを削除する必要がありますか?

削除する理由:

  • 少ないコード、少ないバグ
  • 他の人にとってはコードが少ないほど消化しやすい
  • まだソース管理下にあります

維持する理由:

  • 参照として使用できます
  • いつか役に立つかもしれません
  • クラスの機能を「概算」するために作成された可能性があります

22
「より少ないコード、バグも少ないが、」 -彼らは本当に決して使用されない場合、彼らはバグが発生する可能性は低い
コンラートMorawski

19
@Morawskiしかし、それが残っている場合、いつか使用されます。また、メンテナンスされていないため、バグが発生し、バグが表示されます。
DJClayworth

9
私は通常、コメントとそれに依存するテストをコメントアウトしてから、日付とともに「TODO」コメントを残します。それが一年間使われないと、私はそれをチャックします。他の人は今すぐそれを削除することをお勧めしますが、特にコードがかつて有用だったように見える場合、私はそれを行うのが難しいと思います。
ジョブ

31
@Jobコメントアウトされたコードに出くわした場合、削除されます。言い訳しない。コメントアウトされたコードは、「ソース管理システムを信用していない」と叫ぶだけです。私に。
クリストフプロボスト

26
@Kristof Provost、有用なコードがソースファイルAに存在していなかった場合、それがソースファイルAにあったことをどのようにして知るのでしょうか?もちろん、いつでもファイルの履歴を確認できますが、どのくらいの頻度で自分自身に思いますか:「うーん...ここで機能を変更/実装する必要があります。または、5年間の動作をテストする必要がありますすぐに。誰もがすでにそれを実装していて、それを削除したのだろうか...歴史を確認させてください。」厄介ながらくたを保持することを推奨していませんが、実稼働環境でコードを使用していないが、デバッグなどのためにコードを使用する必要がある場合があります。
ジョブ

回答:


219

それを維持する理由のほとんどは、まったく無関係です。コードが使用されていない場合は、捨ててください-コードを保持することに伴う利点は、ソース管理から簡単に導き出すことができます。せいぜい、どのリビジョンで見つけるかというコメントを残してください。

簡単に言えば、コードを早くカットすればするほど、コードの維持、コンパイル、テストに時間を浪費する必要がなくなります。これらの利点は、概要を説明したささいな利点を大きく上回り、いずれもソース管理から派生する可能性があります。


30
私はそれを削除することに同意しますが、誰かがリフレクションを介して「未使用」コードを使用しているために何かを破った場合があります。とにかく注意する必要があります。
ファルコン

14
@Falcon、それは、人々がそれを使い始める前に、またはそれを公開する必要性を発見する前に、できるだけ早くそれを削除する正当な理由です。
StuperUser

6
@Falcon:コードが未使用であるというOPの主張です。
-DeadMG

4
@StuperUser:まったく同感です。しかし、注意して予期しない事態に備える必要があります。
ファルコン

18
それを削除し、単体テストと回帰テストに合格しても製品がフィールドで破損する場合、何らかのタイプのコードカバレッジツールを設定する強力なケースになります。
アンドリューTフィンネル

43

それを取り除く理由はすべて立っています。

維持する理由:

  • 参照として使用できます
  • いつか役に立つかもしれません
  • クラスの機能を「概算」するために作成された可能性があります

これらを保持する理由はすべて、ソース管理によって管理されます。ライブコードから削除すると、必要に応じて取得できます。


1
はい、参照されていないコードはライブコードに残すべきではありません。
-xdazz

大きなチャンクをコメントアウトするだけで、これらのメリットも得られるようです。
スティーブベネット

@SteveBennett確かに、あなたはこの答えの要点を誤解しています。コメントしておくことの利点をリストしますが、ポイントは、これらすべてのほか、ソース管理からさらに多くの利点が得られることです(他の回答で確認できます)。
StuperUser

私は確かにVCSに反対ではありません。:)(ただし、現在のバージョンからコンテンツが削除されると、参照されていないテキストファイル、Wiki、コメントなどに保存するなど、他のアプローチよりも見えにくくなることに注意してください)
Steve Bennett

@Steve Bennet-ファイルの現在のバージョンのコメントより「見えにくい」かもしれませんが、単一のファイルのVCS履歴を確認するのは簡単で、txt-file / wiki / etcよりもはるかに簡単です。 ..アプローチ。
ザックリゾービー14年

23

参照されていないコードは、トーチでいつか必要になる場合に備えて、ちょっとしたバッテリーを平らに保つのと同じです。

何らかの種類のバージョン管理を使用している限り、それをライブコードから削除し、有用であることが判明した場合に備えてバージョン管理履歴を使用します。


40
類推を少し改善するには、「使用済みだが未使用のバッテリーではない」というラベルの付いた保管室の新しいバッテリーの隣のボックスに入れるのではなく、リモコンにテープをテープで留めておきます。
スコットホイットロック

プラス1を使用すると、大幅に改善されます。
ニコラススミス

15

現在使用されていないコードを保持することができる唯一の正当な理由は、それが自己完結型モジュールの一部である場合です:コードの一部は現時点では使用されていないかもしれませんが、将来的に使用されます。

これは、さまざまなプロジェクトで使用するライブラリの場合に特に当てはまります。特定のプロジェクトに必要なものに応じて、コードの断片を出し入れし続けたくない場合があります。

私のアプローチは次のとおりです。(1)一度使用した場合、本当に必要なものだけを保持する。(2)2回使用する場合は、2回目の使用時にコピーして適用します。(3)2回以上使用する場合は、明確に定義された安定したモジュールを作成し、必要に応じてこのモジュールを使用します。

要約:使用目的で設計した汎用モジュールの一部であり、何度か再利用することがわかっている場合を除き、未使用のコードはすべて破棄します。

:もちろん、さらにクリーンなソリューションは、ライブラリー用に別個のプロジェクトを作成し、プロジェクト間に依存関係を追加することです。


1
この例として、バイト配列内でさまざまなサイズの符号付きおよび符号なしデータ型を読み書きするライブラリルーチンがいくつかあります。現時点で必要なコードに基づいて、存在するものと存在しないものを用意するよりも、すべてのデータ型に対してそのようなルーチンのセットを用意する方がきれいに思えます。
-supercat

11

一般的に、私はこれについてYAGNIに頭を下げます。「必要ない」場合は、コードベース、単体テスト、およびアセンブリのスペースを占有するだけです。あなたはそれを必要とするかもしれませんが、今からあなたがそのような何かを必要とするとき、多くが変わる可能性があるので、あなたはそれを完全に書き直す必要があるかもしれません。

ただし、一般的な使用を目的としたユーティリティまたはAPIを作成している場合は、多少変更されます。ソフトウェアのエンドユーザーが意図した方法でソフトウェアとやり取りすることを期待できないのと同様に、コードの消費者が自分の考えているとおりにコードを使用したいと思うことは決してありません。そのような場合、メソッドの存在を「私のオブジェクトとやり取りするのに有効な方法」と正当化できる限り、おそらくそれが入ってくるはずです。 。


8

コードベースが1年未満であることを考えると、おそらくまだ流動的です(はい?)-近い将来に一部のビットを復活させる必要があるという考えは無理ではありません。

そもそも正しく入手するのが難しく、復活する可能性が高いと思われるビットについては、ソース管理の場合よりも少し「ライブ」にしたいと思います。人々は自分が存在することを知らない/覚えていない-「ソース管理でそれを見つけることができる」と言うことは、それがそこにあることを知っている/覚えていることを前提としている!このような場合は、非推奨(「assert(false)」showtopperを使用)またはコメントアウトを検討してください。


5
+1「「ソース管理で見つけることができる」と言うことは、あなたがそれがそこにあることを知っている/覚えていることを前提としている!」-時々、何らかの理由で役立つようにカットされたコードのリマインダーを少し見つけます。
スティーブン

3

コードが些細で面白くない場合は、ソフトウェアシステムの不必要な慣性を取り除くためにそれを捨てるだけです。

興味深いコード死体についてarchiveは、バージョン管理システムでブランチを使用しています。


3

「参照として使用できます」未使用のコードを残す正当な理由に同意する傾向はありません。多くの場合、未使用のコードのごく一部のみが実際に興味深い何かを示しています。有用だが未使用のコードを文書化して保存する方法は複数あります。

バージョン管理には、後でコードが必要であると判断した場合に特定の機能を簡単に復元できる履歴が含まれますが、バージョン管理履歴を見て、以前のリビジョンが何であるかを知っている人からxyまたはzを見つける必要があることを知っています少し退屈で、探しているものがかなり具体的なアイデアを持っていない限り、しばしば見落とされます。

コードは、いつ削除されたか、なぜ単にコードから削除されなかったのかについてのメモでコメントアウトできます。ただし、これは一般に悪いスタイルと見なされ、使用されず適切に維持されないコードは、後でコメント解除されるとあらゆる種類のバグを引き起こす可能性があるため、これは一般的に中間リファクタリング中の一時的なデバッグ/テスト手順としてより優れています製品コードを残す方法。

削除されたコードを保存するための私のお気に入りの方法は、将来役に立つと思われる場合、価値のある削除されたコードのさまざまなチャンクをすべて含む二次参照ドキュメントを作成することです。コードの各ブロックには、それがどこから来たのか、削除されたときやコードの最後のリビジョン番号など、覚えておくべき他の何かについての簡単な言及が付けられています。「潜在的に有用」なものはすべて削除され、簡単に検索できますが、継続的に維持およびテストするための一定の努力は必要ありません(テストはコードが再導入されるポイントまで延期されます)。


2

未使用のメソッドを保持する理由の1つは、他のブランチ/タグで使用できることです。

アクティブなブランチおよびタグをすべて削除してから、それらを削除します。


それは私には意味がありません:それはで使用されていない場合、このブランチからそれを削除し、このブランチ。別のブランチがそれを使用する場合、そこに留まります。
sleske

1

バージョン管理システムを使用している場合、将来の参照について心配する必要はありません。単にそのコードの履歴を見て、削除された部分を見つけることができるからです。使用しないで、いつか使用されると思われる場合は、そのままにしておきますが、コメントの理由を説明する説明でコメントします。

ただし、今後使用しないことが確実な場合は、単に削除してください。あなたが言及した理由は、コードが削除されるのは非常に簡単だと思います。

ただし、削除する前に、どこでも使用されていないことを確認してください。Visual Studioには、ソリューション全体を検索し、現在の変数、メソッド、プロパティ、クラス、インターフェイスなどへの参照を検索するFind All Referencesという機能があります。コードの一部を削除する前に参照が設定されていないことを常に確認します。


1

私は比較的頻繁に、必要なことを正確に行うように見える関数を見つけ、それが実際に使用されていないことを知るためだけに長い間生産されているので、動作することを信頼する経験がありました数年。使用されないコードは維持されず、何年も前に機能していたかもしれませんが、その周りのAPIは十分に変更されているため、信頼できません。

せいぜい、あなたはそれが実際にあなたが望むことをすることを確かめるために多くの時間を費やすことになります。最悪の場合、後から厄介なバグに噛み付くまでは動作しているように見え、「実稼働テスト済み」のコードが機能することを前提としているため、問題は新しいコードのどこかにあるはずなので、追跡に時間がかかります。私の経験では、新しい関数を自分で記述するだけで、ほとんどの場合は速くなります。

削除しても、実際に必要なのが比較的すぐにわかる場合は、ソース管理にあります。ソース管理にあることを思い出せないほど長い時間が経過するまで必要ない場合は、とにかくゼロから作成する方が良いでしょう。


1

コードを使わないほど時間はかかりません。

コードベースに飛び込む必要がある場合は、そのコードが何に使用されているのかを把握するのにある程度の時間が必要であり、何の目的にも使用されない場合はさらに時間が必要です。

OK-これはコメントで癒される可能性がありますが、それでも、この未使用のコードが削除されるべきかどうかにかかわらず、誰もがこの未使用のコードがまだコードベースにある理由について推論します。

何もなければ、誰もそれに時間を失うことはありません。

正しく理解するのが困難だった場合、このコードが存在することを示す適切なドキュメントが必要ですが、コードベースがいくつかのイテレーションを経て進化する場合、再アクティブ化されると動作しなくなる可能性があります。


1

未使用のコードを削除します-煩雑さを減らし、理解を深める。バージョン管理システムが面倒を見てくれます。また、メモ帳よりも優れたものを使用している場合、ご使用の環境では参照用に古いコードを使用できます。

古いコードの長いコメントは気を散らし、ナビゲーションを困難にします。

よろしく


1

この簡単なアルゴリズムに従ってください:

  1. SCMでバックアップされていますか?はいの場合、3にジャンプします。
  2. SCMをセットアップします。
  3. ものを捨てる

削除を支持するすべてのポイントは有効です。

乱雑さを維持することを支持するすべてのポイントは、それを検索または復元するSCMを取得すると無効になります。実際に、SCMは、適切に使用されていれば、そのコードがここにあり、使用されていない理由を判断するのに役立つはずです。

理由から「デッドコード」と呼ばれています。死んで安らかに眠らせてください。


0

ソース管理にとどまります。アクティブなコードベースに残らないでください。

1つの例外は、コードが設計を完了し、コードを使用していないときに最終的にコードを公開する予定であり、他の人がその基本的な機能を必要とする場合です。次に、テストを設計して、他の人がコードのこれらの部分を使用することを提案する方法を模倣するコードのこれらの部分が機能することを確認します。ただし、コードを削除することを検討していて、それを保持する確固たる理由が思いつかない場合は、実行する必要があります。未使用のコードは、すべての人にとってより多くの作業を行います(コードを読むのが難しくなります;コードが壊れる可能性があります;維持するためのより多くの作業など)


0

私の経験では、未使用のコードを削除すると、逆効果も発生します。あなたはそのコードを持っていたのを忘れるかもしれません、そしてあなたは歴史でそれを探しません。または、誰かがそのコードを実装し、後でそれを削除したことさえ知らないかもしれません。繰り返しますが、あなたは歴史でそれを探しません...

間違いなく、未使用のコードがあることは悪臭です。

更新: Ed Staubが非常によく似た答えを出したことに気付いた。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.