コードレビューはどのくらいの頻度で行う必要がありますか？

Question

人々がコードレビューを行っている頻度と、レビューを行うことが正しいと思われる頻度を知りたいのですが、また、コードレビューの実行方法についても聞きたいと思います。私は今はTTCを使用しています。私はそれにはかなり満足していますが、コードのすべての部分をカバーしているとは思いません。

Answer 1

コードがをトランクにコミットする前に、常にコードレビューを実行します。私はニール・バターワースのコメントに同意します。頻繁なコミットが奨励されるべきものであり、コミットする前にコードレビューが必要であるということは、これを禁じます。

正確な条件は、環境とプロジェクトによって異なります。私たちの環境は、次のとおりです。

• はトランクが常に仕事は（すなわち、コンパイルやテストを失敗しないトランクに物事をコミットしていないしなければならないというルールがあるトランクに開発の主力をキープ、など）各ケース（機能、バグフィックスなど）
• が、それが審査
を通過するときにトランクにダウンブランチをマージ
• 与えられたブランチでの作業が終了したコードレビューを行いため
• 支店
• リリースが行われると、金のリリースリビジョンとブランチにタグを付けます。特定のリリースのすべての新しいバグ修正は、そのブランチで行われます。リリースブランチはトランクに統合されることはありません。私たちの環境では

、これは、開発者が（自分の支店の範囲内で）頻繁にコミットすることを可能にすると、コードごと作業の単位（ただし、すべてのコミット）を実行するレビュー。

コードレビューの実行方法については、これはもっと野心的な質問です。 SOにそれ自身の質問に値する一つは（と、すでに実際にいくつかある）：

https://stackoverflow.com/questions/89163/how-to-conduct-a-successful-code-review Best Peer Code Review Software https://stackoverflow.com/questions/tagged/code-review

Answer 2

チェックインの前に、チェックインは機能/モジュールの論理仕上げと接続されることがよくあります（プログラマに依存します）。これは良いタイミングです。コードがチェックインされているときは、誰が何時にコード化したのかを追跡することは、すでに困難です。

Answer 3

チェックインする前にいつでもチェックインする予定のコードですが、プロジェクトによってはそれよりも頻繁にやりたいことがあります。

誰かが数週間かかるプロジェクトに取り掛かっていて、その期間のコードをチェックインしない場合は、プロジェクトのさまざまなコンポーネントが完了したときにコードを受け取る必要があります。その理由は、悪いデザインパターンがプロジェクト全体を通して繰り返されず、レビューから必要な変更が少ないことを確認するために、コードを継続的に見直すからです。

私は、開発者がより多くのジュニアであるほど、コードをレビューする頻度が高いことを提案します。