冗長ファイルをVCSからすぐに削除せず、代わりにコメントで「削除対象」としてマークするのは悪い習慣ですか？

バージョン管理から削除する必要があるソースファイルの処理方法が悪い習慣と見なされるかどうかを知りたかったのです。

その例に基づいて説明します。

基本的にデッドコードであるプログラムのJavaクラスを退屈に整理しなければならなかったので、最近非常に怒った。もちろん、それらは削除する必要がありましたが、私はそのような冗長なものを削除する前に-奇妙なことを言うかもしれません-習慣があります：

私はSVN-> Deleteを介してそのような冗長ファイルをすぐに削除しません（選択したバージョン管理システムの削除コマンドに置き換えます）代わりにそれらのファイルにコメントを入れます（私は頭とフッターの両方を参照します）削除されます+私の名前+日付-さらに重要なこと- それらが削除された理由 次に、保存してバージョン管理にコミットします。次回プロジェクト内の何かをバージョン管理にコミット/チェックインする必要があるとき、SVN-> Deleteを押すと、最終的にバージョン管理で削除されます-もちろん、修正によって復元できます。そのため、この習慣を採用しました。

すぐに削除するのではなく、なぜこれを行うのですか？

私の理由は、少なくともそれらの冗長ファイルが存在した最後のリビジョンに明示的なマーカーを持ちたい、なぜ削除するに値するのかということです。それらをすぐに削除すると、それらは削除されますが、削除された理由はどこにも文書化されていません。私はこのような典型的なシナリオを避けたい：

「うーん...なぜそれらのファイルが削除されたのですか？私は以前はうまく動いていました。」（「元に戻す」を押す->元に戻す人は永遠になくなるか、次の週に利用できなくなり、次の担当者は私のような退屈なファイルの内容を知る必要があります）

しかし、コミットメッセージでそれらのファイルが削除された理由に注意しませんか？

もちろんやりますが、コミットメッセージが同僚によって読まれない場合があります。（私の場合は死んでいる）コードを理解しようとするときに、最初にバージョン管理ログと関連するすべてのコミットメッセージを確認するのは、典型的な状況ではありません。同僚はログをクロールする代わりに、このファイルが役に立たないことをすぐに確認できます。時間を節約でき、このファイルはおそらく復元された可能性が高いことを知っています（または、少なくとも問題が発生します）。

ファイルにコメントを追加する際の問題は、ソース管理で削除して説明を付けるのではなく、削除する必要があるため、開発者がコミットメッセージを読んでいない場合、ソースコードのコメントを必ず読むという前提です。

部外者の観点から見ると、この方法論はソース管理の非常に保守的な見方に根ざしているようです。

「この未使用のファイルを削除して、誰かがそれを必要としたらどうなるでしょうか？」誰かが尋ねるかもしれません。

ソース管理を使用しています。変更を元に戻すか、ファイルを削除した人に連絡してください（通信）。

「私が死んでファイルを削除した場合は、その後、誰かがそれを再び使用を開始し、彼らは変更を加えます？」他の誰かが尋ねるかもしれません。

繰り返しますが、ソース管理を使用しています。人が解決しなければならないマージ競合が発生します。ここでの答えは、最後の質問と同様に、チームメイトとコミュニケーションを取ることです。

ファイルを削除する必要があると本当に疑う場合は、ソース管理から削除する前に通信してください。たぶん最近使用されなくなっただけかもしれませんが、今後の機能で必要になるかもしれません。あなたはそれを知りませんが、他の開発者の一人はそうかもしれません。

削除する必要がある場合は、削除します。コードベースから脂肪を取り除きます。

「おっと」を作成し、実際にファイルが必要な場合は、ファイルを回復できるようにソース管理を使用していることに注意してください。

質問に対するコメントで、Vincent Savardは次のように述べています。

...同僚がコミットメッセージを読んでいないのに、正当に削除されたファイルを復活させ、コードレビューに合格した場合、チームに間違いがあるのは間違いありません。

これは適切なアドバイスです。コードレビューはこの種のものをキャッチする必要があります。開発者は、ファイルに予期しない変更が加えられたとき、またはファイルが削除または名前変更されたときに、コミットメッセージを参照する必要があります。

コミットメッセージがストーリーを伝えていない場合、開発者はより良いコミットメッセージを記述する必要もあります。

コードの削除やファイルの削除を恐れることは、プロセスに関するより深い体系的な問題を示しています。

• 正確なコードレビューの欠如
• ソース管理の仕組みに関する理解不足
• チームコミュニケーションの欠如
• 開発者側の不十分なコミットメッセージ

これらは対処すべき問題であるため、コードやファイルを削除するときにガラスの家に岩を投げているような気がしません。

はい、それは悪い習慣です。

ファイルの削除をコミットするときは、コミットメッセージに削除の説明を入れる必要があります。

ソースファイルのコメントは、現在のコードを説明する必要があります。コミットメッセージは、コミットの変更が行われた理由を説明する必要があるため、ファイルのコミット履歴はその履歴を説明します。

ソース自体に直接変更を説明するコメントを書くと、コードを追跡するのが非常に難しくなります。考えてみてください。コードを変更または削除するたびにファイルにコメントを追加すると、すぐにファイルに変更履歴に関するコメントが押し寄せます。

私の意見では、あなたのオプションは両方ともベストプラクティスではなく、悪いプラクティスではありません：

1. コメントを追加しても、誰かがそのコメントを読んだ場合にのみ、値が追加されます。
2. （変更の説明に理由がある）VCSから単純に削除すると、重要な成果物に影響を与える可能性があり、多くの人々は、特に圧力がかかっている場合に、変更の説明を読みません。

私の好ま練習- 、年間で数回かまれたことに主に起因するか、誰によって、あなたのコードが使用されている場合、あなたが常に知っていないことを念頭に置いては -にあります：

1. それは削除候補とある旨のコメントの追加、非推奨 #warning または類似を、（ほとんどの言語は、このような仕組み、例えば中のいくつかの並べ替えていたJavaを、最悪の場合、print文または類似の意志で十分）、理想的な時間スケールのいくつかの並べ替えを持つと連絡先の詳細。これにより、まだ実際にコードを使用しているユーザーに警告が表示されます。こうした警告が存在する場合、これらの警告は通常、各関数またはクラス内にあります。
2. しばらくして、警告を標準のファイルスコープにアップグレードします#warning（一部の人々は非推奨の警告を無視し、一部のツールチェーンはデフォルトでそのような警告を表示しません）。
3. 後でファイルスコープ#warningをa #errorまたは同等のものに置き換えます-これによりビルド時にコードが破損しますが、絶対に必要な場合は削除できますが、削除する人は無視できません。（一部の開発者は、警告を読んだり対処したり、重要な警告を区別できないほど多くの警告を持っています）。
4. 最後に、ファイルをVCSで削除済みとして（期日以降に）マークします。
5. 警告段階で全体のパッケージ/ライブラリ/などを削除した場合、私はあるREADME.txtまたはREADME.htmlファイルまたは類似追加しますなぜパッケージを取り除くために計画されているときとの情報と、ちょうどそのファイル、去るAとし残りのコンテンツを削除した後のしばらくのパッケージの唯一のコンテンツとして、それが削除されたときに言うように変更します。

このアプローチの利点の1つは、一部のバージョン管理システム（CVS、PVCSなど）がVCSで削除された場合、チェックアウト時に既存のファイルを削除しないことです。また、良心的な開発者、すべての警告を修正する開発者、問題に対処するため、または削除に異議を申し立てるための多くの時間を与えます。また、残りの開発者に、少なくとも削除通知を見て、多くの苦情を言わせます。

なお、#warning/ #errorで提供されたテキストが続く警告/エラーが発生するC / C ++のメカニズム時にコード、Javaが/ javaの-docのは、持っていることをコンパイラの出会い@Deprecated使用上＆警告を発行するために注釈を@deprecatedなどがあり、いくつかの情報を提供しますPythonで同様のことを行うレシピ＆私は、現実の世界でassert同様の情報を提供するために使用されるのを見てき#errorました。

はい、それは悪い習慣であると言いますが、それはファイルとコミットメッセージにあるからではありません。問題は、チームと通信せずに変更しようとしていることです。

トランクに変更（ファイルの追加、削除、または変更）を行うたびに、トランクにコミットする前に、チームのメンバー（またはメンバー）と直接話し合う必要があります。それらについて知識がある（基本的に、チームメートと直接これらのヘッダーに入れる内容について話し合う）。これにより、（1）削除するコードを本当に削除する必要があり、（2）コードが削除されたことをチームが知っている可能性が高くなり、削除を元に戻そうとしないようになります。言うまでもなく、追加したコードのバグ検出なども得られます。

もちろん、大きなものを変更するときは、コミットメッセージにも含める必要がありますが、すでに説明しているので、重要なアナウンスのソースである必要はありません。Steve Barnesの答えは、コードの潜在的なユーザープールが大きすぎる場合に使用するいくつかの優れた戦略にも対応しています（たとえば、最初にファイルを削除する代わりに、言語の非推奨マーカーを使用します）。

コミットせずにそれほど長くしたくない場合（つまり、変更が複数のリビジョンとして最も意味がある場合）、トランクからブランチを作成し、ブランチにコミットしてから、ブランチをマージしてトランクに戻すことをお勧めします変更の準備ができています。そうすれば、VCSはまだファイルをバックアップしていますが、変更はトランクに影響を与えません。

複数のプラットフォームと構成でビルドされるプロジェクトに関連する問題。死んだと判断したからといって、それが正しい判断だとは限りません。使用中の死者は、まだ除草する必要がある残留依存を意味する場合があり、一部は見落とされている可能性があることに注意してください。

だから（C ++プロジェクトで）私は追加しました

#error this is not as dead as I thought it was

そして、それをチェックインしました。すべての通常のプラットフォームの再構築が完了するのを待ち、誰もそれについて文句を言うことはありません。誰かがそれを見つけた場合、行方不明のファイルに戸惑うのではなく、1行を削除するのは簡単です。

あなたが言及したコメントはバージョン管理システムで行われるべき機能を複製していることに原則的に同意します。しかし、それを補う特定の理由があるかもしれません。VCSツールを知らないことはそれらの1つではありません。

悪い習慣の連続で、これは非常にマイナーです。ブランチをチェックアウトして古いコードを確認できるようにしたいときに、これを実行します。これにより、置換コードとの比較が容易になります。通常、コードレビューコメント「cruft」を受け取ります。ちょっとした説明で、コードレビューに合格しました。

しかし、このコードは長く続くべきではありません。私は通常、次のスプリントの開始時に削除します。

コミットメッセージを読んでいない同僚や、プロジェクトにコードを残した理由を尋ねない同僚がいる場合、問題はコーディングスタイルの問題ではありません。別の問題があります。

スタントをプルする前に、クラスをリファクタリングし、UNUSED_Classnameにプレフィックスを付けて名前を変更することもできます。次に、削除操作も直接コミットする必要があります

• ステップ1：クラスの名前変更、コメントの追加、コミット
• ステップ2：ファイルを削除してコミットする

デッドコードの場合は、削除します。誰でもそれを必要とします、彼らは戻ることができます、しかし、名前を変更するステップは、彼らが考えることなくそれを直接使用するのを防ぎます。

また、ファイルのすべてのコミットメッセージを表示する方法を人々に教えます。一部の人々はそれが可能であることすら知らないのです。