レビューは長期的にコードの品質を保ち、またメンバー間での実装に対する属人化を減らすための大事な工程です。
フルペアプロをしていない限り、おそらくほとんどの開発組織でレビューを開発工程に取り入れていることと思います。
とはいえ、レビューは差し込みで入ってきて自分のタスクをストップさせることから開発者にとっては悩みのタネという側面もあります。
開発者は基本的に自分のタスクを早く進めたいという気持ちがあるので、レビューに対してはできるだけリソースを割きたくないというのが本音だと思います。
そのため、ともすれば流し見でレビュー承認をしてしまいそうになることもありますが、当然これはQAとしてのレビュー工程を形骸化させる悪手です。
では、どうすればレビューを効果的かつ効率的に行っていけるでしょうか？
私が最低限のレビュー品質を保証するために個人的にやっているのが、レビュー承認をする際に最低限観点をコメントして残すという方法です。
例えば、フロントエンドのレビューをした場合には以下のような形で観点を書き残します。
- 表示に問題なし
- デザインシステムに則している
- テストケース十分
- コンポーネントの置き場所が正しい
なぜこれがレビュー品質を保つための手段になりうるのか？
これには3つの理由があります。
自分が要件を理解していることを確認できる
誰しもレビューをする際にはまずレビュイーが書いたコードとその変更要件を理解することから始めると思います。
この際、自分がコードと要件を理解していることをどう証明しますか？
その答えが観点を書き出してみることです。
要件を理解していなければ観点を出すことなどできません。
リファクタリングだから設計を見る、とか機能追加だからビジネス要件を見る、といった具合にその変更の理由を知ることで初めて観点を出すことができます。
そういう意味では、観点を出せないということはそもそも要件が理解できていないからと言うこともできます。 観点を明示することは要件の理解度に対するチェックをしていることと等しいということです。
レビュー観点について責任が伴う
要件を理解できたら次はコードを理解する必要がありますが、観点を書き出すことはここにも寄与します。
というのも、実際にやってみればわかりますが普通レビュー観点を書き出す際その観点について自信を持って問題ないと言えない限りはなかなかコメントとして残すようなことはできません。
これは、コメントとして観点を明示してしまうと少なくともその観点についてはコード品質に対する責任が伴うためです。
例えば、表示に問題なしというコメントをしておいてその後その画面のデザインで問題が発覚したら、あなたは何を見て問題ないと思ったの？という話になると思います。
実際にそう言われなかったとしても、コメントを残す際にはそう言われる想像が働くものです。
ですので自然に、コードをしっかり理解して少なくとも自分が書く観点については間違いなく正しく動作しているということを保証したいというインセンティブが働きます。
これは別の言い方をすると、観点を書き出すという行為は他人の書いたコードに対してオーナーシップを持つ取り組みであるとも言えます。
開発者が自分で書いたコードをよく理解しているのと同じく、この取り組みをすることで自然とコードを理解していないとレビューできないという環境が作られるということです。
複数名でレビューする際に観点の重複を避けられる
PRのリリースまでに複数名のコードレビューを挟むケースはよくあると思います。
これは一人では見切れない観点を複数名にレビューしてもらうことでカバーするためです。
しかし極論、全員が全く同じ観点でコードを見たのでは一人でレビューをするのと変わりません。
これに対し、前のレビュアーがどこを見たのかが分かることで後続のレビュアーの観点被りを防ぐことができます。
例えば前のレビュアーが機能要件をしっかり見たとコメントしているなら、自分は設計周りを重点的に見よう等の判断ができるということです。
また、複数名レビューにおいて前のレビュアーが既に承認していると後続のメンバーはどうしてもレビューが甘くなりがちです。 観点を書き出さなければならないとなると上記のような別観点で見ようというインセンティブが働くので、こういった問題も防ぐことができます。
とはいえ、バランスが大事
と、ここまでレビュー承認の際のコメント残しがいかに重要かを語ってきましたが、この方法にはデメリットもあります。
それは、最初は時間がかかる、すなわち面倒くさいということです。
ですので、他人に強要しすぎるとうざがられるタイプの取り組みだとは思います。
実際、リスクの少ない変更で後から修正するのもそんなに手間ではないので多少レビューが甘くなっても問題ないという場面もあると思います。
こういった場合にはバランスが大事で、時々思い出したように観点を書き出すというくらいでもいいかもしれません。
とはいえ、上述のように観点を明示することはコードに対する理解や要件に対する理解を底上げするという点でも意義があるので、自分のためにも普段からやっておくことをおすすめします。
まとめ
レビュー観点を書き出すのは面倒くさい取り組みですが、確実に自分の力になります。
最初は時間がかかりますが、普段から習慣としてやっておくことでちょっとずつレビュー速度が早くなっていくと思います。
私もついつい観点無しで承認しちゃうことがあるんですが、せめてやり取りなしで一発承認する際にはコメントを残していきたいですね。
