別のチームメンバーによるTFSバージョン管理の変更の上書きを防ぐ方法
背景：UIテストエンジニアとしてこの質問をしています。 TFSリポジトリでTFVCを使用している小さなソフトウェアチームがあります。 Mantisバグ追跡システムを使用して、問題をフォローアップします。
状況は次のとおりです。プログラムを手動でテストしているときに、バグを見つけて開発者に報告しました。数日後、開発者から問題が解決したことが通知されました。ある日、バグが解決されたかどうかを確認するためのテストを開始しましたが、まったく同じバグが見つかりました。
問題：バグを修正するために、誰かがコードを変更しました。数日後、コードが再び変更され、バグがプログラムに再び導入されました。これがTFVCの自動マージ機能が原因で発生したのか、それともその修正について知らなかった別のプログラマーが変更を加えたのかはわかりません。
質問：このようなエラーが発生しないようにする方法はありますか？それとも、コードを元の形式に戻した開発者のずさんな作業ですか？
このタイプのシナリオの発生を回避するために連携する2つの手法があります。
ステップ1：バグを修正する前に失敗したテストを記述します
バグが見つかった場合、最初に行うことは、バグが修正されたときに合格するテストを作成することです。そのため、バグが存在している間はテストが失敗します。その後、開発者はバグを修正し、その過程でテストに合格します。
このようにして、2番目の開発者が修正を元に戻すと、テストは失敗し、バグを（再）導入しているという事実を警告します。
ステップ2：プルリクエストを使用
変更をTFSに直接コミットするのではなく、代わりにプルリクエストを使用します。このようにして、各変更は、変更を行った開発者以外の誰かによってチェックされます。これにより、すべての変更がコードレビューされることが確実になります。これは、この質問で説明されているような問題を防ぐだけでなく、コードレビューに関連するコード品質に関する他の多くの利点を提供します。
テストとコードレビューの失敗についてのDavid Arnoの提案に心を込めて2番目に述べました。また、将来そのようなエラーの影響を受けにくくするためのコードを作成する方法もしばしばあります。
たとえば、前提条件が満たされる前に関数を呼び出すことによってエラーが作成された場合は、クラスを異なる方法で分割して、コンパイラエラーを作成することができます。特別なケースを処理するのを忘れている場合は、特別な処理を1つの中央の場所に移動できます。変数を初期化せずに使用することがある場合は、コードを変更して、有効な値を入力するまで変数が作成されないようにすることができます。インライン検証コードの目的が明確でない場合は、わかりやすい名前の関数に移動してください。コードで意図を明確にする方法が思いつかない場合は、少なくとも少なくともに、変更を加えた理由を説明するコメントを追加してください。
その考えは、なぜあなたの修正がそこにあるのかをベルとして明確にすることです。そのため、次に来る人はそれが間違いだとは思わないでしょう。これは、修正によって誤って別のバグが発生した場合に特に重要です。コードが間違いまたは偶然のように見える場合、次の開発者がそれを取り消すだけです。コードの意図を簡単に見分けることができる場合は、次の開発者が、修正したバグを再導入することなく、誤って導入したバグを修正します。