誰かが未使用のコードを削除（または保持）する利点を説明できますか？

未使用のコードをプロジェクトから削除する必要があると何度も聞いています。しかし、「なぜ？」は私にははっきりしません。

それを削除しないことの私のポイントは：

• コードはすでに書かれていて、努力が費やされている
• コードは、合成環境と実際の環境でテストできます
• うまく整理されていれば（グループ化、個別パッケージ、疎結合など）、全体的なコード分析やリファクタリングを妨げることはありません
• コードは将来使用される可能性があります
• 削除すると、作者は不快に感じるかもしれません

誰かが未使用のコードを削除（または保持）する利点を説明できますか？

未使用のコードを削除する必要がある理由は次のとおりです。

• プロジェクトに新たに取り組む人にとって、彼らは作業コードを理解する必要があるだけでなく、未使用の資料も理解する必要があります。これは無駄な時間であり、混乱を引き起こします。

• いつか誰かが誤って「休止」コードに関係し、バグを引き起こす可能性のある変更を加える危険があります。私が取り組んだプロジェクトでそれが起こったことを知っています。

• コードのメンテナンスは管理上の負担です。古い冗長コードを保持することで、その負担が増大します。たとえば、mainブランチでの変更のマージは、処理するコードが多くなり、間違いを犯す可能性が高くなるため、困難になります。

• 時間の経過とともに起こるのは、ますます古い未使用のコードがコードベースに追加されることです。これにより、混乱、潜在的な誤解、および管理オーバーヘッドが増加します。

• 未使用のコードが再び使用される可能性はほとんどありません。時間とともに、再利用の可能性は減少します。コードを削除する必要があり、十分に重要であると考えられる場合は、コードを分岐して文書化できます。

• コーダーが懸命に取り組んだコードについての個人的な感情は理解できます。しかし、プロであることの一部は、より良い利益のためにそれらの考えを一方に置く必要があることを要求します。時間は誰もいないことを表しており、実際のコードベースに履歴コードを保存する場所はありません。

@suspectusは、コードを削除する理由を提示するという素晴らしい仕事をしました。コードを保持するための個別の箇条書きについて説明します。

• コードはすでに書かれていて、努力が費やされている

しかし、すでに書かれたコードが使用されていない場合、これは（将来の）価値がない場合のコストです。それは無駄に投資された努力であり、それらの努力の未使用の製品を保存することはそれらの努力を検証しません。コードは、今は作者の努力に対するある種の記念としてではなく、有用であるため、私たちはコードを保持しています。

• コードは、合成環境と実際の環境でテストできます

すみません、これがどういう意味かわかりません。

• うまく整理されていれば（グループ化、個別パッケージ、疎結合など）、全体的なコード分析やリファクタリングを妨げることはありません

それがコードベースに存在する場合、どれだけうまく整理されていても、それは保守と理解の負担に貢献します。確かに、負担が少なくなるように整理できますが、なくなってしまってもまったく負担はありません。

• コードは将来使用される可能性があります

アジャイルスクールでは、YAGNI：You Ai n't Gonna Need It と言います。はい、あなたは将来的にそれを使用する可能性がありますが、今日の明日のニーズについて、あらゆる種類の信頼性でそれを予測できることを十分に知ることはできません。そうでなければ考えることは傲慢が傲慢になりがちです。私たちがすることができます明日について知るは、コードベースを簡単に変更できるようにすることであり、未使用のコードはその特性を損なうことです。

• 削除すると、作者は不快に感じるかもしれません

著者はそれを乗り越える必要があります。役に立たないと判明したことはすべて書きました-使用できるコードの本体よりも、使用されていないコードの本体（未使用の残骸が削除されたため）を指すことができる方がはるかに優れています。いくつかの方法、「そして、それは実際に使用されています！」

いくつかのコードを拾い上げて意図を理解するのに十分ではありませんが、今は使用されていない部分を理解する必要がありますか？

コードはすでに書かれていて、努力が費やされている

それも不要です。それを何にも使用しないと、それが何をするか、どれだけの労力が費やされたかにかかわらず、（定義上）役に立たなくなります。

コードは、合成環境と実際の環境でテストできます

それが役に立たない場合は、テストを行っても役に立たない。コードが役に立たない場合、そのテストも役に立たないはずです（コメント化されたコードをそのままにしておくと、あいまいさが生じます-テストを続けますか？コメントされたコードのクライアントコードがある場合、クライアントコードもコメントしますか？ ）

うまく整理されていれば（グループ化、個別パッケージ、疎結合など）、全体的なコード分析やリファクタリングを妨げることはありません

そうではありません。すべてのツール（ソース管理、静的分析、ドキュメント抽出、コンパイラーなど）は、より多くのデータを処理する必要があるため、実行速度が遅くなります（そのデータの大部分または小部分はノイズです）。

コードがそうでない場合整理されていと、静的分析やリファクタリングなどが混乱します。

ツールの入力にノイズを導入し、ツールがそれを正しく処理することを期待しています。

静的分析ツールがコメント/コード比率を計算する場合はどうなりますか？昨日まで（またはコードがコメントされたとき）まで関連性のあるもので、それを台無しにしました。

すべての中で最も重要なのは、コメント付きのコードブロックは、メンテナンスとさらなる開発のためのコードの理解に遅延をもたらし、そのような遅延はほとんど常にコストがかかります。自問してみてください。関数の実装を理解する必要がある場合、何を見なければなりませんか？2行の明確なコード、または2行のコードともう実際の26のコメント？

コードは将来使用される可能性があります

もしそうなら、あなたはチームの選択したSCMにそれを見つけるでしょう。

有能なSCMを使用して、（ソースを散らかすのではなく）デッドコードを維持することに依存している場合、誰がそのコードを削除したか（作成者をコミット）だけでなく、その理由（コミットメッセージ）やその他の理由を確認できます。変更が加えられました（そのコミットの残りの差分）。

削除すると、作者は不快に感じるかもしれません

そう？

あなたは（私が思うに）あなたが方法を知っている最高のソフトウェアを作るために支払われる開発者のチーム全体であり、「Xの感情を損なうことなく方法を知っている最高のソフトウェア」ではありません。

これはプログラミングの一部であり、書かれたほとんどのコードは最終的に破棄されます。たとえば、Joel Spolsky氏は、ある時点で、自社の場合、記述されたコードの約2％が本番環境にあると述べています。

コードベースの品質よりも開発者のエゴを優先する場合、製品の品質を犠牲にします。仲間の開発者の未熟さを維持しますか？同僚の非現実的な期待を守りますか？

編集：私はソースにコメントアウトされたコードを残す正当な理由を1つ見ました、そしてそれは非常に特定のケースです：コードが奇妙な/直感的でない形式で書かれていて、それを書き直すきれいな方法ではない場合本当に微妙な理由で働きます。これは、問題を修正するために繰り返し試行された後で、試行が同じ欠陥を再導入するたびにのみ適用されます。そのような場合は、コメント付きの直感的なコードをコメントとして追加し、機能しない理由を説明する必要があります（将来の開発者が同じ変更を再度試みることはありません）。

// note by <author>: the X parameter here should normally
// be a reference:
// void teleport(dinosaur& X);
// but that would require that we raise another dinosaur and
// kill it every twelve hours
// as such, the parameter is passed by value
void teleport(dinosaur X);

デッドコードがコードを汚染しています

デッドコードは、理解しやすさと読みやすさを低下させます。

最良のコードは常に再利用され、使用できないコードがあると再利用性が低下します

私たちはコーディングのモジュラーアプローチに基づいており、マシンではなく、他のプログラマーとのやり取りのためのコードを設計しています。彼/彼女が私たちのコードを理解しやすくするために、私たちは最も力を注ぐべきです。マシンはとにかく大丈夫です。

死んだコードやコメントされたコードは、人々を混乱させる偽の道標のようなものなので、絶対に避けてください。

• 恐怖。これにより、チームは心配事を増やし、生産量を減らすことができます。より多くのデッドコードが導入されると、恐怖の量は指数関数的に増加します。「そのビットが使用されているかどうかはわからないので、あえて削除したり触れたりすることはありません。」

• 抜本的な変更。システムのあらゆる場所で変更する必要がある何かがデッドコードにも存在する場合、それを変更しますか？どこかで使用されていないかどうかを判断するのは非常に難しいため、常にリスクが伴います。そして、それが何も壊さないとしても、この変更後に使用に戻された場合、デッドコードはまったく機能しますか？

  抜本的な変更に対処する場合、開発者はコードを含むすべての場所もチェックする必要があり、デッドコードの場合、これは冗長です。また、コードが停止している場合は、どこでも使用されていないことを確認することが難しいため、チェックに時間がかかります。

• 精神的負荷。何かが使用されているかどうか、または死んだコードに対して何かをする必要があるかどうかを考える必要があるたびに、それはあなたの頭脳力のいくらかを必要とします。
• 野生のガチョウの追跡。「Foobarの使用例が必要です。ああ、コードベースのこれらの場所にあります。最初のヒットをチェックして、これがUIのどこにあるかを調べます。うーん...どこにも見つかりません。」
• 膨張したレポート（たとえば、コード、クラス、ルーチン、変更の行数）。プロジェクトの可視性と、コードベースのどの部分に取り組む必要があるかに関する決定と将来のプロジェクトの見積もりを歪めます。
• コードベースに対する信頼の低下。これにより、冗長なタスクにより多くの時間が費やされる可能性があり、コードベースの使用の流れを壊します。開発者は、使用するすべてのものが期待どおりに機能することを非常に注意深くチェックする必要がある場合があります。

コードベースの一部が使用されていないことがわかっていれば、それを削除できるため、非常に役立ちます。それをそのままにしておけば、将来的にそれが実際に使用されていないことを確認することは困難またはほとんど不可能になる可能性があります。たとえば、意外な方法でコードを使用するもののいくつか：リフレクション、文字列から連結されたルーチンを動的に呼び出す、eval、framework magic。

ただし、将来コードが使用される可能性が高い場合は、バージョン管理システムではなく、他のコードに沿って追加すると簡単に追加できます。しばらくしてコードに含まれていた単語を覚えていない可能性があるため、VCSの腸からコードを見つけるのは非常に困難です。しかし、死んだコードはほとんど存在しないようにし、それでもコードをコメントアウトします。

• 未使用のコードは、ユーザーが読み通すだけでなく、一般的にコードをスキャンするためのより大きな検索スペースです。たとえば、コンパイラー、IDE、ファイル内検索、デバッグ、静的分析、その他のレビュー、ファイルの取り込み、VCSからのチェックアウトなど。これにより、これらのプロセスの速度が低下し、大きなノイズが追加されます。
• 未使用のコードが常にデッドコードであるとは限りません。特定の状況で実行される場合があります。これは、バグやパフォーマンスの問題を引き起こす可能性があるだけでなく、セキュリティの問題にもなります。パフォーマンスに関しては、これは大きなダウンロードなどの予期しない方法でそれ自体を表現できます。
• 未使用のコードは未使用のコードを生成します。関数呼び出しを削除し、その関数の使用を検索して、その関数がまだ必要かどうかを確認すると、以前の未使用のコードとの一致が見られ、それを保持できると想定できます。未使用のコードが多いほど、コードが未使用かどうかを判断するためのホップが多くなります。
• 未使用のコードは、依然として多くの場合、維持する必要があります。AとBがCに依存しているとします。これらのうちBは使用されません。Cを変更すると、Bが必要とするCの構造体からメンバーを削除したため、Bはコンパイルされません。今度はBを修正するか、アクティブにコンパイルから削除する必要があります。あなたは単にそれを取り除くべきでした。

このリストは単純に見えるかもしれませんが、これらのそれぞれは、開発プロセス全体にわたって相乗効果をもたらす抗力を追加する何百もの異なる方法で現れます。非効率性は、多くの場合、単純かつ数学的な方法で証明または実証できます。

あなたのポイントに応えて...

• コードはすでに書かれていて、努力が費やされている

しかし、それはしばしば維持されなければなりません。また、ファイル内の検索などでも表示されます。

• コードは、合成環境と実際の環境でテストできます

これがどういう意味かわかりません。前回と同じだと思います。つまり、コードはすでにテストされており、クリーンアップすると、再テストが必要になる場合があります。それは時間の90％を完済し、生産に入る前にクリーニングする必要があることを回避するため、通常は価値のあるコストです。ほぼすべてのコードには2つの反復があり、それを機能させ、クリーンにします。その理由は、誰かが最後のステップをスキップしたためです。コードもコストが高すぎて、diff、test（多くの未使用のコードが乱雑であるかどうか）をテストして証明できない場合、それは別の全体的な問題です。

• うまく整理されていれば（グループ化、個別パッケージ、疎結合など）、全体的なコード分析やリファクタリングを妨げることはありません

とにかくあなたのコードはこのようなものでなければなりませんが、それは問題を穏やかに軽減するだけです。何かが整理されていて、汚れているべきだと聞くのは、奇妙な議論です。コードをモジュール化し、依存関係を減らすことは通常のことですが、再利用可能なコードも必要です。また、すべてのモジュールが孤立している場合は、DRYになっていません。また、未使用の乱雑なコードの問題を軽減するだけで、過度のデカップリングを実行している場合もあります。

• コードは将来使用される可能性があります

書かれたコードを大事にする多くの人々。それが現在使用されていない場合、それは重荷であり、実際には、このパスをたどると、多くの場合、未使用のコードの一部のみが使用済みコードになります。おそらく、未使用のコードが使用可能または使用済みのコードである可能性は低いです。再利用される可能性が最も高いコードは、既に何かをしているコードを使用しています。

さらに悪いことに、未使用のコードには目的がありません。誰かがやって来て、未使用のコードに影響を与えるような何かを変更しなければならないとき、彼らはそこに座って、この未使用のコードが何もする必要のないことを理解しようとして困惑するでしょう。

コードが多くの労力を費やすので、開始時に人々がこのように感じるのは簡単です。しかし、流暢で慣れれば、コードは自転車に乗るようになります。このようなコードを書くコストは、忍び寄るコストを大幅に下げるのでわかります。

• 削除すると、作者は不快に感じるかもしれません

これは作者の問題です。一方で、他の人が対処しなければならない未使用のコードをたくさん残しておくのは利己的です。一方、作者がコードの品質に自分の気持ちを置くならば、おそらくコーディングするべきではありません。彼らの気持ちを損なうので、壊れたコードを修正することはできません。誰かがコードに愛着しているというのは、それが良いというよりも彼らのものだからというのは良い兆候ではありません。作者は、コードがクリーンアップされることに満足すべきです。これは誰かがあなたのためにあなたのゴミを取り出してゴミ箱に捨てるようなものです。

誰かが私のためにそれをしてくれたら、私は月を越えます。それらの感情を乗り越えるのをより簡単にするかもしれないものは、誰かがそれをするのを待つ代わりに、自分でそれをやってみることです。行ったコードを繰り返し書き直し、パフォーマンスを向上させ、簡潔にし、余計なものを減らし、柔軟性を高めながら、毎回コードを減らします。コードの量については気分を害しないようにしてください。これはレベルアップするのが大変であり、一度実行すると、すべてのコードが適切なレベルで出力されるため、頻繁にレベル調整する必要はありません。

まず最初に、プロジェクトを管理するために常にソース管理ツールを使用する必要があります。そのため、ソース管理を使用していつでも削除されたコードを取得できるため、未使用のコードを削除することをお勧めします。私が未使用のコードを削除する理由は、コードが未使用であることを知っている人だけがそれを知っているためです。チームの他の誰かがそのコードに遭遇し、それが何をしてアプリケーション全体にどのように適合するかを理解しようとします。コードがまったく使用されないほどの努力の後に失望するでしょう:)

この議論は数年前のものですが、私はそれに遭遇しました...

私が言及していないことの1つは、未使用のコードを削除するために必要な作業です。多くの場合、未使用のコードを削除するための時間と労力は本質的に取る​​に足らないものではありません。さらに、リファクタリングされたシステムをテストして文書化するには、通常追加のコストがかかります。決定プロセスで考慮すべきもう1つのこと。

私はあなたが2つのケースを持つことができると思います：-アプリケーションコード：それが未使用の場合、おそらくそれはテストされておらず、長期にわたって管理されていない場合、おそらく「内部コードリポジトリ」にシフトすることができます-APIコード：ライブラリを書いているなら、私見ですそれを維持するためのより良い選択ですが、アクティブな開発プロセスの中で

コードは未使用ですか？

コードがコンパイルされていることを確認するだけでは不十分です。C ++では、コンパイラエラーが発生しないように、「未使用」の暗黙的に定義されたメソッドを削除するoperator=と、クラスは単に（潜在的に不正な）デフォルト実装を使用し始めます。JavaまたはC＃では、コードはリフレクションを介して使用される可能性があります。オブジェクト指向言語では、継承が役割を果たすことができます（基本クラスが呼び出される場合があります）。ほとんどすべての言語で、別のオーバーロードされた関数が引き継いだ可能性があります。

使用されていないだけでなく、バ​​ージョン管理でコードの古さを確認してください。使用されていないように見えても、コミットされたばかりのコードを確認しました。実際には、別の開発者のプロジェクトの最初のステップでした。

未使用のコードを積極的に削除する

コードを維持するために支払う：

• 壊れたビルドの修正（エンジニアリング時間）。最近、複雑な一連の#include変更があり、未使用のコードに新しいオーバーロードが導入されたため、何十人もの開発者のチームのすべてのエンジニアにとってかなり大きな頭痛が生じました。
• テストのマシンリソース（セルフテストの継続的ビルドがあると想定）。私のチームは最近、すべての最も遅いテストを調べましたが、それらの多くは、そうでなければ未使用のコードを超えていました。ローカルで、または継続的インテグレーションの一環としてテストを実行しているエンジニアは、未使用のコードに対するテストを待っています。
• 読みやすさの観点から（再びエンジニアリング時間）。ヘッダーファイルはAPIを表します。誰も使用したくないが誰もが読まなければならない関数が含まれている場合、コードの学習曲線ははるかに難しくなります。
• コード検索（再度エンジニアリング時間）。家、ハードドライブ、またはGoogleドライブを片付けますか？ドメインを検索するほど、誤検出を回避するために関連コンテンツを含めることが重要になります（またはWeb検索エンジンのようなより高度な検索を使用します）。

基本的に、平均的な開発者が作成するすべてのコードは5年間で使用されなくなるため、このアクティビティが停止することはありません。これをあなたにさせないでください。高品質で絶対に必要なコードのみを記述してください。