コードをコメントアウトしてから徐々に削除して、すでに行ったことと行っていないことを追跡するのはなぜ間違っているのですか？
コードの大部分を変更する必要があるとわかったときは、コードが正しくないため、または他の理由で必要となる主要なアーキテクチャの変更に適応させる必要があるため、通常は次のようにします。
- 変更する必要があると思われるすべてのコードをコメント化します。コメントアウトされたコードをTODOリストの一種として扱います。
- コメントアウトされたコードを少しずつ確認し、このコードの一部のコメントを外すか、他の場所にコピーアンドペーストしてから必要に応じて編集するか、このコードの一部をゼロから書き直し、コメント化されたコードを参照して確認します。コメントアウトされたコードの一部が完了したと思うたびに、それを削除します。
- コメントアウトされたコードがなくなるまでこれを続けます。
これは主に、私が単独で開発している個人プロジェクトで行っていることに注意してください。
しかし、私はこれをやめるべきだと言われました。代わりに、コメントアウトしたコードを残すのではなく、古いコードを確認するために古いコミットを参照して、代わりにgitを使い始める必要があると言われました。私が言われた：
コードをコメントアウトするのは悪い習慣であり、一掃する必要があります。あなたは経験が足りないのでそれを理解できません。数年のうちに、コードをコメントアウトするのが好きな別の人のコードを見つけた場合、あなたは自分がその人に悪態をつくようになります。コメントアウトされたコードを見るときはいつでも、それを見ることさえせずに、コード全体を削除します。通常、そのようなコードはまったく価値がないためです。小さな1人のプロジェクトでコードをコメントアウトすることのマイナス面を見ることはできません。しかし、あなたが仕事を見つけて、この習慣をそこに保つならば、それは残念です。
現在見落としていることで、私がしていることのこれらの欠点は何ですか？
過去のコードを見るのにgitだけを使うことにあまり熱心ではないと私は言わなければなりません。私が言ったように、私はコードをコメントアウトすることを一種のtodoリストとして扱います。 gitはコードが以前どのように見えていたかを示しますが、コードのどの部分がまだレビューする必要があり、どこがすでに完了しているかを明確に示すことはできません。コードの一部を見逃してバグが発生するのではないかと心配です。
完全を期すために、私が引用している人物は経験豊富な開発者であり、ボブおじさんの「クリーンコード」のファンであると付け加えるべきだと思います。
最終的にコメント化されたコードをすべて削除した場合、これに関する実際の問題は発生しません。コードベースにコメント付きのコードを残すことは悪い習慣ですが、それをすべて試し、それを排除する場合、それはあなたがしていることではありません。私はあなたが話している人があなたが使用しているプロセスを理解していないか、独断的であると思われます。
実際には、コメント付きのコードは無害です。問題は、乱雑で読みづらいことです。もっと悪い罪がありますが、それを取り除くのは非常に簡単です。コードをコメントアウトした人は、コードを完全に削除できると判断するのに最適です。
多くのIDEとコードエディターは、コメント内のある種の「TODO」構文を理解しています。これは、何を変更する必要があるかをマークする別の方法です。マークを付けたときに何を考えていたかについて、もう少し情報が得られるので、これを検討することをお勧めします。
結局のところ、あなたにとって最良の結果をもたらすような方法で物事を行います。これがチームプロジェクトであっても、コメント付きのコードをすべて削除する限り、他の人に負担をかけることはありません。
現在見落としていることで、私がしていることのこれらの欠点は何ですか？
おそらく、あなたが一人で作業していて、バージョン管理を使用せず、この方法でそれを行うのは大丈夫だと感じる場合は、間違いありません。
実際、バージョン管理がなければ、コードは常にオペレーティングシステムのように現在のファイルが「保存」されている状態であるため、「時間」のどの時点で何をしても問題はありません。
バージョン管理を使用していて、「todoリスト」として大量のコメントがあり、一部を修正してコメントを削除した後、繰り返してから繰り返すなど...「作業中」のコードとコメントが保存されている変更履歴。別のコミットにロールバックしたり、後で「チェリーピック」する必要がない場合、これは問題になりません（たとえば、特定のコミットを取得して、使用する別のブランチにプルする場合など）。しかし、それ以外の場合は問題になる可能性があります。
おそらくこれは、Windowsが持っていた（復元機能）のようなハードドライブソフトウェアの「スナップショット」と比較できます。ウイルスが含まれているスナップショットを撮った場合、ウイルスを殺すが、後でロールバックする必要がある場合は、ウイルスが再び存在するポイントに戻ることができます。
このアプローチも可能性が高いバージョン管理を使用するときに問題になるand他の開発者と連携するため、彼らはyour todoリストを参照する必要がある彼らには役に立たない。実際、彼らが無視し、回避しなければならないのは単なる混乱です。私たちのチームでは、古いコードや「メモ」などのすべてのコメントを常に削除します。それらが役に立たない限り-しかし、これは「それがどのように機能するか」に関するドキュメントと、実行する必要があることを追跡するためのソフトウェア（別名todo）があるため、非常にまれです。
また、大規模なプロジェクトで作業する場合は、共同作業を行い、頻繁にコミットしてプッシュする傾向があるため、彼らが作業しているブランチがTODOリストを持っている可能性があります。次に、あなたのTODOリストはみんなのビジネスです：D
要約すると、あなたが一人で作業していない場合、特にバージョン管理を使用している場合は、履歴が乱雑になり、他の開発者にとって乱雑になる可能性があります。
そして、これはいくつかの点で個人的なことですが、「todoリスト」としてコードベースを使用することは実際には理想的ではありません。ある日、誤って何かを残したり、誤ってコメントしたり、コメントを外したりすることがあります。
アーキテクチャ、コーディング、および個人またはチームの作業に対する多くのアプローチと同様に、シナリオごとに異なるものが必要になる場合があります。したがって、言及された欠点とバージョン管理を使用する利点を検討し、それがyoで機能するかどうかを判断してください。
あなたのレビュアーは少し独断的なようです。コードをコメントアウトするために誰かを罵るのがPCであるとは確信していません;-)、または役立つかもしれません;-)
しかし、もっと真剣に、私はあなたのレビュアーIS正しいと思います。git（または他のソース管理システムですが、gitは賢明な選択です）の使用を真剣に検討する必要があります。
そうすることで、コードをコメント化する必要性を軽減することができます。
しかし、コード内にTODOリストがあること（箇条書きのリストでも古いコードでも）-私の意見ではかなり合理的です。しかし、あなたはそれをどのように行うかについて少し考え直したいと思うかもしれません。一つには、誰かがあなたのコードを読んでいることについて考えることをお勧めします。プロジェクトに参加して1年後、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は、今日、まさにそれが行われている方法です。そして、あなたがそれを使い始めたら、それはあなたのソフトウェア開発をより簡単にする非常に役立つツール/松葉杖を見つけるでしょう。
がんばって！
コードをコメントアウトする理由はたくさんあります：-
- まだ正しくありません。準備ができたらコメントを外します。
- デバッグ中に動作を変更するために一時的にコメントアウトしています。
- コードが必要かどうかはわかりませんが、さらにテストするまでは削除しないでください。
- 一部のバージョンのソフトウェアではコードが必要ですが、このバージョンでは必要ありません。
- コードは古くなっていますが、書くのに何年もかかり、感情的にコードに執着しています。また、ある日役立つかもしれません。
問題は、コードをベッドに置き、2、3年後にコードに戻ってメンテナンスを行うときに発生します。コメントベースのコードが散らばったコードベースが見つかります。それがなぜそこにあるのかはもはや明確ではなくなり、現在は混乱しているだけです。
中途半端なバージョン管理ツールを使用している場合は、不要になったコードを大胆に削除できます。バージョン管理システムにまだ保存されているため、安全です。バージョン間のファイルの違いは、何が削除されたかを明らかにします。バージョン管理を実装した後、コメントアウトする必要があるのは一時的なものだけです。実際に作業していないファイルでコメント化されたコードを見つけた場合は、それを削除できます。
これを行うように指示するリソースは他にもたくさんあるので、1人のプロジェクトでもソース管理を使用する必要がある理由を繰り返すつもりはありません。しかし、現在のアプローチの主な関連する欠点の1つは、コードをコメントアウトすると、IDE（IDEあなたはおそらくそれを考慮する必要があります）。
たとえば、メソッドまたはクラスの名前を変更する場合、またはメソッドが取るパラメーターの数を変更する場合、IDEには、これを行うためのリファクタリングオプションが必要です。それに応じて更新してください-しかし、おそらくコメントを検索しません。
変更が必要な場所を推測するのではなく、変更を加えて、IDEに変更が原因で問題が発生した場所を通知させます。その後、より外科的にコードをコメントアウトできます。そして、うまくいけば、壊れたものを修正する前に、より短い期間。
badであり、stopを使用する必要があります。
結局のところ、大量のリファクタリングを一度に実行しようとすることが原因です。
コードの大きなセクションをコメントアウトし、少し修正してチェックインすると、機能しないコードがチェックインされたことになります。そして、他の人が古くて無視できると想定するコメントアウトされたもののすべての負荷
頻繁にチェックインしない場合、マージの競合が蓄積され、段階的な進行状況が記録されません。
途中でやめなければならない場合でもすべてが機能するように、作業方法を変更する必要があります。
ベビーステップを踏み、それぞれの後にチェックインします。
- インターフェースを抽出する
- テストを書く
- 関数をリファクタリングする
コードの大きなチャンクをコメントアウトして「自分のもの」としてマーク付けしないでください。それらが完了するまで、または失敗するまで、自分で作業するために取り除いてください。
何をすべきかを追跡する必要がある場合は、スクラムやトレロなどのタスクボードを使用してください