コードレビューをなんのためにするのかと考えてみると、「不安をコントロールするためなのかな」と思ったのでブログにまとめます。
自分が一番好きな方針、そして説明のベースにしているのが、こちらのブログです。
コードレビューについて考えたり、議論する際には、必ず確認するようにしています。 時には、チームに新規に参加するメンバーに対して、「読んでほしい」と共有することもあります。
より構造的に整理されているものが良ければ、Googleのプラクティスもいいものです。
上のブログを読んで「なるほど」となり「そうしよう」となるならば、ここで読むのを終えて大丈夫です。
以下、「なぜコードレビューが重要だと思うか」について。
twitter.com結局のところ、コードレビューが儀式に過ぎないのであれば、この話は無用だと思うわけです。もしもサイコーな自動テストを運用していれば、コードレビューなしで開発したっていいと思うし。トレードオフがあるので、開発している組織ごとに、それらについて納得がされていればいいハズ。
— Koji Wakamiya (@D_R_1009) 2022年7月19日
もしも「自動テストがコードレビューの代わりになる」ようなケースであれば、コードレビューを省いてしまって良いと思っています。 なので、とはいえやそれはそうだけれどもと感じるケースを想定して、続けていきます。
コードレビュー
コードレビューには、コストがかかります。
私ごとではありますが、最近では、150~250件/月ぐらいコードレビューをしています。 これは同僚が「スモークテストをしている」ことを前提に、「設計やデータフローに問題がないか」といった観点でレビューしているものが大半なため、実現できている数です。 逐一ビルドしてデバイス上でチェックして、Figmaと1つ1つ見比べて……とやる必要があれば、多分時間的に対応ができなくなるハズです。
言いたいこととしては、コードレビューを「厚く」運用しようとすればするほど、そこには工数がかかる。つまり人件費がかかるってことです。 他にも、CIツールを利用していればそれらの運用費がかかるし、運用待ちの時間もかかります。 たぶん、各種ドキュメントを整備したり周知する必要もあるので、計上しにくいが明確に必要となる工数もたくさんあります。
コードレビューというプロセスを採用するということは、これらのコストに対して「我々は、こういったメリットを得たい」という合意を取ること、と言えます。 もし、コードレビューがうまく回っていないのであれば、そういった合意が取れていないのではないかなと。コードレビューの運用ではなく、コードレビューの前提を疑ってみた方が、きっと良いと思います。
プロセスの意味
プロセスが儀礼的になっているということは、プロセスの意味がないということを意味しません。
「よくわからないけれど続いている慣習」が何らかの品質を守っていることは時たまあります。もしかしたら、実は、本質的な取り組みかもしれません。 言い換えると、プロセスがブラックボックスであること自体は、そのまま悪いと言い切れません。 しかし、ブラックボックスなプロセスは、そのプロセスが適切かどうかを判断できません。
プロセスの意味が明確になっていないと、プロセスの評価や改善ができません。 プロセスの評価ができないということは、今ある問題を適切に言語化できない、ということです。
コードレビューの問題でよくあるのは、コードレビューが溜まってしまう。コードレビューに時間が取られ過ぎてしまう。レビューそのものが負担になる、という声です。 では、このとき、「何が問題なのか」は明確になっているでしょうか。
前述の通り、コードレビューというステップが不要という共通見解が取れていれば、省いても構いません。 そのような状態であるのに、省けないことに対して不満が上がるということは、何を意味しているのでしょうか？
コードレビューを常に最高のプライオリティにおいているチームであれば、問題は明確になります。つまり、チームで定めたプライオリティと、メンバーのプライオリティの間に、差異があるということです。 当然、「現実的に、レビューするのが大変なコードが多い」場合には不満は残るでしょう。しかし、この時に解決するべきは、コードやPRの質であるハズです。
不安のコントロール
コードレビューは「不安のコントロール」に対して、非常に強い効果を持っていると感じます。 具体例を挙げると、下記のようになります。
- コードが正しく動くことを保証できるか
- コードが変更内容が必要十分であることを保証できるか
- コードが重大な問題を引き起こさないことを保証できるか
これらは、コードで記述されている内容に対して向けられたものです。
- コードの可読性が十分であることを保証できるか
- コードの意図が筆者以外に読み取れることを保証できるか
- コードの改修のしやすが許容できるレベルであることを保証できるか
これらは、コードの記述そのものに対して向けられたものです。
- 書かれたコードが、チームとして出荷することに同意されているか
- レビューのプロセスを通じて、チームの目標に対して前進しているか
- コードレビューそのものが、HRTが尊重された行為だったか
これらは、コードを書いているメンバーに対して向けられたものです。
コードレビューに全員が参加すると、こういった「不安のコントロール」に強い効果を発揮することができます。 もしコードレビューが形骸化しているならば、これらの「不安のコントロール」手段を1つ失っている状態だと、私は思います。
長々と書いたけれども、コードレビューは重視する理由はここにあると思います。 チームメンバーが、チームの「不安」をコントロールできるツール、それがコードレビューなのではないでしょうか。
チームとしてどうあるべきかを考えた時、「効果的なチーム」を目指すのは、ある程度当然の話だと思います。 だからこそ、コードレビューのあり方は、世にある知見を参考にするべきです。 知見を参考に「効果的なチーム」を目指し続けることが、不安に対応できるチームを作ると信じています。