コードコミットの前または後のレビュー。どちらが良いですか。
従来、私たちはコミット前にコードレビューを実行していましたが、今日はコミット後にコードレビューを好む同僚と議論がありました。
まず、ここにいくつかの背景があります、
- 経験豊富な開発者が何人かいて、プログラミング経験がほとんどない新規採用者もいます。
- 私たちは製品をリリースするために高速で短い反復を実行したいと考えています。
- すべてのチームメンバーが同じサイトにいます。
私が学んだコミット前のコードレビューの利点：
- メンターの新入社員
- 開発サイクルの早い段階で、エラー、障害、不良デザインを防止するようにしてください
- 他の人から学ぶ
- 誰かが辞めた場合の知識のバックアップ
しかし、私はいくつかの悪い経験もしました：
- 効率が低く、一部の変更は数日で見直される可能性があります
- 特に初心者の場合、速度と品質のバランスが難しい
- チームメンバーの1人が不信を感じた
コミット後のレビューに関しては、私はこれについてほとんど知りませんが、私が最も心配しているのは、レビューの欠如のためにコントロールを失うリスクです。意見はありますか？
更新：
- VCSにはPerforceを使用しています
- 同じブランチでコーディングしてコミットします（トランクまたはバグ修正ブランチ）
- 効率を改善するために、コードを小さな変更に分割しようとしました。ライブダイアログレビューも試しましたが、全員がルールを遵守したわけではありません。これは別の問題です。
Simon Whiteheadがコメントで言及している のように、それは分岐戦略に依存します。
開発者が開発用の独自のプライベートブランチを持っている場合は（とにかくほとんどの場合にお勧めします）、トランクまたはメインリポジトリとマージする前にコードレビューを実行します。これにより、開発者は開発/テストサイクル中に何度でも自由にチェックインできるようになりますが、配信されたコードを含むブランチにコードが入るたびに、レビューされます。
一般に、コードレビューの悪い経験は、解決策があるレビュープロセスの問題のように聞こえます。小さな個々のチャンクでコードをレビューすることにより、時間がかかりすぎないことを確認できます。 150行のコードを1時間で確認できますが、プログラミング言語に精通していない人、開発中のシステム、またはシステムの重要性（安全性の重要性により多くの時間を要します）の速度は遅くなります。この情報は、効率を改善し、コードレビューに参加するユーザーを決定するのに役立ちます。
まだ誰も引用していないように見えるマントラがあります： 早い段階で頻繁にチェックイン ：
ソース管理に何もチェックせずに長期間（つまり1日以上）作業する開発者は、深刻な統合の頭痛の種を抱えています。デイモンプール concurs ：
開発者はチェックインを延期することがよくあります。開発者は、他の人に早すぎる影響を与えたくないし、ビルドを壊したとして非難されたくないので、延期します。ただし、これにより、作業が失われたり、以前のバージョンに戻れないなど、他の問題が発生します。
私の経験則では「早い段階で頻繁にチェックイン」しますが、プライベートバージョン管理へのアクセス権があることに注意してください。チェックインがすぐに他のユーザーに表示される場合、未成熟な変更を導入したり、ビルドを壊したりするリスクがあります。
同僚が何を書いているのかまったくわからないまま長期間行くのではなく、定期的に小さな断片をチェックインしたほうがいいです。 コードがソース管理にチェックインされていない場合、それは存在しません。これはさらに別の形式の Do n't Go Dark だと思います。コードは、何らかの形でリポジトリに存在するまで表示されません。
...早い段階でチェックインすることを学び、頻繁にチェックインする場合、フィードバック、統合、レビューを行うための十分な時間があります...
私はこれに対して異なるアプローチをとるいくつかの会社で働いてきました。コンパイルを妨げない限り、それを許可しました。バグをチェックインすると、もう1つはおかしくなります。前者がはるかに優先されます。あなたは、すべてが後でテストされることを理解しながら、進行中のことについて他の人と協力できるような環境で開発すべきです。
ジェフ・アトウッドの発言もあります： 物事を壊すことを恐れないでください ：
ソフトウェア開発者として改善するための最も直接的な方法は、コードの変更に関して絶対に恐れを知らないことです。壊れたコードを恐れる開発者は、専門家になることは決してない開発者です。
また、ピアレビューの場合も追加します。誰かが何かを変更してほしい場合、元のバージョンの履歴をソースに含めることは非常に貴重な学習ツールです。
私は最近、自分が参加しているプロジェクトでコミット前のレビューを開始しましたが、それがどれほど問題がないかについては嬉しいことに驚きました。
私が見るコミット後のレビューの最大の欠点は、それが多くの場合、1人の個人のみが関係することです：Someoneは、コードが正しいかどうかをレビューしますが、authorは通常重大な間違いがない限り、関与しています。小さな問題、提案、またはヒントは、通常、著者にはまったく届きません。
これは、コードレビューの認識結果も変更します。これは、誰もが（レビュー担当者とコードの作成者）が毎回新しいことを学ぶことができるものとは対照的に、追加作業のみを生成するものと見なされます。
コミット前のコードレビューはとても自然に思えるので、コミット後にレビューを意図的に行うことができるとは思いもしませんでした。継続的インテグレーションの観点からは、作業が完了している可能性のある、不十分に記述された状態ではなく、コードが完了したらコードをコミットする必要がありますよね？
多分それは、私たちのチームで常に行ってきた方法が、非同期のコントロール主導のドキュメントベースのレビューではなく、元の開発者によって開始されたライブダイアログであるためかもしれません。
今日のほとんどのリポジトリは、2フェーズコミットまたはシェルブセット（プライベートブランチ、プルリクエスト、パッチサブミッションなど、呼び出したいもの）をサポートしています。これにより、メインラインにプルする前に作業を検査/確認できます。これらのツールを活用すると、常にコミット前のレビューを行うことができると思います。
また、組み込みのコードレビューを提供する別の方法として、ペアコーディング（ジュニアとのシニアペア）を検討することもできます。車のロールオフ後ではなく、組立ラインでの品質検査と見なしてください。
両方してください：
- コミット前-非常に再利用可能なコードの一部、または主要な設計上の決定など、非常に重要な場合にこの種のレビューを行う
- コミット後-改善される可能性のあるコードについて意見を得たい場合は、この種のレビューを行ってください
正式なレビューは、構成管理下にあるソースファイルに対して行う必要があり、レビューレコードにはファイルのリビジョンが明確に記載されています。
これにより、「最新のファイルがない」というタイプの引数が回避され、誰もがソースコードの同じコピーをレビューすることが保証されます。
また、レビュー後の修正が必要な場合は、履歴にその旨を注釈として付けることができます。
コードレビュー自体については、私の投票はコミットの「実行中」です。
Gerritやclover（私は思う）のようなシステムは、変更を段階的に行い、それが良ければレビュー担当者にソース管理（Push in git）にコミットさせることができます。それは両方の世界で最高です。
それが現実的でない場合は、コミット後が最善の妥協案だと思います。デザインが良ければ、ほとんどのジュニア開発者だけが十分に悪いことをすべきではありません。 （それらの事前コミットレビューを行います）。
どちらがデザインレビューにつながりますか。コードレビュー時に（またはお客様の展開時に）行うことができますが、デザインの問題を見つけることは、コードが実際に記述される前に、それよりも早く行う必要があります。
レビューは、プリコミットとポストコミットの両方から利益を得ます。
レビュー前のコミット
- レビューアが著者の最新のリビジョンをレビューしていることを確信できるようにします。
- 誰もが同じコードをレビューできるようにします。
- レビューアイテムから行われた改訂が完了したら、比較のための参照を提供します。
レビュー中に実行中のコミットはありません
私はアトラシアンのツールを使用しており、レビュー中に実行中のコミットが発生するのを見てきました。これはレビュアーを混乱させるので、私はそれをお勧めしません。
レビュー後の改訂
レビューアーが口頭または書面でフィードバックを完了した後、モデレーターは、作成者が要求された変更を行うことを確認する必要があります。レビュー担当者または作成者が、レビュー項目を過失、提案、または調査のいずれとして指定するかについて意見が分かれる場合があります。不一致を解決し、調査項目が正しくクリアされるようにするために、レビューチームはモデレーターの判断に依存しています。
約100のコードインスペクションに関する私の経験では、レビュー担当者が明確なコーディング標準を参照できる場合、ほとんどの種類のロジックやその他のプログラミングエラーについて、レビュー結果は一般的に明確です。ときどき、ニットを選ぶことについての議論があるか、スタイルのポイントが議論に退化する可能性があります。ただし、モデレーターに決定力を与えることで、行き詰まりを回避できます。
レビュー後のコミット
- モデレーターおよび他のレビュー担当者に、レビュー前のコミットと比較するデータポイントを提供します。
- 欠陥の除去とコードの改善におけるレビューの価値と成功の両方を判断するための指標を提供します。
ピアレビューにより、コントロールを失うリスクが最小限に抑えられます。いつも2人が同じコードについての知識を持っています。彼らは時々切り替える必要があるため、コードを追跡するために常に注意を払う必要があります。
熟練した開発者と初心者が一緒に作業することは理にかなっています。一見するとこれは非効率的なようですが、実際はそうではありません。実際、バグは少なく、修正にかかる時間も短くなっています。さらに、初心者ははるかに速く学習します。
悪い設計を防ぐために何が起こるか、これはコーディングの前に行われるべきです。大幅な変更/改善/新しいデザインがある場合は、コーディングを開始する前にレビューする必要があります。デザインが完成したら、やることはほとんどありません。コードのレビューが簡単になり、時間もかかりません。
私は、コードがすでにスキルを証明している経験豊富な開発者によって作成されている場合にのみ、コミットする前にコードを確認する必要がないことに同意します。しかし、初心者がいる場合は、コミットする前にコードをレビューする必要があります。レビュー担当者は開発者の隣に座り、彼らが行ったすべての変更または改善について説明する必要があります。
私と私の同僚は最近このトピックについていくつかの科学的研究を行ったので、これはかなり古い質問ですが、私たちの洞察のいくつかを追加したいと思います。アジャイルなかんばん開発プロセス/チームのシミュレーションモデルを構築し、多数の異なる状況（異なる数のチームメンバー、異なるスキルレベルなど）について、コミット前とコミット後のレビューを比較しました。 3年の（シミュレーション）開発時間後の結果を見て、効率（完成したストーリーポイント）、品質（顧客が見つけたバグ）、およびサイクルタイム（ユーザーストーリーの開始から配信までの時間）に関する違いを探しました。 。調査結果は次のとおりです。
- 多くの場合、効率と品質の違いはごくわずかです。そうでない場合、コミット後のレビューには品質に関していくつかの利点があります（他の開発者はある意味で「ベータテスター」として機能します）。効率のために、コミット後は小さなチームにいくつかの利点があり、コミット前は大きなチームまたはスキルのないチームにいくつかの利点があります。
- コミット前のレビューは、依存タスクの開始がレビューによって遅れる状況がある場合に、サイクルタイムが長くなる可能性があります。
これらから、次のヒューリスティックルールを導き出しました。
- 確立されたコードレビュープロセスがある場合は、変更しないでください。おそらく努力する価値はありません
- サイクルタイムに問題がない限り=>ポストに切り替え
- または、スリップした問題がデベロッパーを混乱させる頻度が高すぎる=>プレに切り替え
- まだレビューを行っていない場合
- これらのメリットのいずれかに該当する場合は、プリコミットを使用してください
- コミット前のレビューにより、コミット権のない部外者はオープンソースプロジェクトに貢献できます
- ツールベースの場合、コミット前のレビューでは、プロセスが厳格に遵守されていないチームに、いくつかのレビュー規律を適用します。
- コミット前のレビューにより、レビューされていない変更が配信されないようにすることが簡単にできます。これは、継続的な展開/非常に短いリリースサイクルに適しています。
- チームが大規模で、サイクルタイムで問題に対処または回避できる場合は、プリコミットを使用します。
- それ以外の場合（小規模で熟練した産業チームなど）コミット後を使用する
- これらのメリットのいずれかに該当する場合は、プリコミットを使用してください
- 両方の世界の利点をもたらす組み合わせを探します（これらは正式に研究していません）
完全な研究論文はこちらから入手できます： http://dx.doi.org/10.1145/2904354.2904362 または私のウェブサイト： http://tobias-baum.de
チームの構成によって異なります。小規模で頻繁なコミットが得意な比較的経験豊富なチームの場合、コードに2つ目の目を向けるために、コミット後のレビューで問題ありません。大規模で複雑なコミットの場合や経験の浅い開発者の場合は、レビューを事前にコミットしてから、問題が発生する前に修正するのが賢明です。
これらの方針に沿って、適切なCIプロセスやゲートチェックインを使用することで、コミット前（および間違いなく、それらの多くのコミット後）のレビューの必要性が減少します。
私の意見では、コードピアレビューはコミット後の場合に最適です。
分岐戦略を調整することをお勧めします。開発者ブランチまたは機能ブランチを使用することには多くの利点があります...少なくともコミット後のコードレビューを容易にすることはできません。
Crucibleのようなツールは、レビュープロセスを円滑化および自動化します。レビューに含めるコミット済み変更セットを1つ以上選択できます。るつぼは、選択されたチェンジセットでどのファイルがタッチされたかを示し、各レビュー担当者が既に読んだファイルを追跡し（全体の完了率を示します）、レビュー担当者が簡単にコメントできるようにします。
http://www.atlassian.com/software/crucible/overview
ユーザー/機能ブランチの他のいくつかの利点：
- 開発者は、他の人のためにシステムを壊す心配をせずに、バージョン管理の利点（変更のバックアップ、履歴からの復元、変更の差分）を利用できます。
- 必要に応じて、欠陥を引き起こしたり、予定どおりに完了しない変更を、バックアウトしたり、優先順位を付けたり、棚上げしたりできます。
経験の浅い開発者にとっては、メンターやペアプログラミングと定期的に相談することをお勧めしますが、これを「コードレビュー」とは見なしません。
どちらも。 （やや。）
コミットする前に、独自のコードをまとめて確認する必要があります。 Gitでは、ステージング領域は素晴らしいと思います。変更をステージングした後、git diff --cachedを実行して、ステージングされたすべてを確認します。これを機会として、属していないファイル（ビルドアーティファクト、ログなど）をチェックインしないようにし、そこにデバッグコードやコメントされた重要なコードがないことを確認します。アウト。 （チェックインしたくないことがわかっている場合は、ステージング中に認識できるように、通常はすべて大文字でコメントを残します。）
そうは言っても、トピックのブランチで作業していることを前提として、コミット後にピアコードレビューを実施する必要があります。これは、他の全員が正しいことを確認していることを確認する最も簡単な方法です。大きな問題がある場合は、ブランチで修正するか、削除してやり直すのは大したことではありません。コードレビューを非同期で（つまり、Google CodeまたはAtlassian Crucibleを使用して）実行する場合、ブランチを切り替えて何かを簡単に行うことができ、現在数日間レビューされているすべての異なるパッチ/差分を個別に追跡する必要はありません。
トピックブランチで作業していない場合は、必要です。これにより、ストレスと手間が軽減され、リリース計画のストレスと複雑さが大幅に軽減されます。
編集：テスト後にコードレビューを行う必要があることも追加する必要があります。これは、最初にコードをコミットすることを支持するもう1つの引数です。テストグループがすべてのプログラマーからの数十のパッチ/差分をいじくり回して、間違った場所に間違ったパッチを適用したという理由だけでバグをファイリングしたくない場合。
100％のペアプログラミング（あなたがどの程度上級者であろうと）、多数の小さなコミットと、あらゆるコミットに基づいて構築されたCIシステム（ユニット、統合、機能を可能な限り自動化したテストで）。大きな変更またはリスクのある変更に対するコミット後のレビュー。なんらかのゲート/コミット前のレビューが必要な場合は、Gerritが機能します。
チェックイン（バディチェック）時のコードレビューの利点は、大きなコードが完了する前に即座にフィードバックが得られることです。
チェックイン時のコードレビューの不利な点は、コードの長いストレッチが完了するまで、チェックインを妨げる可能性があることです。これが発生した場合、それは利点を完全に打ち消します。
これをより難しくするのは、すべての開発者が同じというわけではないということです。 シンプルなソリューションはすべてのプログラマーで機能するわけではありません。簡単な解決策は次のとおりです。
必須のペアプログラミング。バディがあなたのすぐ隣にいるので、頻繁にチェックインできます。これは、ペアプログラミングがすべての人にとって常に機能するとは限らないことを無視しています。適切に行われると、ペアプログラミングも本当に疲れるので、必ずしも1日中行う必要はありません。
開発者ブランチ。コードはレビューされ、終了時にメインブランチでのみチェックされます。一部の開発者は秘密裏に作業する傾向があり、1週間後に、以前に発見された可能性のある根本的な問題が原因で、レビューに合格するかどうかにかかわらず、いくつかのコードを考え出します。
頻繁なレビューを保証する各チェックインのレビュー。一部の開発者は忘れがちで、非常に頻繁なチェックインに依存しています。つまり、他の開発者は15分ごとにコードレビューを行う必要があります。
チェックイン後、不特定の時点で確認してください。締め切りが迫っている場合、レビューはさらに押し出されます。既にコミットされているがまだレビューされていないコードに依存するコードはコミットされます。レビューは問題にフラグを立て、問題はバックログに入れられて「後で」修正されます。わかりました、嘘をつきました：これは単純な解決策ではなく、まったく解決策ではありません。チェックインが機能した後、指定された時間にレビューしますが、指定された時間を決定する必要があるため、それほど単純ではありません。
実際には、この作業をさらに単純かつ複雑にすることで行います。簡単なガイドラインを設定し、各開発チームがこれらのガイドラインに従うために何をする必要があるかをチームとして理解させます。そのようなガイドラインの例は次のとおりです。
- 仕事は、1日もかからないはずのタスクに分解されます。
- コード（ある場合）がチェックインされていない場合、タスクは完了しません。
- コード（存在する場合）が確認されていない場合、タスクは完了していません。
そのようなガイドラインの多くの代替形式が可能です。実際に必要なもの（ピアレビューされたコード、観察可能な作業の進捗状況、説明責任）に焦点を当て、チームが彼らが望むものをどのように提供できるかをチームに理解させます。