Review Lens

ソフトウェアテストの世界には観点という言葉がある。

何をテストするかのルールセットだ。境界値、異常系、状態遷移、権限。観点が定義されていれば、誰がテストしても同じ範囲をカバーできる。属人的な「なんとなく触ってみた」から脱却するための仕組みだ。

コードレビューにこの観点が設定されていないプロジェクトは多い。

レビュアーが何を見るべきか定義されていない。結果、レビューが感想文になる。「ここ、もうちょっときれいに書けそうですね」。それはリンターの仕事だ。「変数名がわかりにくいです」。それはリンターの仕事ではなく、たしかに人間の仕事だ。だがレビューの本質ではない。

一次レビューと二次レビューを分けているチームがある。一次はチーム内のエンジニアが見る。ロジックの正しさ、エッジケースの考慮、既存コードとの整合性。二次はリードやアーキテクトが見る。設計方針との一致、パフォーマンスへの影響、セキュリティ。観点が違う。同じ人間が全部見ようとすると、どこかが抜ける。

観点を明文化しているチームはうまく回っている印象がある。レビューチェックリストを作って、最低限見るべき項目を並べる。入力のバリデーションはあるか。エラーハンドリングは適切か。N+1は出ていないか。認可のチェックは漏れていないか。チェックリストがあれば、経験の浅いレビュアーでも一定の品質を担保できる。

CodeRabbitのようなAIレビューツールも出てきた。観点さえ定義してあれば、AIにもチェックリストベースのレビューを任せられる。

レビューで揉めるのは、観点が共有されていないときだ。Aは可読性を重視し、Bはパフォーマンスを重視し、Cはとにかく動けばいいと思っている。全員正しいが、優先順位が違う。観点を先に合意しておけば、レビューは議論ではなく確認になる。

と、レビュアーのいないPRをAIにマージさせながら思った。