9

TFSシェルフセットを使用する理由の1つは、私が同意しないコードレビューのためですが、これは私の現在のプロジェクトで行われている方法です。TFSシェルフセットを使用することがコードレビューに適していない理由は、

  • シェルフセットには、チェンジセットのような自然な順序はありません。これにより、多くのマージの競合が発生する可能性があります。
  • 開発者がレビューされるまでコードをチェックインできない場合、レビュー担当者に依存します。レビュー担当者が短期間でレビューを行わない場合、これらのシェルフセットは他のタスクに干渉する可能性があります。
  • 他の開発者とのコラボレーションは、チェックインコードではなくシェルフセットを渡す必要があるため、面倒になります。これにより、将来、マージの競合が再び発生する可能性があります。

誰かが私にレビューのためのTFSシェルフセットアプローチに賛成または反対のいくつかの指針を提供してくれるので、私はアプローチについて確信するか、このアプローチを使用しない場合のケースを提示できますか?

4

3 に答える 3

11

TFS11とVisualStudio11の新しいコードレビュー機能はシェルフセットを中心に構築されているため、Microsoftはこれについて多くの意見を述べていないと思います。本当の問題は、おそらくチームの運営方法と、製品全体でタスクがどのように分割されているかということです。

依存関係がほとんどなく、同じ領域で作業する人々が緊密に連携するようにタスクが分割されている場合、マージとチェックインに関する問題は発生しません。タスクに時間がかかる場合は、開発ブランチから定期的に最新バージョンを取得して、常に最新の状態に保つようにしてください。

レビューアが遅すぎて、シェルフセットがキューに入れられ、すべてがレビューされるのを待っていることがわかった場合、ここで他の実際の問題が発生する可能性があります。タスクが終了したら、できるだけ早くレビューする必要があります。レビューを待つのはやめましょう。レビューに24時間以上かかる場合、これは実際の問題になる可能性があります。他の誰かによるピアレビューを行うか、チームにさらに多くのレビューアを配置することで、これを軽減できます。

他のすべてが失敗した場合は、事後レビューを行うことができます(シェルフの代わりにチェンジセットをレビューします)。TFS11とVisualStudio11もこのシナリオをサポートします。

私の個人的な好みは、私のチームの開発者を信頼することです。したがって、ほとんどの場合、チェックイン後のレビューを行います。新規または非常に若いメンバーがいる場合は、代わりに、より上級の開発者が最初のチェックイン前のレビューを行えるようにします。

参照:

于 2012-04-29T22:02:58.867 に答える
6

シェルフセットには、チェンジセットのような自然な順序はありません。これにより、多くのマージの競合が発生する可能性があります。

ここであなたの主張がわかりませんが、あなたにとっての「自然な秩序」とは何ですか?チームで作業を開始するとき、チェンジセットの年表は特定の順序に従いません。

開発者がレビューされるまでコードをチェックインできない場合、レビュー担当者に依存関係を置き、レビュー担当者が短期間でレビューを行わない場合、これらのシェルフセットは他のタスクに干渉する可能性があります。

繰り返しになりますが、「通常のタスク開発」でも同じ状況が発生します。これは、タスクBの前にタスクAを開始し、Bの前にタスクAをチェックインするためではありません(BがAに依存している場合を除きますが、ここでは重要ではありません)。 )。タスク開発のワークフローの最終ステップとしてレビューを検討してください。レビューアへの依存は確かに物事をもう少し複雑にしますが、それは安定したビルドを持ち、会社の標準に準拠したコードを持つためです。

チェックインコードではなくシェルフセットを渡す必要があるため、他の開発者とのコラボレーションは困難になります。これにより、将来、マージの競合が再び発生する可能性があります。

棚板よりも簡単なことを知っていますか?変更されたコードをzipファイルで電子メールで送信しますか?参照に影響を与えたくない場合、シェルフセットは開発者間でコードを共有するためのはるかに簡単な方法です。ここでも、あなたが言及しているマージの競合の問題はわかりません。

ここにいくつかのアドバイスがあります:

  1. 誰かが別の開発者の棚セットを取り戻しているとき、たとえば、Dev Aが棚セットを作成し、Dev Bがそれを確認したい場合は、DevBに棚を開けるための別のクリーンで専用のワークスペースがあることを確認します。通常の「開発」ワークスペースで棚上げを解除したくありません。コードレビュー専用のワークスペースにより、前述のマージの競合の問題が緩和されます。

  2. 理論的には、ターゲットブランチに統合する前に、すべてを確認する必要があります。そうは言っても、実際にはそうするのは難しいので、チームにそのようなプロセスの習慣がない場合は、完璧なことをすることを目指しないでください。作業中のアプリケーションをよく知っている上級開発者は、レビュー前にチェックインすることを許可できます。これはすべてトレードオフの問題です。この場合、柔軟性とスムーズな開発エクスペリエンスが得られますが、参照の品質と安定性が低下する可能性があります。ここに本当の勝者はありません、それはあなたにとって何が重要であるかに基づいてあなたの選択です。

  3. コードレビューにブランチを使用しないでください。

  4. シェルフセットを介したコードレビューのエクスペリエンスは、VS / TFSではやや不完全であることに同意しますが、他の方法よりもはるかに優れています。マイクロソフトは、この点でより良い結果が得られることを認識しており、VS11/TFS11で行われた改善につながります。次のバージョンでは、まだシェルフセットに基づいていますが、アクター間のより完全な通信システムを備えた、真のコードレビューエクスペリエンスがあります。この改善は「私の仕事」の経験で行われ、物事は今ではずっとスムーズになっています。tfspreview.comとVS11ベータ版を試してみるか、いくつかのブログ投稿(Brian Harry)を読んで詳細を確認してください。興味のあるリンクは次のとおりです。

于 2012-04-27T08:32:53.573 に答える
2

問題なのは棚板ではありません。ピアがコードをレビューするのを待っている場合、コードの保存方法に大きな違いはありません。とは言うものの、棚セットはコンピューターから離れて、レビュー担当者がアクセスできる場所に安全に保管されているので、他のどのソリューションよりも優れていると思います。別の方法は、チェックインしてチェンジセットを回し、マスターを通過しない場合は元に戻すか、zipを回すかです。どちらにも重大な欠点があります。

では、チェックインする前にコードレビューが必要かどうかという本当の問題はありますか?

于 2012-04-27T05:52:21.453 に答える