変数に基づいて何かを計算しようとして、2週間頭を悩ませました。
一時的に別の問題を解決するために以前に変数を設定し、それを修正するために戻ったことはありませんでした。
通常、私はコードを// ToDoでマークアップして、一時変数を削除するように通知しようとします。
この場合、いくつかの問題を修正しようとしてスキップしていたので、マークを付けませんでした。（何が起こっているのかわからなかったので、いろいろ試してみました！）
後で削除したい一時変数をどのようにマークしますか？
後で削除する必要がある変数をマークするためのベストプラクティスは何ですか？
（もちろん、本当に組織化された脳を持っていることを除いて...）
注釈を使用する@Deprecated
@Deprecated
public void Test() {
//
}
私も興味があったので、ちょっとググった後に見つけました。
@Deprecated
public void speak() {
System.out.println("Meow.");
}
ウィキペディアから、Java 注釈について:
Java は、言語に組み込まれている一連の注釈を定義します。Java コードに適用される注釈: @Override - 関数がオーバーライドであることを確認します。関数が親クラスの 1 つに見つからない場合、コンパイル警告が発生します。@Deprecated - 関数を古いものとしてマークします。関数が使用されている場合、コンパイル警告が発生します。@SuppressWarnings - 注釈パラメーターで指定されたコンパイル時の警告を抑制するようにコンパイラに指示します。他の注釈に適用される注釈: @Retention - マークされた注釈の格納方法を指定します—コードのみ、クラスにコンパイル、またはリフレクションによって実行時に使用可能. @Documented - ドキュメントに含める別の注釈をマークします。
ベスト プラクティスは、バージョン管理を使用することです。バグを修正したら、git/hg/svn diff を実行して、最後のコミット以降に行ったことを確認し、一時的な変更を削除できます。他のバグを修正する必要があるが、「一時的な変更」を複数のコミットに保持する必要がある場合は、部分的なコミット (git add --patch または hg qrecord) を実行して、「一時的な変更」がコミットされて忘れられることがないようにすることができます。非常に大きな一時ファイルの場合 (ベスト プラクティスではありませんが、発生する可能性があります)、通常のコードをリベースし続けるローカル ブランチを作成できます。「一時的な変更」を確実に削除したら、コミットされていない変更をクリーンアップして、問題をテストできます。
ローカル ブランチ (git、IntelliJ でのシェルビングの変更、ローカルでチェックアウトされたソースの 2 つのコピー)、したがって、あるタスクから別のタスクに移動するときは、途中で完了した作業を単に処理するのではなく、2 つ目のブランチを作成して実行しません。完了するまで最初のものをコミット/プッシュしないでください。
コミット/プッシュをペアにする - そのため、コードの一時的なチャンクを指差してそれについて尋ねる別の人とコードについて話し合うまで、コミットしません。うまくいけば、コミットする前に、気になる問題を修正するよう強制されます。
TODO やその他のコメントは使用しないでください。
すでに公開されており、外部で使用されている場合は、@Deprecate してください。
まず、各変数名の前に「TODO_REMOVE_」などを付けます。そうすれば、削除するのを忘れて、後で誰かがそれを見つけた場合、変数を削除する必要があることは明らかです。また、以下の最後の手順を実行した場合は、チェックインする前に必ず削除します。
次に、TODOコメントを追加し、Deprecatedで注釈を付けます。他の人がTODOは実行されないと言っていることは知っていますが、コミットすると、IDE（この場合はIntelliJ）はX個のTODOがコミットされていることを警告します。チェックイン時に同様のメッセージが表示された場合は、頭に浮かぶはずです。また、これを頻繁に行う場合は、ライブテンプレート、スニペット、またはIDEが提供するその他のものを作成して、クラスタイプと変数名を入力するだけで済みます。
@Deprecated
Object TODO_REMOVE_variableName;//TODO Remove
最後に、変更セットをチェックインする前に、書いたコードのすべての行を読み直し、理解し、改善し、確認しようとしています。これは非常に重要です。特に大きな変更や締め切りが迫っている場合は、最初は気が遠くなるように聞こえるかもしれませんが、コードを書くのにかかった時間の隣のバケツの低下であり、それが明らかにする問題と将来の時間です保存する価値は十分にあります。本当に、私はすべての開発者がこれをしたことを望みます。
すべてのアイデア/推奨事項にコメントする代わりに、私は答えて、この答えに投票してもらうと思いました。
まず、プロセスやアイデアを共有していただき、ありがとうございます。ほんとうにありがとう。
愚かな過ちを犯したり、すでに犯した過ちに苦しんだりすることを避けたいという願望によって動かされるべき多くの要因があると思います。私は（多くの）1つを作りました。
バージョン管理とチームレビューがすべてに勝ると仮定しましょう。ただし、バージョン管理を超えています（適切なコードにクラッポラをコミットしたと仮定します）：
@Deprecatedはとても良いです。あなたを睨みつけているようです。私たちは皆、明白にする必要があります。木々の間から森が見えることを願っています。
私にとって、diffは頻繁に抜本的な変更を加えるので面倒ですが、多くの場合に機能する素晴らしい提案です。
いくつかの注目すべき点：
私は通常、唯一の開発者なので、ToDosに依存しています。それらは使いやすいです。私はtodosを使った非公式の評価システムを持っています。たとえば、実際にクリーンアップする必要があるものは次のようになります。
//TODO * Might be a future crash here // where one star is something I really have to clean up before I ship.
//TODO *** Can some lines be trimmed from this view adapter?
複数の星は任意であり、おそらくオプションですらあります。私はそれらをサイクリングし続けます。@BriGuy37-それは興味深い考えでした。@Sriram-それも面白かった-特定の条件下でタグを設定する。
私の場合、// TODOを実行しなかったので、やけどを負いました。
おそらくこれらすべての中で最大のルールは次のとおりです。
このような愚かな間違いをしないようにあなたの仕事を団結させてください。何をいつ変更するかを知ってください。冷静さを保つ。
再度、感謝します！コミュニティからベストプラクティスをピックアップして、作業に組み込むのは素晴らしいことです。
SVN *を使用していて、変更をコミットする前に修正する必要がある変更（たとえば、ローカルでのデバッグ/テストのための一時的な変更）の場合は、次のようなコメントを追加// STOP-COMMITして、事前コミットフックを設定できます。これは、このテキストを含むファイルをコミットすることを禁止します。
これは、SVNにコミットしてはならない構成ファイルへのローカル変更をマークする場合にもうまく機能します。
IDEが特定の文字列のコメントを検索するTODOリストをサポートしている場合は、この文字列を検索するカスタムTODO形式を作成することもできます。
*他の多くのバージョン管理システムと同様のことができると思います
Eclipseを使用している場合は、次のことをお勧めします
「REMOVE」などの新しいタスク タグを使用すると、削除する必要のある一時コードを簡単に特定できます。優先度を高に設定します。
タスク ビューを開いて REMOVE タスクを確認し、アクションを実行します。
以下のリンクを参照してください (UI スクリーンショットも提供されています)。