コードコミットの前または後に確認します。どちらが良いですか？

従来、コミット前にコードレビューを実行していましたが、今日、同僚とコミット後のコードレビューを希望する議論がありました。

まず、ここに背景があります。

1. 経験豊富な開発者がおり、プログラミングの経験がほとんどない新規採用者もいます。
2. 製品をリリースするために、高速かつ短時間の反復を実行したいと考えています。
3. すべてのチームメンバーは同じサイトにいます。

私が学んだコミット前のコードレビューの利点：

1. メンターの新入社員
2. 開発サイクルの早い段階でエラー、障害、不良な設計を防止するようにしてください
3. 他の人から学ぶ
4. 誰かが辞めた場合の知識のバックアップ

しかし、私はいくつかの悪い経験もしました：

1. 効率が低いため、一部の変更は数日にわたってレビューされる
2. 特に初心者の場合、速度と品質のバランスを取るのが難しい
3. チームメンバーの1人が不信感を抱いた

コミット後のレビューについては、これについてはほとんど知りませんが、私が最も心配しているのは、レビューがないためにコントロールを失うリスクです。意見はありますか？

更新：

1. VCSにPerforceを使用しています
2. コーディングとコミットは同じブランチ（トランクまたはバグ修正ブランチ）で行います
3. 効率を改善するために、コードを小さな変更に分割しようとしました。また、ライブダイアログレビューをいくつか試しましたが、全員がルールに従ったわけではありません。ただし、これは別の問題です。

Simon Whiteheadがコメントで述べているように、それは分岐戦略に依存します。

開発者が独自の開発専用プライベートブランチを持っている場合（とにかくほとんどの状況で推奨します）、トランクまたはメインリポジトリとマージする前にコードレビューを実行します。これにより、開発者は開発/テストサイクル中に必要なだけ頻繁にチェックインできるようになりますが、提供されたコードを含むブランチにコードが入るたびにレビューされます。

一般的に、コードレビューの悪い経験は、解決策があるレビュープロセスの問題のように聞こえます。コードをより小さく、個々のチャンクでレビューすることにより、時間がかかりすぎないことを確認できます。150行のコードを1時間でレビューできますが、プログラミング言語、開発中のシステム、またはシステムの重要度に不慣れな人には速度が遅くなります（安全に重要な場合はさらに時間がかかります）-この情報は、効率を改善し、コードレビューに参加する人を決定するのに役立ちます。

まだ誰も引用していないように見えるマントラがあります：早く、頻繁にチェックインしてください：

ソース管理に何もチェックせずに長期間（長いこと私は1日以上を意味する）働いている開発者は、今後の深刻な統合の頭痛の種になります。デイモン・プールは同意します：

多くの場合、開発者はチェックインを延期します。彼らは、他の人に早すぎる影響を与えたくないため、ビルドを壊したことで非難されたくないため、延期します。しかし、これは仕事を失うか、以前のバージョンに戻ることができないなどの他の問題につながります。

私の経験則は「早期かつ頻繁にチェックインする」ことですが、プライベートバージョン管理にアクセスできるという警告があります。チェックインが他のユーザーにすぐに見える場合、未熟な変更を導入したり、ビルドを壊したりするリスクがあります。

同僚が何を書いているのか全くわからないまま、長期間行くよりも、定期的に小さな断片をチェックインしたいです。私の知る限り、コードがソース管理にチェックインされていない場合、コードは存在しません。これはDo n't Go Darkのもう1つの形だと思います。コードは、何らかの形でリポジトリに存在するまで見えません。

...早めにチェックインし、頻繁にチェックインすることを学んだ場合、途中でフィードバック、統合、レビューを行う十分な時間があります...

私はこれに対して異なるアプローチをしているいくつかの会社で働いてきました。コンパイルを妨げない限り、それを許可しました。バグをチェックインした場合、もう1つはおかしくなります。前者がより好まれます。あなたは、それがすべて後でテストされることを理解して、まだ進行中の事柄で他の人々と協力できるような環境で開発されるべきです。

Jeff Atwoodの声明もあります。物事を壊すことを恐れないでください。

ソフトウェア開発者として改善するための最も直接的な方法は、コードの変更に関しては絶対に大胆不敵であることです。壊れたコードを恐れる開発者は、決して専門家に成長しない開発者です。

また、ピアレビューの場合、誰かが何かを変更したい場合、元のバージョンの履歴をソースに保存することは非常に貴重な学習ツールです。

私は最近、自分が参加しているプロジェクトでコミット前のレビューを開始しましたが、それがいかに問題のないものであるかを嬉しく思います。

私が見るポストコミットレビューの最大の欠点は、それがしばしば一人称のみの不公平であるということです：誰かがコードの正確性をレビューしますが、重大な間違いがない限り、著者は通常関与しません。小さな問題、提案、またはヒントは、通常著者にはまったく届きません。

これは、コードレビューの知覚結果も変更します。すべての人（レビュー担当者およびコードの作成者）が毎回新しいことを学ぶことができるものとは対照的に、追加作業のみを生成するものと見なされます。

コミット前のコードレビューは非常に自然に思えるので、コミット後にレビューを意図的に行うことはできませんでした。継続的インテグレーションの観点からは、作業が完了している可能性が十分にない状態ではなく、完成したコードをコミットする必要がありますか？

おそらく、私たちのチームでこれを常に行ってきたのは、非同期のコントロール駆動型のドキュメントベースのレビューではなく、元の開発者が開始したライブダイアログだからです。

現在、ほとんどのリポジトリは、2フェーズコミットまたはシェルブセット（プライベートブランチ、プルリクエスト、パッチの提出、または呼び出したいもの）をサポートしています。これらのツールを活用することで、常にコミット前のレビューを行うことができると思います。

また、組み込みのコードレビューを提供する別の方法として、ペアコーディング（ジュニアとシニアペア）を検討することもできます。車がロールオフした後ではなく、組立ラインでの品質検査と考えてください。

両方を行う：

• 事前コミット-非常に再利用可能なコード部分や主要な設計決定など、非常に重要な場合にこの種のレビューを行います
• コミット後-改善される可能性のあるコードについて意見を聞きたい場合に、この種のレビューを行います

構成管理下にあるソースファイルに対して正式なレビューを実施する必要があり、レビュー記録にはファイルの改訂が明記されています。

これにより、「最新のファイルを取得していない」タイプの引数が回避され、すべての人がソースコードの同じコピーを確認することが保証されます。

また、レビュー後の修正が必要な場合、履歴にその事実を注釈できることも意味します。

コードレビュー自体については、私の投票は「コミット中」です。

gerritやclover（私が思うに）のようなシステムは、変更をステージングし、それが良ければ、レビュアーにソース管理にコミットさせる（gitでプッシュする）ことができます。それは両方の世界の最高です。

それが実用的でない場合、コミット後が最良の妥協だと思います。設計が優れている場合、最も後輩の開発者だけが、これまでコミットしたくないほど十分に悪いものを持つべきです。（それらの事前コミットレビューを行います）。

これは設計レビューにつながります-コードレビュー時（または顧客の展開時に）に行うことができますが、設計問題の発見はそれよりも早く行う必要があります-コードが実際に書かれる前に。

査読により、制御を失うリスクは最小限に抑えられます。常に2人が同じコードに関する知識を持っています。彼らは時々切り替える必要があるため、コードを追跡するために常に注意を払わなければなりません。

熟練した開発者と初心者が一緒に働くことは理にかなっています。一見、これは非効率的と思われますが、そうではありません。実際、バグは少なく、それらを修正するのにかかる時間は短くなります。その上、初心者はずっと速く学ぶでしょう。

悪いデザインを防ぐために来ること、これはコーディングの前にされるべきです。設計に大幅な変更/改善/新しい部分がある場合は、コーディングを開始する前に確認する必要があります。デザインが完全に開発されたら、やるべきことはあまりありません。コードのレビューが簡単になり、時間がかかりません。

コードが既にスキルを証明した経験豊富な開発者によって作成された場合にのみ、コミットする前にコードを確認することは必須ではないことに同意します。ただし、初心者がいる場合は、コミットする前にコードをレビューする必要があります。レビュー担当者は開発者の隣に座って、開発者が行ったすべての変更または改善を説明する必要があります。

レビューは、コミット前とコミット後の両方の恩恵を受けます。

事前審査コミット

• レビューアに、著者の最新リビジョンをレビューしているという自信を与えます。
• 全員が同じコードをレビューできるようにします。
• レビュー項目から作成された改訂が完了したら、比較のための参照を提供します。

レビュー中に実行中のコミットはありません

Atlassianツールを使用しましたが、レビュー中に実行中のコミットが発生しました。これはレビュアーを混乱させるので、これに反対することをお勧めします。

レビュー後の改訂

レビューアが口頭または書面でフィードバックを完了した後、モデレーターは作成者が要求された変更を行うことを確認する必要があります。レビュアーまたは著者は、レビュー項目を誤り、提案、または調査として指定するかどうかについて意見が異なる場合があります。不一致を解決し、調査項目が正しくクリアされるようにするため、レビューチームはモデレーターの判断に依存しています。

約100のコードインスペクションでの私の経験では、レビュー担当者が明確なコーディング標準を参照でき、ほとんどの種類のロジックやその他のプログラミングエラーについては、レビュー結果は一般的に明確です。時々、ピッキングについての議論があるか、スタイルのポイントが議論に退化する可能性があります。ただし、モデレーターに決定権を与えると、行き詰まりが回避されます。

レビュー後のコミット

• モデレーターと他のレビュー担当者に、レビュー前のコミットと比較するためのデータポイントを提供します。
• 欠陥の除去とコードの改善におけるレビューの価値と成功の両方を判断するためのメトリックを提供します。

チームの構成次第です。小規模で頻繁なコミットが得意な比較的経験豊富なチームの場合は、コードに2番目の目を向けるだけで、コミット後のレビューは問題ありません。より大規模で複雑なコミットや経験の浅い開発者の場合は、問題を解決するためのレビューを事前にコミットしてから、問題を解決する方が賢明です。

これらの方針に沿って、適切なCIプロセスおよび/またはゲートチェックインを使用すると、コミット前のレビューの必要性が少なくなります（そして、おそらくそれらの多くのコミットをポストします）。

私と同僚はこのトピックに関する最近の科学的研究を行ったので、これはかなり古い質問であるにもかかわらず、私たちの洞察の一部を追加したいと思います。アジャイルなかんばん開発プロセス/チームのシミュレーションモデルを構築し、多数の異なる状況（チームメンバーの数、スキルレベルなど）のコミット前とコミット後のレビューを比較しました。3年間の（シミュレートされた）開発時間の結果を見て、効率（完成したストーリーポイント）、品質（顧客が発見したバグ）、サイクルタイム（ユーザーストーリーの開始から配信までの時間）の違いを探しました。 。調査結果は次のとおりです。

• 効率と品質の点での違いは、多くの場合無視できます。そうでない場合、コミット後レビューには品質に関していくつかの利点があります（他の開発者はある意味で「ベータテスター」として機能します）。効率化のために、小規模なチームでは事後コミットにいくつかの利点があり、大規模または未熟なチームでは事前コミットにはいくつかの利点があります。
• レビューによって依存タスクの開始が遅れる状況がある場合、コミット前のレビューによりサイクル時間が長くなる可能性があります。

これらから、次のヒューリスティックルールを導き出しました。

• 確立されたコードレビュープロセスがある場合、変更を気にしないでください。おそらく努力する価値はありません
  • サイクルタイムに問題がない限り=>投稿に切り替え
  • または、スリップした問題により開発者が頻繁に混乱する=> Preに切り替える
• まだレビューをしていない場合
  • これらのメリットのいずれかが該当する場合は、事前コミットを使用してください
    • コミット前のレビューにより、コミット権のない部外者がオープンソースプロジェクトに貢献できる
    • ツールベースの場合、コミット前のレビューは、プロセス順守が緩いチームのレビュー規律を強化します
    • コミット前のレビューにより、未レビューの変更が簡単に配信されなくなります。これは、継続的な展開/非常に短いリリースサイクルに適しています
  • チームが大きく、サイクルタイムで問題を抱えたり回避したりできる場合は、事前コミットを使用します
  • それ以外の場合（たとえば、小規模で熟練した産業チーム）は、コミット後を使用します
• 両方の利点をもたらす組み合わせを探します（これらを正式に研究したことはありません）

完全な研究論文はこちらから入手できます：http : //dx.doi.org/10.1145/2904354.2904362または私のウェブサイト：http : //tobias-baum.de

私の意見では、コードピアレビューはコミット後に行うと最も効果的です。

分岐戦略を調整することをお勧めします。開発者ブランチまたは機能ブランチを使用することには、多くの利点があります...少なくとも、コミット後のコードレビューを促進することにはなりません。

Crucibleのようなツールは、レビュープロセスをスムーズにして自動化します。1つ以上のコミット済みチェンジセットを選択して、レビューに含めることができます。るつぼは、選択した変更セットでどのファイルが変更されたかを表示し、各レビューアがすでに読んだファイルを追跡し（全体の完了率を表示）、レビューアが簡単にコメントできるようにします。

http://www.atlassian.com/software/crucible/overview

ユーザー/機能ブランチのその他の利点：

• 開発者は、バージョン管理の利点（変更のバックアップ、履歴からの復元、差分の変更）を享受でき、他のすべての人がシステムを壊す心配が少なくなります。
• 欠陥の原因となる、または予定通りに完了しない変更は、必要に応じてバックアウト、再優先順位付け、または保留することができます。

経験の浅い開発者にとっては、メンターやペアプログラミングと定期的に相談するのは良い考えですが、これを「コードレビュー」とは考えません。

両方。（やや。）

コミットする前に、独自のコードを簡単に確認する必要があります。Gitでは、ステージングエリアは素晴らしいと思います。変更をステージングした後、実行さgit diff --cachedれているすべてのものを確認します。これは、所属していないファイル（ビルドアーティファクト、ログなど）をチェックインせず、デバッグコードや重要なコードがコメント化されていないことを確認する機会として使用します。でる。（チェックインしたくないことがわかっていることをしている場合は、通常、ステージング中に認識できるようにすべてのキャップにコメントを残します。）

そうは言っても、トピックブランチで作業していると仮定すると、通常、コミット後にピアコードレビューを実施する必要があります。これは、他のすべての人が正しいことを確認していることを確認する最も簡単な方法です。重大な問題がある場合は、ブランチで修正したり、削除して最初からやり直しても大した問題ではありません。コードレビューを非同期に（つまり、Google CodeまたはAtlassian Crucibleを使用して）実行すると、数日間現在レビュー中のすべての異なるパッチ/差分を個別に追跡することなく、ブランチを簡単に切り替えて他の作業を行うことができます。

トピックブランチで作業していない場合は、する必要があります。ストレスと手間を軽減し、リリース計画のストレスと複雑さを大幅に軽減します。

編集：また、テスト後にコードレビューを行う必要があることも追加します。これは、最初にコードをコミットすることを支持するもう1つの引数です。テストグループがすべてのプログラマーからの多数のパッチ/差分をいじって、間違った場所に間違ったパッチを適用したという理由だけでバグを提出するのは望ましくありません。

多くの小さなコミットと、すべてのコミットに基づいて構築されたCIシステム（ユニット、統合、機能を可能な限り含む自動テスト）を備えた100％ペアプログラミング（あなたがどんなに年長だと思っても）。大規模または危険な変更のコミット後レビュー。何らかのゲート/事前コミットのレビューが必要な場合は、Gerritが機能します。

チェックイン時のコードレビュー（バディチェック）の利点は、大きなコードが完了する前に即座にフィードバックが得られることです。

チェックイン時のコードレビューの欠点は、長いコードが完了するまでチェックインすることを妨げる可能性があることです。これが発生した場合、利点は完全に無効になります。

これをさらに難しくしているのは、すべての開発者が同じではないということです。単純なソリューションはすべてのプログラマーに有効というわけではありません。簡単なソリューションは次のとおりです。

• 必須ペアプログラミング。バディがあなたのすぐ隣にいるため、頻繁にチェックインを行うことができます。これは、ペアプログラミングがすべての人に常に機能するとは限らないことを無視します。適切に行われた場合、ペアプログラミングも非常に疲れる可能性があるため、必ずしも1日中やることではありません。

• 開発者ブランチ。コードは、終了時にメインブランチでのみレビューおよびチェックされます。一部の開発者は秘密を守って作業する傾向があり、1週間後には、以前に発見された可能性のある根本的な問題のためにレビューに合格するかどうかにかかわらず、いくつかのコードを思い付きます。

• 頻繁なレビューを保証する各チェックインのレビュー。一部の開発者は忘れがちで、非常に頻繁なチェックインに依存しています。つまり、15分ごとにコードレビューを行う必要がある開発者もいます。

• チェックイン後、不特定の時間に確認してください。締め切りが迫ると、レビューはさらにプッシュされます。既にコミットされているがまだレビューされていないコードに依存するコードはコミットされます。レビューは問題にフラグを立て、問題はバックログに記録され、「後で」修正されます。うーん、嘘をついた。これは単純な解決策ではなく、まったく解決策ではない。チェックインが機能した後、指定された時間にレビューしますが、指定された時間を決定する必要があるため、それほど簡単ではありません

実際には、この作業をさらにシンプルにすると同時に複雑にします。簡単なガイドラインを設定し、各開発チームがこれらのガイドラインに従うために必要なことをチームとして把握できるようにします。そのようなガイドラインの例は次のとおりです。

• 作業は1日未満で完了するタスクに分類されます。
• コード（存在する場合）がチェックインされていない場合、タスクは終了しません。
• コード（存在する場合）がレビューされていない場合、タスクは終了しません。

このようなガイドラインの多くの代替形式が可能です。実際に必要なもの（ピアレビューされたコード、目に見える作業の進捗、説明責任）に焦点を当て、チームが彼らが望むものを提供する方法を理解できるようにします。

LedgerSMBでハイブリッドを実際に実行します。コミッターは、後でレビューされる変更をコミットします。非コミッターは、変更をコミッターに送信して前にレビューします。これは、2段階のレビューを意味する傾向があります。最初に、メンターにレビューしてもらい、メンターします。その後、そのメンターは、コードにサインオフしてフィードバックが循環した後、コードを再度レビューします。新しいコミッターは通常、最初に他の人のコミットをレビューするのに多くの時間を費やします。

かなりうまくいきます。ただし、後のレビューは通常、前のレビューよりも大雑把です。したがって、後のレビューは、自分自身を証明した人のために予約するようにしてください。しかし、新しい人々のために2層のレビューがある場合は、問題がキャッチされ、議論が行われる可能性が高いことを意味します。

どこにコミットしますか？いくつかの作業を行うために作成したブランチがあります。気分がいいときはいつでもそのブランチにコミットします。それは誰の仕事でもありません。その後、ある時点で、そのブランチは開発ブランチに統合されます。そしてその中間のどこかにコードレビューがあります。

レビュー担当者は、ブランチにコミットした後に明らかにレビューします。彼は私の机に座っていないので、私のブランチにコミットする前にレビューすることはできません。そして、彼はマージの前にレビューし、開発ブランチにコミットします。

コードレビューをまったく行わないでください。開発者が優れたコードを書くことができると信じるか、それらを取り除く必要があります。ロジックのエラーは、自動テストでキャッチする必要があります。エラーはスタイルです。リントおよび静的分析ツールでキャッチする必要があります。

自動プロセスであるべきものに人間を関与させることは無駄です。