すべての開発者にコードレビューを行わせる
私は7〜8人の開発者チームのソフトウェア開発者です。私たちはコードレビューをかなり長い間行っており、コードの品質は時間とともに改善されてきました。
しかし、最近、一部の開発者が他の開発者よりも多くのコードレビューを求められていることに気付きました。それは彼らの柔軟な態度のためだと思います。
私の見解では、これはコードレビューの方法ではありません。すべてのチームがその責任を負うべきであり、コードレビュー担当者は変更を簡単に受け入れる意欲があることを選ばないでください。
チームでこの問題にどのように対処しますか？
コードレビューアを選択するためのルールを確立しましたか？
コードレビューアは、（良い）コードレビューを行うために費やした時間に対して報酬を与えられるべきだと思いますか？そして、彼らはどのように報われるべきですか？
あなたの答え/アイデアをありがとう。
レビューアは選択しません。
私たちのチームでは：
- プルリクエストが完了する前に、すべてのコード変更をコードレビューする必要があります
- 少なくとも1人の開発者がコードレビューを行う必要があります（2人以上のレビュー担当者がより優れており、テスター、アナリスト、およびコードレビューを行う他のチームメンバーがいることも非常に有益です）
コードレビューは割り当てられていません、それが彼らのために働くとき、人々はそれらを拾います。理解は、パイプラインを通じてストーリーをプッシュできないことです。時々、スタンドアップでCRを待っていると誰かが言うかもしれませんが、それはそれについてです。
私はこのモデルが好きです。それは人々に彼らができることを拾い上げ、「人々に仕事を与える」ことを避けます。
変更をコミットした人だけでなく、それをレビューした人だけに、バグを修正のために割り当てることができるというルールを導入します。これにより、コードレビューの正しい視点が作成されます。
はどうかと言うと、
コードレビューアは、（良い）コードレビューを行うために費やした時間に対して報酬を与えられるべきだと思いますか？
まあ、給与を得たり、自分がやったことを誇りに思ったりする以外は、一般的に開発者が仕事をすることに対してどのように報われるのかはわかりません。ただし、コードのレビューは仕事の一部であるため、レビュー担当者はレビューの時間を確保し、クレジットを何らかの形で共有する必要があります。
主な問題は技術的なものではありませんが、一部のツールはコードレビューにかかる労力を軽減できます。克服すべき課題がいくつかあります。
- 変化とは何かを理解する。機能ブランチのGitプルリクエストは、このプロセスを実際に支援します。
- コードを作成して、人々が同じ部屋にいる必要があるイベントをレビューします。これにより、スケジュール、会議リソースなどのストレスが追加されます。GitHub、GitLab、およびBitBucketは非同期のレビューを許可するため、ピアの準備ができているときにレビューを行うことができます。
- コードを見たときに意味のあるフィードバックを提供する機能。正直なところ、GitHub、GitLab、Bitbucketのプルリクエストの行ごとのコメント機能は、対面式の会議よりも本当に便利です。それはあまり政治的ではないと感じています。
つまり、Subversionや他のツール（Fisheyeなど）を使用して支援することはできないということではありませんが、Gitパイプラインに機能ブランチを組み込んで統合することで、作業が面倒でなくなります。
ツール以外では、より多くの社会的課題を検討する必要があります。
- 開発者に、オープンプルリクエストを確認してサインオフすることから始めてもらいます。
- 新しいタスクを開始する前に、開発者に開いているプルリクエストを確認してもらいます。
- プルリクエストには複数の人からの承認が必要です。
また、より熱心な人々によってコードレビューされているタスクの種類を確認することも価値があります。彼らは簡単なレビューをすべて手に入れているかもしれません。
ラウンドロビン方式で実行することをお勧めします。コードのレビュー回数が最も少ない人を選択します。時間の経過とともに、チームの全員がほぼ同数のレビューを行うはずでした。知識も広めます。
明らかに、山と谷がある休日のような時折の例外があります。
ジュニアとシニア/リードの間に区別があってはなりません。コードレビューは、すべてのコードに対して実行する必要があります-彼らがどんなに年上であっても。それは摩擦を減らし、異なるアプローチを共有するのに役立ちます。
この後もレビューの品質が気になる場合は、コードレビューが合格するための一連の最低基準を導入することを検討してください。何を含めるかは完全にあなた次第ですが、コードカバレッジ、単体テスト、コメント化されたコードの削除、メトリック、十分なコメント、ビルド品質、SOLID原則、DRY 、KISSなど.
コードレビューを奨励することに関しては、品質コードis報酬です。他の開発者が最初からコードをもう一度渡して、建設的な変更を提案しただけで、痛みが大幅に軽減された次善のコードベースに取り組んだことは間違いありません。
チームには、コードレビューの正式なプロセスがないようです。
350ページのWord文書を作成することについて話しているのではなく、プロセスが何を必要とするかについてのいくつかの簡単な箇条書きです。
重要なビット：
レビューアーのコアセットを定義します。一般的な説明はありません。人に名前を付けます。
これらはあなたの上級開発者でなければなりません。
レビューにサインオフするには、複数のコアレビューアが必要です。
一時的なコアレビューアであるスプリントまたはリリースごとに、少なくとも1人の非コアレビューアを特定します。この間、すべてのコードレビューでサインオフを要求します。
アイテム＃3により、他の開発者はコアレビューアーグループにローテーションできます。数週間、他の人よりもレビューに多くの時間を費やします。それはバランスをとる行為です。
やりがいのある人は？多くの場合、チーム全体の前でコードレビュー中に人が行っている努力を認めることができますが、これについてストレスを感じないでください。
疑わしい場合は、プロセスを定義し、プロセスに固執する必要があることをチームに伝えます。
そして、あなたが試すことができる最後の1つがあります—議論の余地があるかもしれません：私がイディオムを使用しているかもしれない場合、@＃$％をファンにヒットさせてください。
コードレビュープロセスが行われていないため、チームを失敗させます。経営陣が関与し、人々は変化します。これは、すでにプロセスを定義していて、チームがそれに従うことを拒否した最も極端なケースでは、本当に良いアイデアです。人々を解雇したり懲らしたりする権限がない場合（ほとんどの主要開発者としてしないでください）、このことを行える人を関与させる必要があります。
そして、物事を変えるための失敗のようなものは何もありません。人々が言うかもしれないことにもかかわらず、あなたはタイタニック号を操縦しますcan —しかし、それが氷山にぶつかる前ではありません。
時々、タイタニック号を氷山にぶつける必要があるだけです。