この記事は、開発生産性 Advent Calendar 2022の3日目の記事です。
2日目の記事はnaoto_pqさんの「PR数は開発生産性のセンターピンかもしれない」でした。PR数を増やすことにフォーカスすることで、Four Keysの向上やベロシティが安定したという学びが深い記事でした。
私は開発の生産性向上施策の１つとして、コードレビュープロセスの負荷や時間を減らすために取り組んでいる10のTipsを紹介します。
ぜひ、面白いなと思ったTipsがあれば、トライしてもらい、コードレビューの効果や効率を高めていただければ嬉しいです。
Tipsを紹介する前に
コードレビューは、開発プロセスの早い段階で欠陥を発見できる有効な開発プラクティスとして多くの開発チームで実施されています。
しかし、プルリクのレビュー依頼をしてからレビューが返ってくるまで1日以上かかったり、その後、レビューの対応からマージまで数日かかったりすると、私は開発がうまく進められていないなーとヤキモキしてしまいます。
また、最近、Metaのコードレビュー改善の記事を読んで、「コードレビューに時間がかかると開発者の満足度が下がることが分かった」という話もありました。
We analyzed the correlation between Time In Review and user satisfaction (as measured by a company-wide survey). The results were clear: The longer someone's slowest 25 percent of diffs take to review, the less satisfied they were by their code review process. We now had our north star metric: P75 Time In Review.
訳：レビュー時間とユーザー満足度 (全社調査で測定) との相関関係を分析しました。結果は明らかで、レビューされるまでの時間が最も遅い25%の人々は、コードレビュープロセスに対する満足度が低くなりました。そのため、ノーススターメトリクス（訳者補足：運営上、重要な指標）である 「P75 Time In Review」ができました。
この記事では、以下のようなコードレビューのプロセスを前提として、コードレビューの負荷や時間を減らす10のTipsを紹介していきます。
※GitHubのプルリクベースの開発スタイルやSlackでコミュニケーションをしている前提で書かれています。
1. GitHubのリマインダーを設定する
GitHubではプルリクエストでのレビュー依頼をSlackに通知したり、レビュー忘れを定期的にリマインドしてくれる機能（スケジュールされたリマインダーの管理）があります。
チームでリマインダーの設定をすることで、レビュー依頼にすぐに気づきやすくなったり、レビュー忘れを防止でき、レビューの着手までの時間を短くできます。
※リマインダーの間隔を短くしすぎて、リマインダーの疲れに注意してください 
2. レビュースピードを早くするためのチーム文化づくり
弊社の開発チームでは、レビュースピードを高めるための文化づくりがされています。
チーム開発を進めていく中でレビューを早くすることの大切さを体感してもらいつつ、レビュースピードに関することを明文化しています。
参考：弊社の開発チームのドキュメント一部抜粋
個人的な実感としても、お互いにスピーディにレビューをすることで、サクサク開発が進み、気持ちよく開発ができています。
3. プルリクのサイズを小さくする
プルリクの変更量が小さければ、レビュアーのレビュー負荷が減ります。また、レビュー後の対応も少なくなるので、結果として、コードレビュー全体の負荷を減らし、時間も短かくすることができます。
また、変更行数が400行以下だとレビューの品質が高くなるという話（Best Practices for Code Review）もあり、変更量に対するレビューの質の向上もはかれます。
よく機能追加全体では、400行を超えるような変更になることが多いと思います。
そういった場合は、例えば、スキーマの変更、モデルの追加、コントローラの追加といったように機能追加をタスクにバラしてプルリクを作ることで、レビュー負荷を下げながら、コンフリクトや手戻りの問題などを減らせます。
参考：機能追加時のタスクばらしのイメージ
4. プルリクの変更意図を１つにする
プルリクのサイズと関係することですが、プルリクの変更内容は１つの問題に集中したものが理想です。
例えば、バグ対応ならバグ対応のみ、機能追加なら機能追加とそれぞれ分けてプルリクを作ります。逆に、バグ対応とリファクタリング、機能改善とリファクタリングなど複数の変更意図をまとめてしまうのはあまりよくないです。
複数の変更意図を１つのプルリクに混ぜてしまうと、レビューの負荷が多くなるだけでなく、リグレッションテストの実施の必要性がでてきたり、他の人による該当のプルリクのリバートも難しくなります。さらに、数カ月後など後からプルリクの変更を見た人が変更の意図を理解するのも難しくなってしまいます。
5. 事前にレビュアーに役立つ情報をコメントする
レビュー依頼前に、レビュアーがレビューしやすいように、見てほしいポイントやレビューに役立つ情報をコメントします。
例えば、外部ツールとの連携の場合はAPIドキュメントのリンクを貼る、実装上迷っている場合は迷っていることを書くなどレビュアーが疑問に思うところを先回りしてコメントしておきます。
そうすることで、レビュアーがレビューをしやすくなることで、レビュー負荷やレビュー時間を短くすることができます。また、コードレビューが変更の履歴として、後世の開発者に向けた記録としても活用しやすくなります。
6. ビルド、テスト、静的解析などを自動化する
ビルド、テスト、静的解析など人間がやっている機械的なタスクの自動化を進めていきます。
少なくとも、次のようなことは自動でチェックしていけるとよいでしょう。
- 自動テストのカバレッジをあげて、機能性のチェックをテストコードに任せる
- リンターやフォーマッターでコードスタイルや悪いコードの書き方を自動でチェックする
- 静的解析ツールやCodeQL、Synkなどで一部のセキュリティのチェックを自動化させる
これらの自動化を進めることで、プルリクごとにシステムの振る舞い、可読性、セキュリティなどがある程度担保されるようになるので、レビュアーの労力が減り、結果としてレビュアーの負荷を減らすことにつながります。
7. レビュアーが偏らないようにする
レビュアーが偏ると、その人のレビュー負荷が高まり、レビューの待ち時間が伸びてチーム全体の開発スピードのボトルネックになってしまいます。さらに、レビューによる知識の共有がうまくいかず属人化も進んでしまいます。
そのため、レビューをできる人を増やしつつ、GitHubのレビュアーのオートアサイン機能（Managing code review settings for your team - GitHub Docs）などを使いレビュアー自体を分散させるようにします。
8. コーディングガイドやレビューチェックリストを整備する
理想的にはすべての指摘をLinterやFormatterなどで自動化できれば良いのですが、まだ人間がチェックする部分も残っています。（技術の進歩に期待
）
そのため、よく実装で議論が起こる箇所やレビューで指摘されることは、コーディングガイドに議論の結論をまとめたり、レビューのチェックリストとして整備していきます。
大切なポイントとして、よく整備したけど形骸化してしまうことがあるので、コーディングガイドやレビューチェックリストは定期的にチームで内容の見直しや不要な項目は削除といった運用をすることが大切です。
9. 話がややこしくなりそうなら口頭で話す
コロナ以降、リモートワークが当たり前になり、リモートで開発をするようになり開発者同士でのテキストコミュニケーションが増えました。そんな中、テキストコミュニケーションだけでやりとりしていると、時間はかかるが全然話が進まないということが増えてきました。
どんなテンションでコメントしているかいまいち伝わらない、対応方法について議論しつつ決めたいというような話がややこしくなりそうな場合は、Zoomやハドルなどで口頭で話すことですんなり解決することがよくあります。
10. 手戻りがおきそうなら、ドラフトプルリクで仮実装して先に相談する
開発を進めていると、どうやって実装をしようか悩む場面もあります。そういったときに、ドラフトプルリクなどで仮実装をして途中でいいのでレビューしてもらうと上手くいきます。
仮に、頑張って実装して、レビューで大きく手戻りすると、実装者も大変ですが、レビューする側もレビュー負荷が高まってしまいます。
それよりも、「仮実装なんですが、xxを迷っていて、yyのような考えで実装してみたのですが、どうでしょうか？」みたいな形でレビューをすると、手戻りも少なくでき、レビュアーの心理的負荷も減り、お互いに気持ちよく仕事ができます。
ぜひ、小さくトライを！
ここであげているTipsはあくまで一例です。他にもコードレビューの効果や効率を高める方法はいろいろあると思っています。
個人的には、開発プロセス改善は、前向きに新しいことに小さくトライしていき、それが上手くいけば拡大し、上手くいかなければ別の方法を試すというようなマインドが大切だと感じています。
今回の記事で少しでも面白そうと思ったTipsがあれば、１つでも小さくトライしてもらえると嬉しいです！