コードをコメントアウトしてから、徐々に削除して、すでに行ったことと今後行うことを追跡するのはなぜ間違っているのですか？

コードの大部分を変更する必要があることがわかったときは、それが間違っているか、他の理由で必要となる主要なアーキテクチャの変更に適応する必要があるため、これは私が通常行うことです：

1. 変更が必要と思われるすべてのコードをコメント化します。コメントアウトされたコードは、TODOリストの一種として扱います。
2. コメントアウトされたコードを徐々に確認し、このコードの一部のコメントを外すか、必要に応じてコピーアンドペーストして必要に応じて編集するか、このコードの一部を最初から書き直して、コメントアウトされたコードを参照します。コメントアウトされたコードの一部が完了したと思うたびに、それを削除します。
3. コードがコメントアウトされなくなるまでこれを続けます。

私は主に、私が単独で開発している個人プロジェクトでこれを行っていることに注意する必要があります。

しかし、私はこれをやめるべきだと言われました。代わりに、コメントアウトされたコードを残すのではなく、古いコードを見るために古いコミットを参照してgitを使い始めるべきだと言われました。私が言われた：

コードをコメントアウトするのは悪い習慣であり、一掃する必要があります。経験がないため、それを理解できません。数年後に、コードをコメントアウトするのが好きな別の人のコードを見つけた場合、自分でこの人を非難するでしょう。コメントアウトされたコードを見るたびに、私はそれを見ずにその全体を削除します。通常、そのようなコードは完全に価値がないからです。小規模な個人プロジェクトでは、コードをコメントアウトすることのマイナス面を確実に見落とすでしょう。しかし、あなたが仕事を見つけて、この習慣をそこに保つならば、それは残念です。

私が今見逃していることの、私がやっていることのこれらの欠点は何ですか？

私は、過去のコードを見るためにgitを使用することだけに熱心ではないと言わなければなりません。私が言ったように、私はコードをコメントアウトすることを一種のtodoリストとして扱います。gitは、コードが以前どのように表示されていたかを示しますが、コードのどの部分がまだレビューが必要で、どの部分がすでに実行されているかを明確に示すことはできません。コードの一部を見逃し、バグを導入する恐れがあります。

完全を期すために、引用している人は経験豊富な開発者であり、ボブおじさんの「クリーンコード」のファンであると付け加えるべきだと思います。

最終的にコメントアウトされたコードをすべて削除しても、実際の問題は見当たりません。コメントベースのコードをコードベースに残しておくことは悪い習慣ですが、それをすべて実行して排除する場合、それはあなたがしていることではありません。あなたが話している人は、あなたが使用しているプロセスを理解していないか、独断的になっていると思います。

実際には、コメントされたコードは無害です。問題は、面倒で読みにくくなることです。はるかに悪い罪がありますが、それを除去することは非常に簡単なことです。コードをコメントアウトした人は、完全に削除できると判断するのに最適な立場にあります。

多くのIDEとコードエディターは、コメント内のある種の「TODO」構文を理解しています。これは、変更が必要なものをマークする代替方法です。あなたがそれをマークしたときにあなたが考えていたことについてもう少し情報を与えるので、あなたはこれを検討したいかもしれません。

一日の終わりには、あなたにとって最良の結果が得られるように物事を行います。これがチームプロジェクトであったとしても、コメントされたコードをすべて削除する限り、他の人に負担をかけることはありません。

私が今見逃していることの、私がやっていることのこれらの欠点は何ですか？

おそらく、単独で作業し、バージョン管理を使用せず、この方法で問題ないと感じた場合は、どれもありません。

実際、バージョン管理がなければ、コードは常にオペレーティングシステムのように現在のファイルが「保存」されている状態であるため、「時間」のどの時点で何をするかは重要ではありません。

バージョン管理を使用し、「todoリスト」として大量のコメントがあり、その一部を修正してコメントを削除し、繰り返し、次に繰り返すなどの場合、「作業中」のコードとコメントが保存されます。改訂履歴で。これは、後で別のコミットにロールバックしたり、「チェリーピック」する必要がない場合は問題になりません（たとえば、特定のコミットを取得して、使用する別のブランチにプルする場合）。しかし、そうでなければ問題になるかもしれません。

おそらくこれは、Windowsが持っていた（復元のこと）ハードドライブソフトウェアの「スナップショット」と比較できます。ウイルスが含まれるスナップショットを取得した場合、ウイルスを殺しますが、後でロールバックする必要があり、ウイルスが再び存在するポイントに戻ることができます。

このアプローチでもありそうなバージョン管理を使用する場合の問題であることをと、他の開発者との仕事を、彼らが見てきたように、あなたのそれらへの使用を持っていないToDoリストを。実際、彼らは無視して回避しなければならない混乱です。私たちのチームでは、古いコードや「メモ」などのすべてのコメントを常に削除します。それらが有用でない限り-しかし、これは「どのように機能するか」に関するドキュメントと、何をする必要があるかを追跡するためのソフトウェア（別名todo）があるため、これは非常にまれです。

また、大規模なプロジェクトで作業する場合は、コラボレーションし、頻繁にコミットしてプッシュする傾向があるため、作業中のブランチがブランチをマージした場合、TODOリストがある可能性があります。それからあなたのTODOリストは皆のビジネスです：D

要約すると、単独で作業しない場合、特にバージョン管理を使用している場合は、履歴が乱雑になり、他の開発者が混乱する可能性があります。

そして、これはいくつかの点で個人的なことですが、コードベースを「todoリスト」として使用することは理想的ではありません。ある日、偶然に何かを残したり、間違ってコメントしたりコメントを外したりすることがあります。

アーキテクチャ、コーディング、および個人的またはチームの仕組みに対する多くのアプローチと同様に、各シナリオは異なるものを必要とする可能性があります。したがって、前述の欠点と、バージョン管理を使用する利点を考慮し、それが機能するかどうかを判断してください。

あなたのレビュアーは少し独断的なようです。コードをコメントアウトしたことを誰かに誓うのはPCであるとは確信していません;-)、さらには;-)

しかし、もっと真剣に、あなたのレビュアーは正しいと思います、あなたは真剣にgit（または他のソース管理システムですが、gitは賢明な選択です）の使用を検討すべきです。

そして、そうすることで、コードをコメントアウトする必要性の一部が緩和される可能性があります。

しかし、コード内にTODOリスト（箇条書きまたは古いコード）を含めることは、私の意見では非常に合理的です。しかし、あなたはそれをどうするかについて少し考え直したいかもしれません。一つには、他の誰かがあなたのコードを読んでいると考えることをお勧めします。プロジェクトをドロップして再参加してから1年後に、他の誰かがあなたになる可能性があります。または、完全に他の誰かである可能性があります。コメントアウトされたコードに遭遇するだけで少し混乱します。たぶん次のようなもの：

/*
 * Need this sort of functionality added back before too long:
 * .... OLD CODE HERE
 */

個人的に、私はこのようなものにもっと傾いています：

 * TODO:
 *      @todo   Possible get rid of intermediate LRUCache_ object.
 *
 *      @todo   Find some reasonable/simple way to get
 *              LRUCache<PHRShortcutSpec, PHRShortcutSpec, PHRShortcutSpecNoAuthCacheTraits_>   sRecentlyUsedCache (kMaxEltsInReceltlyUsedCache_);
 *              Working with ONE T argument
 *              Add(elt2cache).
 ...

また、古いコードから「コードスニペット」を有用なものとして自由に挿入できます。

gitの使用は困難です（悲しいことに）。学ぶには少し時間がかかりますが、あなたが達成しようとしていることの一部ではないように感じるかもしれません。しかし、あなたが便利にプログラムするつもりなら、チームの一員としてそれを行うことを学び、チームとコミュニケーションをとる必要があります。そして、gitはまさにそれが今日行われている方法です。そして、一度使用すると、非常に役立つツール/松葉杖が見つかり、ソフトウェア開発が容易になります。

幸運を祈ります！

コードをコメントアウトする多くの理由があります-

• まだ正しくありません。準備ができたらコメントを外します。
• デバッグ中に動作を変更するために一時的にコメントアウトしています。
• コードが必要かどうかはわかりませんが、さらにテストするまでコードを削除しないでください。
• ソフトウェアの一部のバージョンではコードが必要ですが、これは必要ありません。
• コードは時代遅れですが、書くのに何年もかかり、あなたは感情的にそれを愛しています。それに、いつか役に立つかもしれません。

問題は、コードをベッドに置いてから、数年後に戻ってメンテナンスを行うときに発生します。コードベースにはコメントアウトされたコードが散らばっています。なぜそれがそこにあるのかはもはや明確ではなく、今では混乱しています。

半分まともなバージョン管理ツールを使用する場合、不要になったコードは大胆に削除できます。バージョン管理システムに保存されているため、安全です。バージョン間のファイル差分により、削除されたものが明らかになります。バージョン管理を実装したら、コメントアウトする必要があるのは一時的なものだけです。実際に作業していないファイルでコメントアウトされたコードを見つけた場合は、削除するだけです。

これを行うように指示する他のリソースがたくさんあるので、1人のプロジェクトでもソース管理を使用する必要がある理由を繰り返すつもりはありません。しかし、現在のアプローチに関連する大きな欠点の1つは、コードをコメントアウトすると、IDEからコードを隠すことです（IDEを使用していない場合は、おそらく検討する必要があります）。

たとえば、メソッドまたはクラスの名前を変更する場合、またはメソッドが取るパラメーターの数を変更する場合、IDEにはこれを行うためのリファクタリングオプションが必要です。これにより、すべての適切な参照が検索され、それに応じて更新されます-しかし、おそらくtコメントを検索します。

どこで変更を加える必要があるかを推測するのではなく、変更を加えて、変更が原因でどこで問題が発生したかをIDEに知らせます。その後、コードをより外科的にコメントアウトし、できれば壊れたものを修正する前に短期間でコメントアウトすることができます。

それは悪いです、あなたは停止する必要があります。

その理由は、一度に大量のリファクタリングを試行することに要約されます。

コードの大部分をコメントアウトし、少し修正してチェックインすると、機能しないコードがチェックインされます。そして、他の人が推測するコメントアウトされたものの全体は古いものであり、無視することができます

頻繁にチェックインしない場合、マージの競合が蓄積され、段階的な進行状況は記録されません。

途中でやめなければならない場合でもすべてが機能するように、作業方法を変更する必要があります。

赤ちゃんの手順を実行し、それぞれの後にチェックインします。

• インターフェースを抽出する
• テストを書く
• 関数をリファクタリングする

大量のコードをコメントアウトして「自分のもの」としてマークしないでください。コードが完成するか失敗するまで、自分で作業するためにそれらを取り去ってください。

何をする必要があるかを追跡する必要がある場合は、スクラムやトレロなどのタスクボードを使用します