概要

みなさんコードレビューしていますか？(されていますか？)
私は基本的にコードレビューをすべき(されるべき)だと考えています。
今回は、なぜコードレビューをした方がいいのか、誰が誰にすべきなのか、具体的なやり方、注意点についてご紹介したいと思います。
なお、本記事はあくまでも私個人の考え方なので正解というわけではないです。
※ 前提として、コードレビューと動作レビューは別物の想定です。

誰が誰にレビューするべき？

私は新人・玄人関係なく、コードレビューするべきだし、されるべきだと考えています。

レビュー者は、必ずしもコードが綺麗に書ける人・経験が豊富な人である必要はないです。
コードレビューすることで、こんな書き方や考え方があるんだということをレビュー者が学べたり、知識が少ないからこその気付きがあったりします。したがって、新人だからとか不慣れだからとかは気にしなくてもいいです。
品質担保を目的とするのであれば、新人と経験者の二人をレビュー者とすれば良いですね。

少なくとも、これまでコードレビューをしてこなかったチームや会社なのであれば、不慣れな方がコードレビューするからといって、品質が下がるということはないのでご安心ください。(笑)

具体的なやり方

前提条件

ラベル

GithubやGitlabにラベルというものがありますので、ぜひ活用しましょう。
参考までに私がよく利用しているラベルの一部を紹介します。

名称	意味
doing	現在作業中です
done / finished / fixed	作業終了しました
reviewable	レビュー可能な状態です
feedback	フィードバックがあるので確認してください
mergeable	マージ可能な状態です

フロー

issue作成からmergeするまでの流れを記載してみました。

注意点

レビューが必要かどうかの基準を設ける

全て機械的にレビューするのではなく、例えば、文言変更だけの場合はレビューは無しでOKなど、レビューが必要かどうかの基準をチームで定めるのは良いと思います。

コードの分量(レビューにかける時間)

基本5分程度を目安にできるくらいがいいです。
(レビュー者と被レビュー者が慣れるまでは時間がかかりますが、それは仕方ないです。)
また、マージリクエスト(プルリクエスト)もそれくらいの粒度で作成できると良いです。
どでかいのをレビュー依頼されると、、、見ること自体辛いですし、レビューの精度は格段に落ちます。(笑)

改善案は具体的に書く

レビュー時のコメントは具体的に書いてあげましょう。

サンプルコード

PHPのサンプルコードで試しにレビューして、コメントしてみます。

function getUserIds($users) {
  $data = [];
  for($i = 0; $i < count($users); $i++) {
    $data[] = $users[$i]->id;
  }
  return $data;
}

良くない例

もう少し簡潔に記載してください。

良い例

具体的な改善案を示してあげると対応もしやすいです。

`array_map`という関数を使えばもっと簡潔に書けそうです！ https://www.php.net/manual/ja/function.array-map.php

余談ですが

昔、私は上記のような良いコメントのおかげで、array_mapという関数を知ることができました(笑)

レビューにおいて立場や経験は関係ない！？

立場や経験などを気にしてレビューはしないようにしましょう。（No忖度！）
例えば、A先輩は10年のベテランだから、気になるところがあるけれどコメントせず承認だけしとけばいいよね？や俺はベテランなのになんで新人のBからコメントされないといけないの？とかはやめましょうね。
レビュー者は素直に気づいたことはコメントしたり、質問したりしましょう。
また、被レビュー者は私のコードを見てくれてありがとう。コメントありがとう。気づかせてくれて（教えてくれて）ありがとう。の気持ちを持ちましょう。

コミュニケーション

当たり前ですが、これが多分一番大事ですね。
コメントは感情のない文章でのやりとりなので、レビュー者にそんなつもりがなくても冷たい感じに受け取られてしまったり、怒っている感じに受け取られてしまったりします。
だから、コメントする時は表現を気をつけたり、顔文字をつけたり、など簡単にできる最低限の配慮があるといいですね。
また、どうしてもコメントだとやりとりが長くなりそうといういう時は、口頭で伝える+簡単なコメントという感じがいいですね。

さいごに

コードレビューのメリットややり方をご紹介してきましたがいかがでしょうか？
もちろん、デメリットとしてレビュー工数がかかってしまいます。
ただ、そのデメリットを鑑みても、メリットの方が勝ると私は考えています。
この辺は案件の規模や予算などによっても分かれるところかと思いますが、まだレビューしたことないよーという方はぜひチャレンジしてみてください。

コードレビューのすゝめ

概要