11

見つけやすさの理由でリポジトリにチェックインされたコメントアウトされたコードを使用するための有効な代替手段はありますか?

私が質問する理由は、コメント アウトされたコードのチェックインについて、最近仲間の開発者と話し合ったからです。私のスタンスは、コメント アウトされたコードは、技術的にはコードベースの一部ではないため、VCS にチェックインするべきではないということです。

彼の反論は、彼がチェックインしたコメントアウトされたコードのいくつかは、彼が将来修正したいいくつかの作業をまだ示しているというものでした (この特定のポイントでは、コメントアウトは 2 年前に発生しましたが、それは重要ではありません)。彼はそれをコードベースに保持して簡単に見つけられるようにしたいと考えていました。現在はコンパイルされていませんが、グローバル行で正しい解決方法を示していました。

最終的に、彼は、コメントアウトされたコードが属していないことに同意しました。しかし、彼に代わる可能性のあるものを考えていたとき、私たちはかなり不足していました.

私が考えることができる唯一のオプションは次のとおりです。

  • Wiki : Wiki のどこかに貼り付けるだけです。これの欠点は、コードに関係のない他の wiki コンテンツと混ざってしまい、検索が難しくなる可能性があることです。
  • すべての VCS リビジョンにインデックスを付ける: これは主に理論上の話ですが、コードベースとその履歴全体を検索可能にするシステムはありますか?

誰かが代替案を知っている/使用していますか? どちらのオプションも実際の価値よりも多くの作業のように聞こえますが、コメントアウトされたコードはとにかく価値がないという私の推論によって歪められている可能性があります。「ちょっと、修正する時間がないのなら、とにかくコードベースにとどまるほど重要ではない」というルートに行かなければならないのは嫌です(ただし、実行可能な代替手段がない場合は修正します)。

ひどいタイトルで申し訳ありません。これ以上のタイトルが思いつきませんでした。

4

7 に答える 7

4

ここでは分岐が役立ちます。SCM を使用する 1 つのモデルは、機能ごとにブランチを作成することです。これは、ブランチのマージが簡単な場合に人気があります - すべての SCM では提供されない容易さです ... :-)

作業する機能ごとに専用のブランチがあり、そのブランチ内で完全に作業するという考え方です。機能が完成し、動作し、テストされ、文書化され、オリンピックで 2 つの金メダルを獲得した場合などに、ブランチはトランクにマージされます。あるいは、機能が完成しない、または放棄されないなどの場合、ブランチは無期限に開いたままになります。しかし、コードは表示されたままになり、いつか誰かが拾う準備が整います。

これは「進行中の作業」を保存するのに適した方法です。コードが分岐されているため、仮のコードを自由にチェックインできます。進行中の変更はその分離されたブランチのみにあるため、コメント アウトする必要はありません。また、これらのブランチは通常、成熟度に達するまで継続的インテグレーションに移行されないため、コンパイルする必要さえありません。

コメントアウトされたコードとは異なり、これらの一時的なコードの変更は表示および検索可能であり、コード分析ツールやリファクタリングなどに適しています。

一部の環境では、機能とそのブランチに変更チケットまたは問題追跡 ID が関連付けられている場合があります。これにより、重大な変更が失われることがなくなり、ショーストッパーの修正から、おそらく日の目を見ることのない別の方法を実装するための実験まで、さまざまな機能の優先順位を付けて整理する手段が提供されます。

検索に関しては、一部の SCM には検索フロントエンドがあります。たとえば、SVN には SVNSearch - http://sourceforge.net/projects/svn-search/があります。ヘッドだけでなく履歴も検索できるsvnqueryもあります。

于 2010-06-04T09:47:09.760 に答える
3

コードが使用されなくなったことは理解していますが、将来的に興味深いアイデアが含まれています。

コントロール バージョン システムに保存しますが、別のフォルダーに保存しますremoved-code-to-review-later。. その後、見直し次第削除します。

于 2010-06-04T09:44:08.950 に答える
2

彼がチェックインしたコメントアウトされたコードのいくつかは、彼が将来修正したいいくつかの作業をまだ示していました

次に、バグトラッカーで優先度の低いチケットを開き、何を修正したいかを説明し、現在コメントアウトされているコードをコメントとしてそのチケットに追加する必要があります。今、彼はそのチケットを自分自身に割り当てることができ、他の誰もそれを気にすることはありません.

コメント アウトされたコードは、他のコメントと同じです。適切に管理されていないと、コードとの一貫性が失われ、有用性が失われる傾向があります。

于 2010-06-04T10:14:51.910 に答える
1

あなたの友人はブランチを作成し、そこで「改善」を試す必要があるようです。この改善ブランチと現在のソースを簡単に比較して、彼が意図している変更を明確に表現することができます。

于 2010-06-04T09:39:31.970 に答える
1

私の経験では、コメントアウトされたコードをチェックインする最大の理由は、開発者がタイピングを非常に嫌い、未使用のコードを手元に置いておきたいということです。

あなたのケースは少し異なりますが、私はまだ「使うか失うか」と言います。コメントアウトされた解決策が何か重要な問題を修正する場合、それはそれを終了するための良い動機になります。何かが正しくない理由や、「それを修正する時間が与えられなかった」ことを説明するのに、実際にかかるよりも多くの時間を費やすのは簡単です。

最後のポイントは、開発者の時間は直線的ではないという主張に基づいており、やる気のある何かに着手することは、毎回「プロジェクト Y に予約された X 時間」よりもはるかに多くの価値をもたらします。

ブランチの作成とマージに非常に優れたバージョン管理システムがあります。Mercurial、git などはすべてこれを行うことができます。これらのいずれかをメインの VCS として使用しない場合でも、同僚が実験を保存するためにローカル リポジトリを作成するのを止めるものは何もありません。

于 2010-06-04T09:56:27.780 に答える
1

いくつかのシナリオでは、参考のために、いくつかの複雑/固有の問題に対する解決策を文書化することをお勧めします。ただし、コードに含める必要はないと思います。IMHO ある種の Wiki が最良の選択肢だと思います。

過去 2 年間コードを使用していない場合、それを使用する予定はありますか? また、使用する場合は、2 年前のコードを引き続き使用する必要がありますか? そのロジックをコードに再度追加する必要がある場合は、最初から記述したほうがよい場合があります。おそらく、その間に状況が変化し、多くのことを学び、追加のリソースが利用できるようになるからです。

于 2010-06-04T10:01:08.567 に答える
0

あなたの声明「現在はコンパイルされませんが、グローバル行でそれを解決する正しい方法が示されました。」

<>

あなたの声明「コードをコメントアウトした私の推論は、とにかく価値がありません。」

コメントを残すことに害はないと思います。コメントは、元の開発者の意図が何であったか、および既存のコードの現在の制限について、将来の開発者に洞察を提供することが多いためです。別のシステムに保存すると、将来の開発者がそれらを紛失する可能性が高くなります。バイトは安く、別の開発者の意図を再現するのにかかる時間は $$$ です。

于 2010-06-04T17:27:28.110 に答える