開発チームが生産性をあげるコードレビューのコツ

こんにちは、グロービスでサーバーサイドエンジニアをしている大嶋です。主に研修システムの開発・運用を行なっています。

web界隈ではすっかりリモートワークが一般的になった昨今、webエンジニア同士のコミュニケーションにおけるコードレビューの重要度はますます上がっているのではないでしょうか。そこで今回は、「開発チームの生産性を上げるために、コードレビューで心がけていること」についてまとめてみました。

コードレビューされるとき

テストコードを必ず書く

2021年現在、もはや当たり前と言われてしまうかもしれませんが、機能追加の際にはテストコードを書くことを徹底しています。

カバレッジの取得
全社的にcodecovを導入しています。私のチームがメインで管理しているリポジトリはリリースされてから2年近く経ちますが、かなり高いカバレッジで運用されています。（2021年2月現在で95%程度）

CIによる自動チェック
CircleCIを導入しており、Githubにコードをプッシュすると自動でテストを実行します。また、同時に静的構文解析チェック、セキュリティチェックも実行され、オールGreenにならないとマージできない仕組みになっています。

少し脱線 --より高い安定性・安全性を目指すために--
ただテストカバレッジが高ければよい、という訳ではもちろんありません。

グロービスにはQAチームが存在し、開発チームと協力して品質向上活動に取り組んでいます。QAチームと協力しながら、より意味のあるテストを書けるよう、試行錯誤しながら日々勉強しています 🙌

設計の追加・修正は早めにメンバーに見てもらう

大きめの機能追加など、設計を議論する必要のある実装は早めにチームメンバーからのフィードバックをもらうようにしています。実装を作り切った後で設計を修正する必要がある指摘が入った場合、手戻りが大きくなってしまうことを防ぐためにこのような運用をしています。

Pull Requestは可能な限り小さくする

あくまで目安ですが、1つのPull Requestにつき修正ファイル数が20以内に収まるよう意識しています。これは、修正範囲が大きくなることによって全体像の把握が難しくなり、バグを埋め込む可能性が高くなることを防ぐためです。

また、修正ファイル数が20を超えるような修正は、そもそもユーザーストーリー自体が大きい可能性が高いと判断します。仕掛かった後でユーザーストーリーが大きすぎることが判明した場合は、適宜チームメンバーに相談し、ユーザーストーリーの分割を行うようにしています。

1つのPull Requestに複数の意図を入れない

複数の意図とは、「機能追加を実装している最中にリファクタできるコードを見つけたので、まとめて修正した」というような作業をイメージしています。1つのPull Requestに複数の意図が入ると、「このPull Requestで何が実現したいのか？」という観点がブレてしまい、コードレビューに使う時間の増加、コードレビューの質の低下に繋がると考えています。

そのため私のチームでは、「このPull Requestで何を実現したいのか？」という問いに対して、明確な意図を持ったPull Requestの作成を心がけています。

コードレビューするとき

自分の作業よりもコードレビューを優先する

基本的にコードレビューを最優先して取り組むようにしています。コードレビューが滞ると仕掛りが増え、期限内にユーザーストーリーが終了しない可能性が高まってしまうためです。

自分の作業を終わらせることよりも、チーム全体の生産性をあげることを優先するという共通認識があるため、このように運用しています。

相手の立場に立ったコミュニケーションを心がける

コードレビューによる指摘では、相手の立場に立った伝え方を意識しています。相手のドメイン知識量やスキルセットを想像し、認識の齟齬を産みにくいコミュニケーションを取ることによって、認識違いから発生する手戻りを減らすことができると考えています。

また、コードレビューは本質的に指摘を行う場であるため、足りない点の指摘ばかり目立つのが常ですが、良い点についても言及するように心がけています。（指摘だけでなく、良い点を取り上げてもらえるのは嬉しいですよね😸）

特に現在は、メンバー全員がほぼフルリモートで直接会う機会が少なくなっているので、より丁寧なコミュニケーションを大切にしています。

コードレビューの着目点について認識を揃える

このあたりの知見は参考になるものがWeb上に豊富にあるので、チームやプロダクトの特性に合いそうなものを読み合わせると良いと思います。私のチームでは、Googleのガイドラインを参考にしながらコードレビューを行なっています。

まとめ

ここまでコードレビューに際して、チームとしての生産性をあげるために心がけていることについて紹介させていただきました。コードレビューに対する考え方は、チームやプロジェクトによってまちまちだと思いますが、チームメンバーとよく話し合い、納得した上で方針を決められると良いですよね😊

グロービスに興味を持っていただけた方は、ぜひこちらをご覧いただけると嬉しいです😺
一緒に働いていただけるメンバーを募集していますので、よろしくお願いします。
https://recruiting-tech.globis.co.jp/