コードレビューと不安の管理

コードレビューをなんのためにするのかと考えてみると、「不安をコントロールするためなのかな」と思ったのでブログにまとめる。


iwashi.co

自分が一番好きな方針、そして説明がこのブログ。 実践したり、設計するときには、いつも確認するようにしている。 場合によっては、新規に参加してもらうメンバーに、上のブログを「読んで欲しいっす」と送ることもある。

もしも、より構造的にされているものが良ければ、Googleのプラクティスでも良い。

shuuji3.xyz

「コードレビューで1日が終わってしまって困る」みたいな困りは各所で見かけるのだけれど、上のブログはそれらを『そういうものだ』と教えてくれるものだと思う。 今ブログに考えをまとめ直してみているけれど、正直なところ、上の2リンク以上の価値はないハズ。

なので、上のブログを読んで「なるほど」となり「そうしよう」となるならば、ここで読むのを終えて大丈夫です。


以下、ブログの考えを「なぜ良いと考えるか」を書き連ねてみる。

twitter.com

上のツイートに書いたように、もしも「自動テストがコードレビューの代わりになる」ようなケースであれば、コードレビューを省いてしまって良いと思う。 *1

コードレビュー

コードレビューには、コストがかかる。

私ごとになるけれど、最近は本業で150~250件/月ぐらいコードレビューをしている。 これは同僚が「スモークテストをしている」ことを前提に、「設計やデータフローに問題がないか」といった観点でレビューしているものが大半だ。 そういった方向で軽量化しているので、なんとか業務時間の半分ぐらいでこなすことができている。 もしも文法のチェックや、ビルドしてデバイス上でチェックして、Figmaと1つ1つ見比べて……とやる必要があれば、多分レビューに専念しないといけなくなる。

何が言いたいかといえば、コードレビューを「厚く」運用しようとすればするほど、そこには工数がかかり、つまり人件費がかかることになる。 その他にも、CIツールを利用していればそれらの運用費がかかる。 たぶん、各種ドキュメントを整備したり周知する必要もあるので、計上しにくいが明確に必要となる工数もたくさんある。

コードレビューというプロセスを採用するということは、これらのコストに対して「我々は、こういったメリットを得たい」という合意を取ることだ。 もしも、コードレビューがうまく回っていないのであれば、そういった合意が取れていないことを疑ってみた方が、きっと良い。

プロセスの意味

プロセスが儀礼的になっているということは、プロセスの意味がないということを意味しない。 「よくわからないけれど続いている慣習」が何らかの品質を守っていることは時たまあるし、実は本質的な取り組みをしていることもある。 言い換えれば、プロセスがブラックボックスであることは無意味ではない。 しかし、ブラックボックスなプロセスは、そのプロセスが適切かどうかを判断することができない。

そして、プロセスの意味が明確になっていないと、プロセスの評価や改善ができない。 プロセスの評価ができないということは、今ある問題を、適切に言語化できないということだ。 例えば、コードレビューが滞ってしまっているときに、「何が問題なのか」を明瞭に記述できないことに繋がってしまう。 ブログで参照している通り、コードレビューを常に最高のプライオリティにおいていれば、チームとメンバーのプライオリティの置き方に差異があることが問題となるだろう。

コードレビューだけに限らないが、さまざまなプロセスの意味自体を明確にする努力は、欠かすべきではないと思う。

不安のコントロール

コードレビューは「不安のコントロール」に対して、非常に強い効果を持っている、と個人的に思っている。

  • コードが正しく動くことを保証できるか
  • コードが変更内容が必要十分であることを保証できるか
  • コードが重大な問題を引き起こさないことを保証できるか

これらは、コードで記述されている内容に対して向けられたもの。

  • コードの可読性が十分であることを保証できるか
  • コードの意図が筆者以外に読み取れることを保証できるか
  • コードの改修のしやすが許容できるレベルであることを保証できるか

これらは、コードの記述そのものに対して向けられたもの。

  • 書かれたコードが、チームとして出荷することに同意されているか
  • レビューのプロセスを通じて、チームの目標に対して前進しているか
  • コードレビューそのものが、HRTが尊重された行為だったか

これらは、コードを書いているメンバーに対して向けられたもの。


コードレビューに全員が参加するということは、こういった「不安のコントロール」に強い効果を発揮する、と思う。 もしコードレビューが形骸化しているならば、これらの「不安のコントロール」手段を1つ失っている状態状態になる。

長々と書いたけれども、コードレビューは重視する理由は、ここに尽きる。

rework.withgoogle.com

「効果的なチーム」であるために、ソフトウェアのコードを書いているチームであれば、コードレビューは効果を発揮する。 だからこそ、コードレビューのあり方は知見を参考にするべきで、チームの重要課題として取り組むべきだと思っている。

*1:詳しくはないけれど、DDDでTDDをしっかりやると、そういう世界観になるのではないかなとかとか