チームワークアグリーメント〜コードレビューの困難と乗り越え方
多くの開発現場ではコードレビューが行われています。しかし、コードレビューを正しく行う方法について教わったことがある人はあまりいないのではないでしょうか？
私は『Looks Good To Me』を読み、なぜコードレビューを行うか？ からコードレビューの方法論、トラブルシューティング、ペアプロやAIの話まで体系的に理解して感銘を受けました……が、絶版になってしまったようです😭
悲しいので今回はLooks Good To Meに書かれた内容から、コードレビューの困難を乗り越える方法を抜粋して紹介します。
似たジャンルの本だと『伝わるコードレビュー』はコードレビューをコミュニケーションの面から解説した本らしいですね。評判がよいのでぜひ読んでみてください。
なんのためにコードレビューする？
コードレビューって正直大変ですよね。レビューしている間は自分の作業は進められないし、何かを生む作業ではないのであまりモチベーションは上がりません。
にも関わらず、ほとんどの開発現場でコードレビューが取り入れられるのはなぜでしょう？ コードレビューには、大きく分けて3つの大きなメリットがあります。
- 品質の向上
- チームのレベルアップ
- 記録の保持
バグをまったく生まないというのは難しいですが、減らすことはできます。有効な手段のひとつがコードレビューです。実装者以外の観点からコードを見ることでバグに気づき修正を促すことができます。また、不具合ではなくとも保守性の低い実装を改善したり、より拡張性の高い実装を提案することで品質を高めることにつながります。
また、コードレビューはチームのレベルを向上する働きもあります。コードレビューの中で知識を与え、得ることがあります。これを知識移転と呼びます。
また、ベテランにレビューしてもらうことでコードの質が向上したり、逆にベテランのコードをレビューする中で知らなかった知識を得ることもあります。
そして、GitHubなどでプルリクエストをレビューする場合など、プロジェクトの記録を残すことに役立ちます。現在の実装がなぜこうなったか確認したい場合、プルリクエスト内のやりとりを確認すると理由がわかることがあります。
このように少しの手間で大きな効果を発揮するコードレビューですが、場合によってはうまく機能しないことやプロジェクトの進行を妨げてしまうことさえあります。
コードレビューの失敗
ここでは、コードレビューが機能していない状態、デメリットがメリットを上回っている状態をコードレビューの失敗と呼ぶことにします😢
具体的には以下のような状況です。
- バグが見逃されている
- レビューに時間がかかりすぎる
- レビュー観点がわからず、承認の基準が不明
このような状態に直面し、「うーん、よくわからないけどOK！LGTM！」というレビューを行ってしまったことはないでしょうか。なかったらすみません。しかし、もしあったとしてもそれはあなたの意識や能力の問題だけではないのです。
このような状況を引き起こす原因をいくつか挙げます。
レビューするファイルが多すぎる
差分を見ると100ファイル、200ファイルに変更箇所があったとき、いったんブラウザのタブを閉じてしまうのは私だけではないはずです。
複数の作業が一つのPRに含まれているのはレビューの失敗を引き起こします。なるべく作業を分割してレビューを依頼したほうがレビューの質も、速度も上がります。実装段階で切り離せない機能は、設計段階まで戻って検討も必要です。
また、リファクタリングと機能実装などが同じPRに含まれているのも要注意です。まずはリファクタリングをレビューしてもらい、マージ後に機能実装を行ったほうがレビュー観点も明確で、コードも読みやすくなった状態でレビューできます。
プルリクエストが理解できない
ほとんどの場合、コードレビューを行う際は仕様や設計などの背景知識、文脈があった方が圧倒的にレビューしやすいです。これらの情報はプルリクエストの説明に確実に含めましょう。必要であれば図も利用して、理解してもらうための努力を惜しまないようにしましょう。
また、文章だけで理解できない場合、直接会話して説明する、説明してもらうことも効果的です。この場合はわからなかった点、理解できた点をプルリクエスト内に記載しておくとあとから見返すときや他の人の理解を助けるでしょう。
レビュアーが一人しかいない
そんな環境があるのかとびっくりする人もいるんじゃないでしょうか。私はこのようにテックリードがすべてのコードレビューを行う環境にいたこともありましたが、多くの面でデメリットを感じました。
経験の浅いエンジニアでも、学習の機会としてレビューを行うべきだと考えています。
受け入れ基準があいまい
改行の場所や命名規則など、いくらでも議論を長引かせることはできますがあまり生産的な議論ではありません。
逆に、エラーが出ないからと承認してしまうのも効果的なコードレビューとは言えないでしょう。
レビュアーによってレビューの質に差が出ることは、なるべく避けるべきです。
チームワークアグリーメントに取り組もう！
レビュー対象のファイル数、プルリクエストの単位あたりの作業配分、プルリクエストに記載する情報、プルリクエストの受け入れ基準……。これを読んでいるみなさんは、これらに対する明確な基準はありますか？ そしてそれは、チームメンバーと大きくずれていないでしょうか？
上で挙げた失敗の多くは、「暗黙知のずれ」によって引き起こされます。それぞれの常識が違うため、レビューのコストが上がり失敗を引き起こします。
これらのずれを話し合いですり合わせる取り組みがチームワークアグリーメント(TWA)です。
PRの最適なサイズやレビューまでの応答時間、説明に記載すべき情報、受け入れ条件などを話し合い明文化することでコードレビューの質は上がり、より効果的なレビューが行えるようになります。
TWAは一度だけ行うのではなく、定期的に振り返りアップデートしていくのがよいでしょう。
さらなるレベルアップ
コードレビューを効果的に行うには、自動化できるものは自動化するのが効果的です。不要なコメントを減らし、優先度の高いコメントへの対応に注力するためコードフォーマットや構文ルールなどは、フォーマッターやLinterで依頼者自身が修正しておきましょう。
また、チームで気持ちよく仕事をするにはコメントの内容やトーンも大切です。
箇条書きのようなコメントではなく、以下のように3つの要素を含めると指摘が伝わりやすいです。
- 依頼：何をしてほしいか
- 理由：参照やリンクを添付し根拠を示す
- 結果：期待される最終状態
丁寧すぎるコメントは不要なコストだと考える人もいますが、少なくとも一般的な職場では必要なコストだと私は考えます。
ポイントとして、命令ではなく依頼の形で書くこと。主体を「あなた」よりも「私たち」がどのような状態であるのが望ましいと伝えることを意識するとよいでしょう。
まとめ
当たり前のように行われているコードレビューですが、当たり前だからこそなんとなくやってしまいがちです。ですが、どうやったらよくなるか考え、話し合うことでコードレビューはより効果的で効率的になっていきます。結果として開発体験も向上しプロダクトの品質も向上します。
コードレビューは、レビュアーだけでなく、プルリクエストの作り方からレビュープロセスの検討まで検討することでよくなるものです。お互いに思いやりをもって、どうすれば気持ちよくレビューできるか、気持ちよくレビューを受け止められるか考えることが成果につながります。
ぜひ、今一度コードレビューについて考えてもらえれば幸いです。
Discussion