未使用のコードはプロジェクトから削除する必要があると何度も耳にしました。しかし、私には「なぜ？」ということは明らかではありません。
削除しないための私のポイントは次のとおりです。
誰かが未使用のコードを削除 (または保持) することの利点を説明できますか?
未使用のコードを削除する必要がある理由は次のとおりです。
プロジェクトに初めて取り組む人は、作業コードを理解するだけでなく、未使用の資料も理解する必要があります。これは時間の無駄であり、混乱を招きます。
ある時点で、誰かが不注意に「休眠中の」コードを含む変更を行い、バグを導入する危険性があります。私が取り組んだプロジェクトでそれが起こったことを知っています。
コードのメンテナンスは管理上の負担です。古い冗長コードを保存することで、負担が増加します。たとえば、メイン ブランチでの変更のマージは、作業するコードが多くなり、間違いを犯す可能性が高くなるため、難しくなります。
時間が経つにつれて、未使用の古いコードがコードベースにどんどん追加されていきます。これにより、混乱、潜在的な誤解、および管理オーバーヘッドが増加します。
未使用のコードが再び使用される可能性はほとんどありません。時間の経過とともに、再利用の可能性は減少します。コードを削除する必要があり、十分に重要であると見なされる場合、コードを分岐して文書化できます。
熱心に取り組んだコードについてコーダーが抱く個人的な感情は理解できます。しかし、プロであることの一部は、より良い利益のためにそれらの考えを脇に置く必要がある. 時間は誰の代にもならず、動作中のコードベースに過去のコードを保存する場所はありません。
@suspectus は、コードを削除する理由を提示する素晴らしい仕事をしてくれました。コードを保持するための個々の箇条書きに対処したいと思います。
- コードはすでに書かれており、労力が費やされている
しかし、すでに書かれたコードが使用されていない場合、これは (将来の) 価値のないコストだけです。それは無駄に投資された努力であり、それらの努力の未使用の製品を保存することは、それらの努力を検証するものではありません. 私たちがコードを保持しているのは、作者の努力を記念するものではなく、今では有用だからです。
- コードは、構文および実際の環境でテストされる場合があります
申し訳ありませんが、これが何を意味するのかわかりません。
- 適切に整理されていれば (グループ化、個別のパッケージ、疎結合など)、全体的なコード分析やリファクタリングを妨げません。
コードベースに存在する場合、どんなによく整理されていても、メンテナンスと理解の負担につながります。確かに、負担が少なくなるように整理することはできますが、それがなくなると、まったく負担になりません。
- コードは将来使用される可能性があります
アジャイル スクールでは、YAGNI : You Ain'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);
まず第一に、常にソース管理ツールを使用してプロジェクトを管理する必要があります。そのため、未使用のコードを削除することをお勧めします。これは、ソース管理を使用していつでも削除されたコードを取得できるためです。私にとって、使用されていないコードを削除する理由は、コードが使用されていないことを知っている人だけがそれを知っているためです。チームの他の誰かがそのコードに出くわし、それが何をするのか、アプリケーション全体にどのように適合するのかを理解しようとします。コードがまったく使用されないほど多くの努力をした後、がっかりするでしょう:)
私はあなたが2つのケースを持つことができると思います:それを維持するためのより良い選択ですが、アクティブな開発プロセスの中で