Subscribed unsubscribe Subscribe Subscribe

@kyanny's blog

Write down what I learnt. Opinions are my own.

理想的なコードレビュー

理想的なコードレビューとはどういうものだろう。前提として、 Git のよくあるワークフローで常識的なサイズのトピックブランチを、 GitHub か似た何かの Pull Request 的なビューの単位でレビューする、とする。

無言、または LGTM や :+1: など、「ちゃんとレビューしたよ、オッケーだよ」というシンプルな意思表示のみでマージに至るものは理想的に思える。レビュアーの「自分だったらこう作る」という設計・実装イメージとレビュイーの「自分はこう作った」という設計・実装がほとんど違わない、もしくはレビュアーのイメージとは違うけども納得できる結果になっている、よってコメント不要、なのだといえるからだ。

これを理想だとすれば、なんであれコメントがつくのは理想的ではない、ということになる。レビュアーとレビュイーの見解・実力に差があり、それが設計や実装の欠陥を指摘するコメントや、逆にコードの意図を正しく理解できていない未熟なコメントとして現れる、といえるからだ。

しかし本当にそうだろうか?双方の力量が同程度で、見解も一致しているという状態は、チームでシステム開発をしている組織にとって本当に望ましい状態といえるんだろうか?見解に相違がないのは新しい視点が不足しているせいかもしれないし、レベルの低いもの同士がレベルの低いレビューをしても品質はあがらない。

ここでジレンマがうまれる。チームの開発速度を最大化するためにはメンバーの力量に差がないほうがよい。しかし似た者同士のチームは長い目で見れば硬直化し、チームの作るシステムも柔軟性を失っていくだろう。

レビューには教育という側面もあり、育成のためにあえて実力差があるチーム編成をすることもある。実力差があるほうがレビューは効果的だから、レビューの価値を最大化する、ひいては組織の成長への貢献度を最大化する観点からは、こちらのほうが理想的とすらいえるのではないか。

もちろんそれにも一理あるだろう、しかし、長い目で見たときの価値を最大化するために目先の生産性を損なう、というのも手放しには受け入れがたい。レビューがまともに回らないチームには明るい未来も訪れないだろう。

あなたのチームはどうだろうか。あなたのプロジェクトでは何を重視してレビューしているだろうか。チームメイトとそんなことを話してみるのも、たまにはいいかもしれませんよ。