セルフレビューはどこまで確認しようか

今回は日記として、セルフレビューはどこまでって議題で書いてみよう。

セルフレビューって❓

チーム開発の場合、開発したソースコードは Git などを利用して管理します。開発した内容は、レビューチェックを別の担当者にお願いして、基本的にはクロスチェックの体制にしてチームで管理されます。責任はみんなで負う。

担当者Aさんが開発して、Gitで共有して、レビュー者Bさんにチェックしてもらう感じ。

で、その前に自分自身で「この内容でレビュー依頼して良いよな」ってチェックするのがセルフレビュー。あまりにも当たり前のチーム内のルールや、すぐ検知できるミスは自分で検出した方が良いよね、という視点でセルフレビューをするものです。

Git を利用したものを具体的に見ると分かりやすいので、ここでは GROWI の OSS で利用している GitHub （Git を利用した Webサービス）上で管理しているソースコードを見てみましょう。

Git と GitHub の違いについてはまた別の機会に記事化だな。。

GROWI は OSS なので、引用で参照します。コーディングの修正でレビュー依頼する単位である Pull request （プルリクエスト、略してプルリクって読んだりする）を見てみましょう。

パッと見て、「あ、これくらいチョロっと変えるくらいなんだ」という規模の修正もあります。

レビューの前提として、プロジェクトの知識が担当者より豊富な方にレビューしてもらうのがチーム開発の基本なので、このくらいの規模だと目視で指摘や間違いなどを検出してもらえます。

レビューする側も、このくらいの規模だと指摘漏れとかせず品質チェックできます。

さて今度はちょっと大きめの規模のコーディングの依頼

さて、パッと見るとどうでしょうか。

レビューというと、機能がちゃんと開発できているかどうかというポイント以外にも、目を皿にしてプログラミングの１文字１文字を見る というチェックになることもあります。👁️

あんまり行数が多いと、レビューする側の担当者もツライという事になります。

こういう時は、「この部分は前提としてこうだから、このレビュー依頼（PR、プルリクエスト）ではこの視点でチェックしよう」と、ある程度レビュー観点を絞ってチェックするのが一般的です。

この時に結構重要になってくるのが、「担当者Aさんはこのへんはちゃんと自分で確認済みだよな」というところ。

レビュー者Bさんがレビューする観点が少なく出来る品質を、担当者Aさんが確保できているかどうか。これが開発現場では結構仕事の重い軽いを左右する重要ポイント。

もし担当者Aさんが、セルフレビューでいろいろな観点を几帳面にチェック済みで、レビュー者Bさんがかるーくチェックするくらいで済むのなら、プルリクエストでレビュー依頼するソースコード行数は大きくても良いと思う。

問題は、レビュー者Bさんが「あ、担当者Aさん、このプロジェクトのこのルール守ってないじゃん」みたいな要素がいっぱいNG状態になっているとき。

こういう時は、レビュー者は指摘をいっぱいすることになり、指摘対応する担当者Aも「うわ、指摘多すぎ」ってなって、双方が不幸になり仕事の進捗が悪くなりがち。

プロジェクトでは、レビュー依頼する単位(GitHub では PR）の規模を小さ目にすることを意識して、レビューして欲しいポイントとバランスを考慮するのが大事。

具体的に「〇〇行以上のレビュー依頼はしないこと」とか、「セルフレビューのチェックポイントとして、このチェックリストの内容を全てを自分でチェックすること」とかすると、今度はスピードが損なわれる。

人に見てもらわないと検知できない間違いもいっぱいあるので、あんまり時間かけてレビュー依頼を躊躇するのも良くない。

結論として、なにごともほどほどにというところかな。