Webアプリエンジニアの大橋です。
オープンワークではGitHub上で1人以上のレビュアーがコードレビューをし、approveすることを必須としています。
レビュアーはプロジェクトチームごとに中堅以上の正社員エンジニアが担当していますが、レビュアー自身も開発を担当しており、チーム内のレビュアーが少ないと負担が大きく、レビューが開発のボトルネックになりがちです。
私も今期（10~12月）はチームのほとんどのメンバーのレビューを担当しており、試行錯誤しながら進めてきましたので、ここで共有したいと思います。
Draftでレビューリクエストしてもらう
軽微なプルリクやある程度経験のある開発者の場合は、テスト実装まで完了してからレビューリクエストするのが理想ですが、
新メンバーの場合や、慣れていないタスクに取り組むときは、「開発途中で良いので、プルリクエストをDraftの状態でレビューリクエストしてください」と伝えています。
コメントや手戻りを少しでも少なくて済むようにするためです。
このように小まめにレビューリクエストしてもらうことで、それぞれのメンバーの進捗状態を確認したりつまづいている箇所がわかるというメリットもあります。
ですから、新メンバーの場合は毎日1回以上はレビューリクエストしてもらうぐらいでも良いと思います。
開発者自身が完了した！と思ったときにDraftをOpenにしてもらうことで、このプルリクは開発途中なのかどうかがわかりやすくなります。
Saved repliesを活用しました
最近はSaved repliesを使い、レビューコメントの分類をしています。
今コメントしようとしている内容は以下のどのラベルに分類すべきか？を考えることはレビュアーにとっても冷静に判断できるメリットがあると思います。
| ラベル | 対応要否 | 温度感、使い方 |
|---|---|---|
 |
〇 | 実装の意図や仕様確認などを質問することが多いです。回答の内容によってはsuggestなどに発展することも |
 |
〇 | 絶対に対応してほしいこと。要件を満たしていない、不具合の元がある等 |
 |
△ | 社内で推奨されているコーディングルールなど客観的にもこうしたほうが良いという内容 |
 |
suggestよりも主観が入る。「自分ならこうする」「自分はこう思う」 | |
 |
細かい指摘、軽微な指摘 | |
 |
「いいね」「ありがとう」 | |
 |
指摘、good以外のコメント |
自身では反省点もあります。
goodをもっと書こう！
レビューに追われていると、やを優先してしまい、つい忘れがちですがコメントも必ず残すようにしたいです。
「この実装いいね！」や「ついでに対応してくれてありがとう」「こんな書き方もあるのですね。勉強になりました！」などです。
imoやnitsのコメントしか残っていない場合はapproveしても良い
やに関してはレビュアーとしては「必須ではない」「どっちでもいいよ」という温度感でも、レビューイは「やはり対応すべき」と受け取ってしまうかもしれません。
ですから本当に「どっちでもいいよ」というスタンスを示すためには先にapproveしておいたほうが良いと思いました。
1営業日以内を目安にレビューする
レビューがボトルネックにならないように、可能な限り1営業日以内に目を通すようにしました。
複数のレビューリクエストが溜まってしまった場合は、リリース予定日が決まっているなどプロジェクトチーム内でも優先度が高いタスクや、再レビューですぐ確認できるものを優先しました。
ただし、自分のタスクが作業中の場合は、キリのいいところまでは中断しないように気を付けたいと思います。
ペアプロ、モブプロも臨機応変に併用しよう
レビューコメントで何度もやり取りを往復するよりも、部分的にペアプロをしてしまうのも一つの方法です。 特に新しいメンバーへのナレッジの共有に効率的です。
また、複数のレビュアーで意見が割れたとき等はレビュアー、レビューイが集まって直接相談し、その場でモブプロをしたほうが早いです。
これももっと早く活用すれば良かったです。
レビューの自動化
これは以前からですが、オープンワークでは機械的なレビューも実施しています。
GithubActions
phpstan、Danger、javascript-ci、deptracをチェックしています。
コードスタイル
コードスタイルを.editorconfigにまとめ、PHPStormのCode Styleで設定することを推奨しています。
CI実行
CI自動テストが通らないとリリースできない為、開発者のCI実行確認は必須としています。
さいごに
初めはレビュー作業に追われて自分の作業をする時間がないと感じてしまった時期もありましたが、いかに効率的に良いレビューをするか？を考えながら取り組むと楽しめるようになりました。
これを書きながら気づいた反省点を元に、来年はもっと良いレビューができるように精進したいです。
この記事を自分のレビューへのレビューとして、今年を締めくくりたいと思います。
GitHubの便利な機能をもっと知りたい方 techblog.openwork.co.jp ペアプロについてもっと読みたい方 techblog.openwork.co.jp オープンワークに興味を持ってくださった方 www.openwork.co.jp
