VCSからすぐに冗長ファイルを削除せず、最初にコメントで「削除する」とマークするのは悪い習慣ですか？
バージョン管理から削除する必要のあるソースファイルの扱い方が悪い習慣と見なされるかどうかを知りたかった。
その例に基づいて説明します。
基本的にデッドコードであるプログラムのJavaクラスを退屈に整理しなければならなかったため、最近非常に腹を立てましたが、どこにも文書化されておらず、それらのJavaクラスにもコメントされていません。もちろんそれらは削除する必要がありましたが、そのような冗長なものを削除する前に、私は-奇妙なことを言う人もいます-癖があります：
私はそのような冗長なファイルをSVN-> Delete（選択したバージョン管理システムの削除コマンドで置き換えます）を介してすぐに削除しませんが、それらのファイルにコメントを付けます（先頭とフッターの両方で参照します）。削除される+私の名前+日付および-さらに重要なこと-なぜ削除されるのか（私の場合、それらは死んでいて、混乱を招くコードだったため）。次に、保存してバージョン管理にコミットします。次回プロジェクトで何かをバージョン管理にコミット/チェックインする必要があるとき、SVN-> Deleteを押すと、それらは最終的にバージョン管理で削除されます-もちろん、リビジョンによっても復元可能ですが、これが私がその習慣を採用した理由です。
すぐに削除するのではなく、なぜこれを行うのですか？
私の理由は、少なくともこれらの冗長ファイルが存在する最後のリビジョンに明示的なマーカーを付けたいためです。なぜそれらを削除する価値があったのでしょうか。すぐに削除すると削除されますが、削除された理由はどこにも記載されていません。私はこのような典型的なシナリオを避けたいです：
「うーん...なぜこれらのファイルが削除されたのですか？以前は問題なく動作しました。」 （「元に戻す」を押す->元に戻した人は次の週に永久になくなるか利用できなくなり、次の担当者は私のような退屈な方法でそれらのファイルについて調べなければならない）
しかし、これらのファイルがコミットメッセージで削除された理由に注意しませんか？
もちろんそうしますが、コミットメッセージが同僚に読まれない場合があります。 （私の場合は死んでいる）コードを理解しようとするときに、最初にバージョン管理ログをチェックして、関連するすべてのコミットメッセージを確認するのは、一般的な状況ではありません。同僚は、ログをクロールする代わりに、このファイルが役に立たないことをすぐに確認できます。それは彼女/彼の時間を節約し、彼女/彼はこのファイルがおそらく悪いために復元されたことを知っています（または少なくとも問題を提起します。
ソース管理でコメントを削除してそこに説明を置くのではなく、削除する必要があるファイルにコメントを追加する場合の問題は、開発者がコミットメッセージを読み取らない場合、ソースコードのコメントを確実に読み取ることを前提としています。
部外者の視点から見ると、この方法論はソース管理の非常に保守的な見方に根ざしているようです。
「この未使用のファイルを削除すると、誰かがそれを必要とする場合はどうなりますか？」誰かが尋ねるかもしれません。
ソース管理を使用しています。変更を元に戻すか、ファイルを削除した人に連絡してください（通信）。
「死んだファイルを削除すると、誰かが再びそれを使い始めますand彼らは変更を加えますか？」他の誰かが尋ねるかもしれません。
ここでも、ソース管理を使用しています。人が解決しなければならないマージの競合が発生します。ここでの答えは、最後の質問と同様に、チームメートと通信することです。
ファイルを削除する必要があると本当に疑われる場合は、beforeをソース管理から削除することを伝えてください。たぶん、最近使用されなくなっただけかもしれませんが、今後の機能で必要になるかもしれません。あなたはそれを知りませんが、他の開発者の一人が知っているかもしれません。
削除する必要がある場合は、削除してください。コードベースから脂肪を取り除きます。
「oopsie」を作成し、実際にファイルが必要な場合は、ファイルを回復できるようにソース管理を使用していることを忘れないでください。
ヴィンセント・サバードは、質問に対するコメントで、こう述べました：
...同僚がコミットメッセージを読まずに、正当に削除されたファイルを復活させ、コードレビューに合格した場合は、チームに間違いがあり、より適切に教える絶好の機会です。
これは健全なアドバイスです。コードレビューはこの種のものを捕らえるべきです。開発者は、ファイルに予期しない変更が加えられたとき、またはファイルが削除されたか名前が変更されたときに、コミットメッセージを調べる必要があります。
コミットメッセージが物語を語らない場合、開発者はより良いコミットメッセージを書く必要もあります。
コードを削除したりファイルを削除したりすることを恐れているということは、プロセスにさらに深いシステム上の問題があることを示しています。
- 正確なコードレビューの欠如
- ソース管理がどのように機能するかについての理解の欠如
- チームのコミュニケーションの欠如
- 開発者側の不十分なコミットメッセージ
これらは対処すべき問題なので、コードやファイルを削除するときに、ガラスの家に岩を投げているように感じることはありません。
はい、それは悪い習慣です。
ファイルの削除をコミットするときは、削除の説明をコミットメッセージに入れてください。
ソースファイル内のコメントは、現在のコードを説明しているはずです。コミットメッセージは、コミットの変更が行われた理由を説明する必要があるため、ファイルのコミット履歴はその履歴を説明します。
ソース自体に変更を直接説明するコメントを書くと、コードの追跡が非常に難しくなります。考えてみてください。コードを変更または削除するたびにファイルにコメントを付けると、すぐにファイルに変更履歴に関するコメントが殺到します。
私の意見では、あなたのオプションの両方はベストプラクティスではありません、- 悪いこととは対照的に、練習：
- コメントを追加しても、誰かがそのコメントを読んだ場合にのみ、値が追加されます。
- （変更の説明に理由があるため）VCSから単に削除すると、重要な成果物に影響が及ぶ可能性があり、特にプレッシャーがかかっている場合、多くの人は変更の説明を読みません。
私が好む慣習は、主に長年にわたって数回噛まれたことによるものですコードがどこで誰によって使用されているかを常に把握しているわけではないことを念頭に置いてください –
- それが削除の候補であることを示すコメントと deprecation
#warningまたは類似のコメントを追加します（ほとんどの言語には、たとえば Java 、最悪の場合はprintステートメントなどで十分です）理想的には、ある種のタイムスケールと連絡先の詳細があります。これにより、コードを実際に使用している誰かに警告します。これらの警告は通常、各関数またはクラスの内部にありますそのようなものが存在する場合。 - しばらくして、警告を標準ファイルスコープ
#warningにアップグレードします（一部のユーザーは非推奨の警告を無視し、一部のツールチェーンはデフォルトでそのような警告を表示しません）。 - 後でファイルスコープ
#warningを#errorまたは同等のもので置き換えます。これにより、ビルド時にコードが破損しますが、絶対に必要な場合は削除できますが、削除した人は無視できません。 （一部の開発者は警告を読んだり対処したりしなかったり、重要なものを分離できないほど多くの警告を出したりします） - 最後に、ファイル（期限日以降）をVCSで削除済みとしてマークします。
- 警告段階でパッケージ/ライブラリ/ etc全体を削除する場合、README.txtまたはREADME.htmlまたは同様のものを追加しますパッケージを取り除く予定の理由と理由に関する情報を含むおよびそのファイルだけを残しますそれが削除されたことを通知する変更を加えてを、残りのコンテンツを削除した後、しばらくの間、パッケージの唯一のコンテンツとして残します。
この方法の利点の1つは、someバージョン管理システム（CVS、PVCSなど）が既存のファイルを削除しないことです。 VCSで削除されていないかチェックアウトします。また、良心的な開発者にもすべての警告を修正する人問題に対処したり、削除に異議を申し立てたりするのに多くの時間がかかります。また、残りの開発者は少なくとも削除通知を確認する必要がありますそして多くの文句。
#warning/#errorはC/C++メカニズムであり、コンパイラがそのコードに遭遇すると警告/エラーが発生し、その後に提供されたテキストが続くことに注意してください。Java/ java-docには@Deprecated使用に関する警告を発行するための注釈＆@deprecatedによる情報の提供など recipes python＆ assertは、現実の世界で#errorと同様の情報を提供するために使用されました。
はい、私はそれは悪い習慣だと言いますが、それはファイル内またはコミットメッセージ内にあるからではありません。 問題は、チームと通信せずに変更を加えようとしていることです。
トランクに何らかの変更を加える場合-何らかの方法でファイルを追加、削除、または変更する場合-トランクにコミットする前に、それらの変更について直接チームのメンバー（または複数のメンバー）に直接詳しい（基本的に、ヘッダーに何を入れるかをチームメイトと直接話し合う）。これにより、（1）削除するコードを本当に削除する必要があること、および（2）コードが削除されたことをチームが知る可能性が高くなり、削除を元に戻さないようになります。言うまでもなく、追加したコードのバグ検出なども行われます。
もちろん、大きな変更を行う場合は、コミットメッセージにも含める必要がありますが、すでに説明したので、重要なアナウンスのソースである必要はありません。 Steve Barnesの回答 は、コードの潜在的なユーザーのプールが大きすぎる場合（たとえば、最初にファイルを削除するのではなく、言語の非推奨マーカーを使用する場合）に使用するいくつかの優れた戦略にも対処します。
コミットせずにそれほど長く進みたくない場合（つまり、変更が複数のリビジョンとして最も理にかなっている場合）、トランクからブランチを作成してブランチにコミットし、ブランチがトランクにマージされてブランチにマージされることをお勧めします。変更の準備ができています。このようにして、VCSはまだファイルをバックアップしていますが、変更がトランクに影響を与えることはありません。
複数のプラットフォームと構成で構築されるプロジェクトからの関連する問題。 [〜＃〜] i [〜＃〜]が死んでいると判断しても、それが正しい判断であるとは限りません。使用中で死んでいるということは、まだ除かれる必要がある痕跡の依存を意味するかもしれないことに注意してください、そして、いくつかは見落とされているかもしれません。
だから（C++プロジェクトでは）私は追加しました
#error this is not as dead as I thought it was
そして、それをチェックインしました。すべての通常のプラットフォームの再構築が完了するまで待ち、誰もそれについて文句を言わないようにします。誰かがそれを見つけた場合、行方不明のファイルに戸惑うのではなく、1行を削除するのは簡単です。
あなたが言及したコメントが、実行すべき機能を複製していることは原則として同意しますバージョン管理システム内。しかし、それを補うために特定の理由があるかもしれません。 VCSツールを知らないことはそれらの1つではありません。