コードレビューに割り当てられた時間

コードレビューを行っている場合

• 実装と比較して、コードレビューにどのくらいの時間を費やしますか？
• どのくらいの変更がコードレビューを受けますか？
• あなたはそれがはるかに多い/もっとあるべきだと思いますか？

有効性に関する研究はありますか？

[編集]回答をありがとう

私の仕事では、コードレビューのために次の手順があります。これまでのところ私たちにとってはうまく機能しており、特に工数の面で非常に時間効率が良いことがわかりました。レビューに実際に割り当てられた時間はありません。トランクへのすべてのコミットまたはマージをレビューする必要があり、レビュー担当者が承認するまでに時間がかかります。

編集：要する時間は、もちろん、変化の大きさに依存します。小さな機能とバグ修正には数分かかります。システムの多くの部分に影響を与える大規模な新機能、リファクタリング、または変更は、レビューに半日かかり、結果として生じるすべての問題に対処するのにさらに1日かかります。

このシステムを機能させるには、変更を管理可能なサイズにするために、頻繁にトランクにコミットすることが重要です。1年分の誰かのコードをレビューしなければならない状況にはなりたくないでしょう。

研究に関しては、Smart Bearソフトウェアから無料で小さな本「Peer Code Reviewの最高の秘密」が送られます。コードレビューのさまざまな側面に関する多くの記事があります。これには、どれだけの時間を費やすべきか、どれくらい効果的かについての研究が含まれます。

私たちのプロジェクトでは、システムに対するすべての重要な変更は、チームリーダーによって、または新しいモジュールの主要な「消費者」になる別の開発者と一緒にレビューされます。skypeについて話し、EmacsでRudel（共同編集用のプラグイン、基本的には複数のユーザーが同じファイルをライブで編集できるようにする）、TypeWith.me（Piratepad）、または私たちの1人がskypeで画面を共有します。

新しいビュー、ページなどの日常的な変更はレビューされないため、これを定量化することは困難です。新しいモジュール、メジャーアップデート、リファクタリングを確認します。大きな変更に関しては、コードのレビューには10％から30％の時間がかかりますが、それだけの価値はあります。

ペアプログラミングは、2人のプログラマーが同じコンピューターに座っているだけでなく、同じファイルを同時に編集する場合、肩の後ろに座っている通常のオフィスの練習よりもはるかに優れていると言えます。

命名規則やスコープエラーなどの単純なものには、独自のツールまたはオープンソースの自動ツール（jslint、pylint、pyflakes、pep8）を使用します。そして、コミットとプッシュを制限しません：ブランチとマージが非常に簡単なMercurialを使用します（Gitよりも簡単です）。バグはコードレビューの問題ではありません。

チーム会議を行って変更や新しいことを発表しますが、そこでは誰もが本当に注意を払っていません。おそらくもう少しコードレビューを行う必要があります。

これに対する正しい答えも間違った答えもありません。しかし、私の前に多くの人が示唆したように、コードレビューが外部チームメンバーによって行われる場合[強く推奨される方法] 、開発努力の約30％から35％に達する可能性があります。ただし、これが開発チームの一部である内部プロジェクトチームメンバーによって行われた場合[推奨されません]、これは開発作業にかかった時間の約20％以内に完了することができます。

注：他の何かを検索するときにこのスレッドに出くわし、ここに何らかの値を追加できると思った。ところで、上記のすべての労力の見積もりは、複数のプロジェクトにわたるエンゲージメントマネージャーとしての私の仕事経験に基づいています。それが役に立てば幸い。

組織とコードベースはすべて異なるため、業界全体の価値を得るのは困難です。
あなたが本当に真剣なら、メトリックスの収集を始めるべきです。すなわち、手直しを含めて十分に行われるまでコードレビューを行います。データベース（LOC、コードの複雑さ、プログラミング言語、時間など）でこれを収集し始めます。次に、テスト中に不良率に関するメトリックを収集します。このコードレビューを減らすことができる限り、それ自体で支払う必要があります。テストから欠陥が戻ってきた場合は、欠陥の修正に費やされた時間に関するメトリックを収集します。組織内でこれらのデータを構築し、ベースラインを作成すると、非常に正確に予測できます。さらに学習するために検索する用語は、品質のコストと品質の低いコストです。

唯一の注意点は、これが官僚的になり始め、組織文化に依存することです。