コードレビューの参加者
- レビュアー: 他の人が作成したコードをレビューする人
- pr作成者:本人が作成したコードを他の人にレビューしてもらう人
コードレビューとは
コードレビューとは、ある開発者がコードを作成すると、別の開発者が決められた方法でフィードバックをやり取りする過程のことです。 この過程を通じて本人が発見できなかったミスを他の人が発見し、コードの副作用(Side effect)とエラーに早期に対応でき、開発内に定められたコンベンション規則を維持し、技術負債を減らすことができます。 また、複数の開発者が参加することで、問題解決のための技術実装方法論について共有することもあります。
効果的なコードレビューを続けるためには、レビュー担当者の姿勢がとても重要です。 レビューの5つのルールをもとに、レビュー担当者がどのような姿勢で臨めばいいのか見てみましょう。
レビューアの姿勢
レビュアーがコード改善の必要性を感じ、レビューを残すなら、十分な理由によって裏付けられる必要があります。
もしコードレビューが主観的または抽象的である場合、レビューは混乱を感じる可能性があります。
そのため、フィードバックを作成する際にレビューが改善の必要性を感じられるように具体的な理由を作成すると良いでしょう。
pr作成者の姿勢
レビュアーの意見を尊重することをベースとしています。
NG事例を紹介します。
- 社内ルールが決まっていないのであなたのレビューは拒否する->NG
- あなたのレビューはこんな点が足りないから私は皆の合意があるまではあなたのレビューは拒否する->NG
(実際に実務で経験しました。 w)
このような場合は、コミュニケーションのコストをかなり上げる方式です。
すべてをルール化することはできません。 もしruleが必要なら、コードレビュー中に提起するのではなく、コードレビュー後に提示するのが正しいプロセスです。
レビュアーの時間も重要なので、このようなレビュアー以外の部分を話すよりは、レビュアーの意見を最大限尊重する方向が効率的です。
どうやって効率的にコードレビューをするの？
ビジネスの価値を実現するために最も重要なことは時間だと思います。
その時間に対するコストを削減する方向で、二つの側面を考慮したルールを定めるとよいでしょう。
- コミュニケーション·コスト
- 優先順位判断
についてルールを決めていきたいです。
コミュニケーションコストを削減するためのPnルール
私たちは相手と会話をする時、「言葉」という言語的表現の他にも「表情」、「手振り」などの非言語的表現も積極的に活用します。
オンラインでコードレビューを行う場合、「文」だけで考え、感情を含む意見を伝えるため、伝達力が相対的に不足し、
これにより軽い冗談が相手に真剣な話として伝えられる状況が演出され、blockerになることもあります。
コードレビューのコメントに「Pnルール」を使用して、レビュー担当者がコメントを強調したい程度を表現します。
「Pnルール」
P1: 必ず反映してください (Request changes)
レビュアーは、PRの内容がサービスに重大なエラーを発生させる可能性を秘めているなど、重大なコード修正が必ず必要と判断される場合、P1タグを介してレビュアー要求者に修正を求めます。 レビュー要求者は、p1タグについてレビュー担当者の要求を反映したり、反映できない合理的な意見を通じてレビュー担当者を説得できなければなりません。
P2:積極的に考慮してください (Request changes)
作成者はP2について受け入れるか、もし受け入れられない状況であれば、適切な意見を聞いて討論することをお勧めします。
P3:なるべく反映してください (Comment)
作成者は、P3について受け入れ、又はもし受け入れがたい状況であれば反映できない理由を挙げて説明し、又は次に反映する計画を明示的に（チケット等で）表現することを推奨します。 Request changesではなくCommentと一緒に使用されます。
P4:反映してもいいし、次に行ってもいいです (Approve)
作成者はP4については何の意見も付けずに無視しても構いません。 その意見を反映した方がいいか悩んでみる程度で十分です。
P5: ただの些細な意見です (Approve)
作成者はP5について何の意見も付けずに無視しても構いません。
FYI）Pnルールは、コミュニケーションは最大の費用だという問題意識から、これを解決するための文化を背景に根拠として作成されました。 Pnルールはコードレビューの他にも、teamsの会話などのテキストでのコミュニケーションでも活用すれば良いでしょう
レビュー優先順位の判断を助けるD-nルール
D-0 (ASAP)
緊急の修正事項ですぐにレビューしてください。
アプリのエラーによって障害が発生したり、ビルドされないなど緊急イシューが発生した時に使用します。
D-N (Within N days)
「Working Day基準でN日以内にレビューしてください」
一般的にD-2タグを多く使用し、重要度が低かったり日程に余裕がある場合はD-3~D-5を使用することもあります。
終わり
コードレビューには、テクノロジー組織の働き方、文化が反映されています。
- 低文脈コミュニケーション志向の文化
- コミュニケーション費用を高い費用と考える文化
- 非同期コミュニケーションを目指す文化
この文を通じて技術組織でどのような文化が効率的なのかを理解し共感できる機会になればと思います。
*個人記録ですので、様々な部分でリファレンス参考にしました。 ご了承ください.