コードをコメント化するための良い置き換え？
コメントアウトされたコードを見るのは面倒で、多くの場合、開発者が高度なソース管理機能に精通していないという症状のようですが、一方で、ソース管理は、コメントアウトが意図されている問題を完全に解決するわけではありませんために。突然削除されたはずのコードが再び必要になるような方法で、要件フリップフロップをときどき見ました。コードが実際に削除された場合、ソース管理で削除されたコードを見つける場所を正確に見つけるための明確な手順がないようです。
実証済みの「コメントアウト」以外に、再度必要になる可能性のある開発者の作業を保存するためのより良い方法はありますか？
これについては非常に厳格であり、コメントアウトされたコードはチェックインしないようにすることがガイドラインです。これの背後にある理論的根拠は、エンジニアがチェックインする前にコメントを解除するのを忘れたかどうかを本当に知ることができないということです。コードがコメントアウトされている理由を説明するコメントには、疑問の余地があります。必要な場合は、ソース管理から戻すことができます。
私の意見では、要件を変更することの危険性は、チェックインされたコメントアウトされたコードのブロック（特に将来のある時点）を見て、そこにあるべきかどうか疑問に思う危険（およびおそらく不確実性）よりも小さいです。
結局のところ、仕様、ユーザーストーリー、Jiraチケット、その他すべてのジャズがあっても、「コードisドキュメント」-これは実際に何かについての唯一の決定的なリファレンスですします。
もちろん、それは単なるガイドラインです。きっと素晴らしい答えが得られると思います。ぜひ読んでください！
簡潔に言うと、コメント付きのコードをチェックインせず、問題トラッカーにメモを残してください。代替実装のリビジョン番号と場所を書き込みます。コードはクリーンなままであり、あなたはあなたの将来の自己を助けます。要件が変更されると、実装チケットが（再開する必要があります）再開され、ブレッドクラムを使用して以前のバージョンを見つけることができます。一部の課題トラッカーは、チケットで直接ソース管理の変更を自動的に追跡します。これは、もう1つの支援です。
ソース管理が整っていると仮定すると、コメントアウトされたコードのブランチ（またはシェルフ/スタッシュ）を作成する方が、ファイルの束を調べてコードの束全体のコメントを外す/再コメントする必要があるよりも、おそらくメンテナンスが簡単です。また、より安定した残りのコードベースからそのコードを論理的に分離するという副次的な目的にも役立ちます。
答えはそれを削除することです。質問は、削除後にそれをどのように処理すればよいかです。これは一部VCSに依存します。
削除するだけでは、blame（ git および svn を使用して何かを簡単に見つけることができないという問題があります。どちらにも、追加された場所を示す機能があります-およびコーディングホラーブログの投稿- 誰がこのクラップを書いたか？ ）。
ただし、コメントをその場所に配置すると、注釈と現在のコードに表示されます。
たとえば、コードブロックを次のように置き換えることができます。
/* code removed here that does frob()
* no longer needed because of XYZ requirement
* see f7f6023 for removed code
*/
おそらく、それを1行程度に簡略化して、私が持っているような目障りではないようにすることができます。アイデアは、誰かが再びそれを見つけられるように、コードに「ページの折り畳まれた角」を残すことです。確かに、あなたが取るコードのeveryブロックに対してこれを行わないでください。退屈なラインを引き出すだけの場合は、それを取り出して、それで完了です。ソース（つまり、コミットメッセージのスポット）を読むときに頭を混乱させる必要はありません。
ここでgitには、他のVCSが親の場所を指定できるよりも簡単に親のチェックサムを指定できるというわずかな利点があることを指摘します（ブランチにある場合もあれば、そうでない場合もあります）。
Githubまたは類似の社内リポジトリを使用している場合は、代わりにそれを Gist に抽出して、コメントで参照できます。
VCSシステムに精通していない場合は、Gistのアイデアを独自の「スニペット」ディレクトリに移動できます。このディレクトリは、維持したい機能のかなりのチャンクを参照します。
要旨とスニペットの抽出方法には、このコード内で簡単に検索できるという利点があります。削除されたコードではonlyではなく、何かを行うためのテンプレートを使用するべきではありません。ある時点で何かが削除されたことは、その抜粋を保存する理由ではありません。
この目的のために、質問 プロジェクト間でコードの小さなスニペットを共有するためのベストプラクティス を最適化する方法に関するアイデアを探すこともお勧めします。
別のアプローチは、問題追跡システム自体で問題のコードを削除したpatchを保存することです。コード削除のパッチを保存すると、削除されたコードも保存されます。問題追跡システムを検索すると、削除されたコードも検索されます。
すでに良い答えがいくつかありますが、1点追加したいと思います。
突然削除されたはずのコードが再び必要になるような方法で要件フリップフロップを時々見ました。
それがあなたが取り組むべきポイントです：要件とその理由をよりよく特定する理由が変更されます。最初の分析が適切でなかったために変更された場合、またはクライアントが実際に何を望んでいるかを理解するまでプロトタイプが必要だった場合、いくつかの反復後に安定する可能性が高くなります。次に、古いコードを削除して、必要なことを行うコードのみを保持できることが明らかになります。
ただし、ビジネスの一部のために要件が変更された場合（たとえば、要件Aが1月、3月、6月、Bが2月、4月、7月の場合）、1つの実装のみをサポートすることはおそらく間違っている可能性があります。このような場合、アプリケーションは、一般化された方法でそれらをサポートすることによって、またはいくつかのカスタマイズや構成を許可することによって、一度にこれらの異なる要件をより適切にサポートできます。このような場合、すべてのコードはアプリケーション内に残りますが、コメント化された部分ではなくアクティブな部分に残ります。
後者は、実際の要件に関する知識が安定していない限り、プロトタイピングフェーズで変化する要件に対処する必要がある場合の解決策にもなります。この場合、 機能の切り替え が実行可能な解決策になる可能性があります。
@MathewFoscariniの今や削除された答えの考えを拡張したいと思います。
問題のコードの周囲に抽象化（最も単純なケースではインターフェース）を作成します。問題のコードをそのコードの実装にして、新しい要件に適合する新しい実装を作成します。必要に応じて、古い実装を独自のモジュールに移動して、本番用にパッケージ化されないようにします。
要約すると、クラスの実装の詳細を頻繁に変更しているため、オープンクローズの原則に違反しています。これを解決するには、共通のインターフェースを導入し、正しい実装を使用するようにアプリケーションを構成する必要があります。
私はあなたがその前提の下で操作するべきではないと思います。必要になるかもしれません。それがなくて必要な場合は、ソリューションを再作成するために、この不釣り合いな時間がかかります。このソリューションはとても素晴らしいので、誰も二度とそれを考えることはありません。
可能であれば、除外されるコードのこの行に基づいて合格する単体テストを記述します。テストについての何かは、なぜこのコードをそこに置くのがもはや良い考えではないのかを教えてくれるはずです。
これで、ソース管理、テスト、およびその他のドキュメント、プロジェクト、またはリクエストの追跡に文書化されました。
目標は、追加する最も便利な方法を見つけることではなく、変更を加える前に、アプリケーションの特定の領域に関するすべてのリソースを信頼して確認することです。コードでメモリを単独で使用するか、不要なプロンプトを使用するだけでは十分ではありません。保存されたコードが役に立たなくなるような変更が他にあるかどうかは誰にもわかりません。
YAGNI
私の実用的なアプローチは、コードをコメントアウトしてチェックインするという細かいことです。これには、以前のコードが見ている人にすぐに表示されるという利点があります（私たちが知っているように、バグはしばしば導入され、すぐに発見されるため、そこに古いコードを残しておくと、バグを探している誰もが、問題のある変更がどこにあるかを見つける可能性がはるかに高くなります。
ただし、コメントアウトしたコードは、次に編集のためにチェックアウトするときに削除できるという考えもあります。そのため、コードを取得してコメント化されたコードを確認すると、その有用性は過ぎており、安全に削除できます。コメントアウトされたコードは、1回のチェックインでのみ有効になります。 （もちろん、コメント化されたコードのみが削除されたコードをチェックインすることはありません。コードを再度確認する必要がない場合は、コメント化されたコードが表示されないため、コードの周囲の領域を変更した場合のみです）。
明らかにそれは非常に大まかなガイドラインであり、私はとにかく少し毛深いと思うコードをコメントアウトするだけです。
コードが再び使用される可能性があることがわかっている場合は、未使用のメソッドとしてコードをリファクタリングし、将来の使用に備えて利用できるという事実を文書化します。
削除する必要がある場合、または削除する必要がある場合は、何らかの形式のタグ付けや、後で検索できるREMOVED:などの標準コメントの使用を検討します。