はじめに

コードレビューを実施した際に、レビューに対する認識が違ったり、効率的でないレビュー依頼を出してしまう、良くないレビューを実施してしまうことがありました。その時の反省を踏まえ、コードレビューを実施する際に気をつけることや、大まかな流れをまとめたことがあります。そのときの内容を大まかに紹介したいと思います。

ただし、ここで記載する内容は技術的なレビュー考慮点ではなく、お互いに気持ちよくレビューするための考慮点がメインとなります。

コードを書く前にチェックすること

設計を相談しよう

小さな修正などなら問題にはなりませんが、大きな機能追加では指摘された内容等によっては大きく出戻りが発生します。事前に設計方針を決め、気になる点があれば都度レビュアーに相談しましょう。

レビューによって何をチェックするかを決めよう

開発チームによって「レビュアーがどこまでコードをチェックするか」という感覚が違います。コードの綺麗さは基本として、どの程度の品質チェック(バグ、パフォーマンス、セキュリティ)を行うかなどは事前に感覚を合わせておきましょう。

レビュー依頼するコード量は適切に

コード量が大きくなるとレビュアーの負担が大きいです。感覚的には

• 20ファイル以下
• 変更箇所1500行以下

くらいだと嬉しいですね。変更内容が単純であればこれ以上あっても問題ないときもあるのでレビュアーと相談しましょう。スケジュール感を伝えるのも大事です。

参考:レビューをもらいやすい細かいプルリクの切り分け方

レビューを依頼する前にチェックすること

• テストコード動きますか？
• Lintツールを使ったコードチェック、クリアしてますか？
• テストコードから要件を正しく把握できますか？
• Pull Requestのコメントわかりやすく書きましたか？

CIのフローがあればテストコード/Lintは実行されますが、できればそれらがすべてクリアした段階で、レビューを依頼しましょう。(動くコード大事)
ただ、開発途中のレビューであればその限りではないのです。適時依頼して、フィードバックをもらいましょう。Pull Requestはテンプレート用意しておくと良いです。

テンプレート例

# 目的
どういった機能、要件を達成するためにこれを作成したか書きましょう。
基本的にはTicketやIssueのリンクを貼り付け、簡単な概要を載せます。

# 方針
上記の目的を達成するためにどういった手段を用いたかを記載しましょう。

# 実装
上記の方針からどのような実装になったか分かるように、概要説明や補足資料を載せましょう。
スクリーンショットや、図などを貼るとよりわかりやすいです。

# テスト
テストコードの概要や、テストコード化できなかったテストについてここに記載します。

# 相談
自信がない部分や、特に確認してもらいたいところなどについて記載します。

参考:「速」を落とさないコードレビュー

レビューを書く前に気をつけること

指摘は細かくなりすぎないようにしましょう

Pull Requestのコメントのみで質問すると、文章量が多くなってしまうことがあります。ざっくりとした内容や、確認部分が多い場合は、一度本人に聞いてみて、それを考慮してコメントしましょう。

言葉遣いは気をつけましょう

口頭と文章では、相手に与える印象が大きく異なります。淡々とバグや、コードに関する指摘を書かれてしまうと何気ない文章も相手から「怖い」と思われてしまうことがあります。なるべくフランクな文体で、指示、命令ではなく提案する形で書くと良いと思います！

参考:コードレビューで気をつける言葉や行い
LGTM.fun

抽象的すぎないコメントにしましょう

かといって指示、命令などを恐れるあまりコードに対するコメントが抽象的すぎると、レビュイーが何をどう修正すればいいか分かりません。自身が気づいた問題点、その解決案などが分かるようなコメントは記載しましょう。

この辺は人によりますが、自分が思う(正解とは言わない) 修正イメージのコードや、良いと思う名称をコメントしたりします。

コメント略語について検討しましょう

略語を使ってコメント指摘内容の優先度を表すときがあります。親切ではあるものの、略語の意味を知らないチームメンバーにとっては意味が分かりませんし、細かすぎると感じる人もいるかも知れません。使用の有無を検討しましょう。

参考:プルリク時のコメント略語

指摘する技術的な観点を整理しましょう

偉大な先人たちが、技術的な考慮点をまとめてくださっています。こちらを参考にしてレビューを実施しましょう！

参考:コードレビューのベストプラクティス

最後に

冷静にお互いが納得できるラインを見つけましょう

コードの書き方や、好みは人によってかなり違います。(コメント不要派 VS コメント必要派など) 公式ドキュメントや、参考書籍を使用してより良いコードになるよう話し合いましょう。また

• 指摘されたからといって、不機嫌な態度を取らない
• 指摘が通らないからと言って、不機嫌な態度を取らない
• 上記を防ぐため、お互い敬意を持って話をする

人と人とのコミュニケーションなのでどうしても納得行かない部分、不満に思うところも出てきます。大抵はそこまで拗れることもありませんが、場合によってはそうなってしまう時もあります...怒らない、怒らせないコミュニケーションは本当に大事です。