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