すべての開発者にコードレビューを行わせる

私は7-8人の開発者チームのソフトウェア開発者です。私たちは現在かなり長い間コードレビューを行っており、コードの品質は時間の経過とともに向上しています。

しかし、最近、一部の開発者が他の開発者よりも多くのコードレビューを求められていることに気付きました。私は彼らの柔軟な態度のためだと思います。

私の見解では、これはコードレビューの実施方法ではありません。すべてのチームがそれを説明し、コードレビュー担当者が変更を簡単に受け入れる意思があるために選ばれるべきではありません。

チームでこの問題にどのように対処しますか？

コードレビュー担当者を選択するためのルールを確立しましたか？

コードレビュー担当者は、（良い）コードレビューを行った時間に対して報われるべきだと思いますか？そして、彼らはどのように報われるべきですか？

あなたの答え/アイデアをありがとう。

レビュー担当者は選択しません。

私たちのチームでは：

• プルリクエストが完了する前に、すべてのコード変更をコードレビューする必要があります
• 少なくとも1人の開発者がコードレビューを行う必要があります（2人以上のレビュアーが優れているため、テスター、アナリスト、および他のチームメンバーがコードレビューを行うことも非常に有益です）

コードレビューは割り当てられておらず、人々はそれが彼らのために働くときにそれを拾います。理解は、パイプラインを通じてストーリーをプッシュできないことです。時折、誰かがスタンドアップでCRを待っていると言うでしょうが、それはそれについてです。

私はこのモデルが好きです。人々ができることを手に入れることができ、「人々に仕事を与える」ことを避けます。

変更をコミットした人だけでなく、レビューした人にもバグを修正に割り当てることができるというルールを導入します。これにより、コードレビューの正しい視点が作成されます。

はどうかと言うと、

コードレビュー担当者は、（良い）コードレビューを行った時間に対して報われるべきだと思いますか？

開発者が自分の仕事をしたことに対する報酬がどれほど一般に得られるかは、給料をもらって自分がやったことを誇りに思っていることを除けばわかりません。しかし、コードのレビューは彼らの仕事の一部であるため、レビュー担当者はレビューの時間を確保し、何らかの形でクレジットを共有する必要があります。

主な問題は技術的なものではありませんが、一部のツールではコードレビューにかかる労力を削減できます。克服すべきいくつかの課題があります。

• 変更点を理解する。機能ブランチでのGit Pull Requestは、このプロセスを本当に助けます。
• 人々が同じ部屋にいなければならないイベントをコードでレビューする。これにより、スケジューリング、会議リソースなどのストレスが追加されます。GitHub、GitLab、およびBitBucketを使用すると、非同期のレビューが可能になり、ピアの準備ができたときにレビューを行うことができます。
• コードを見たときに意味のあるフィードバックを提供する機能。正直に言うと、GitHub、GitLab、Bitbucketのプルリクエストの行ごとのコメント機能は、実際の対面会議よりも本当に便利です。政治的ではないと感じます。

SubVersionやその他のツール（Fisheyeなど）を使用して支援できないというわけではありませんが、機能ブランチを備えたGitパイプラインに組み込まれた統合により、本当に面倒な作業が減ります。

ツールの外で、あなたはより多くの社会的課題を見る必要があります：

• オープンプルリクエストを確認してサインオフすることで、開発者に1日を始めてもらいます。
• 新しいタスクを開始する前に、開発者にオープンプルリクエストを確認してもらいます
• プルリクエストには複数の人の承認が必要です。

より熱心な人々がどのタイプのタスクをコードレビューしているのかをチェックする価値があるかもしれません。彼らは簡単なレビューをすべて手に入れているのかもしれません。

ラウンドロビン方式で行うことをお勧めします。コードのレビュー数が最も少ない人を選択します。時間が経つにつれて、チームの全員がほぼ同じ数のレビューを行うはずです。それは知識も広めます。

明らかにピークや谷がある休日のような時折例外があります。

ジュニアとシニア/リードを区別しないでください。コードのレビューは、全員のコードに対して実行する必要があります-彼らがどれほど上級であっても。摩擦を減らし、さまざまなアプローチを共有するのに役立ちます。

それでもやはりレビューの品質に不安がある場合は、コードレビューが合格するための一連の最低限の基準を導入することを検討してください。含めることは完全にあなた次第ですが、考慮したいのは、コードカバレッジ、単体テスト、コメント化されたコードの削除、メトリック、十分なコメント、ビルド品質、SOLID原則、DRY、KISSなどです。

コードレビューのインセンティブについては、質の高いコードが報酬です。他の開発者が最初からコードをもう一度与えて建設的な変更を提案していた場合、痛みをかなり軽減することができた次善のコードベースで作業していると確信しています。

チームにはコードレビューのための正式なプロセスが欠けているようです。

私は350ページのWord文書を作成することについて話しているのではなく、プロセスに伴うものに関する簡単な箇条書きだけです。

重要な点：

1. レビューアのコアセットを定義します。一般的な声明はありません。人に名前を付けます。

   これらはあなたの上級開発者でなければなりません。

2. レビューにサインオフするには、複数のコアレビュアーが必要です。

3. 一時的なコアレビュアーであるスプリントまたはリリースごとに、少なくとも1人の他のコアレビュアーを特定します。この間、すべてのコードレビューでサインオフを要求します。

項目＃3を使用すると、他の開発者がコアレビュアーグループにローテーションできます。数週間、他の人よりもレビューに多くの時間を費やすでしょう。それはバランスのとれた行為です。

やりがいのある人は？多くの場合、チーム全体の前でコードレビュー中に人が行っている努力を認めることはできますが、これについてストレスを感じないでください。

疑わしい場合は、プロセスを定義し、チームにそのプロセスに固執する必要があることを伝えます。

そして、最後に試すことができます-物議を醸す可能性があります：イディオムを使用する場合は、@＃$％をファンに当てましょう。

コードレビュープロセスが実行されていないため、チームを失敗させます。経営陣が関与し、人々が変化します。これは、プロセスを既に定義していて、チームがそのプロセスに従うことを拒否した最も極端な場合にのみ、良いアイデアです。あなたが人々を解雇したり、訓練したりする権限を持っていない場合（ほとんどのリード開発者はそうではありません）、このようなことができる人を関与させる必要があります。

そして、物事を変えることができなかったということはありません。人々が言うかもしれないが、あなたはタイタニックを操縦することができます-しかし、それがアイスバーグに当たる前ではありません。

時々、タイタニック号をアイスバークに当てる必要があるだけです。