コードレビューという言葉には、少しこわい響きがあります。
書いたものを見られる。
まちがいを指摘される。
場合によっては、最初からやり直しになる。
レビューを受ける側だけでなく、する側にも、ちょっとした重さがあります。
けれど、本来のコードレビューは、答案に赤ペンを入れるような仕事ではありません。
まだ事故になっていない小さな違和感を、みんなで見つける時間です。
そして、ひとりの頭のなかにあったものを、チームの知識に変えていく時間でもあります。
大きな荷物は、開けるのもたいへんです
変更されたコードが500行あると、それだけで読む人は少し疲れます。
どこから見ればいいのか。
途中に何があったのか。
前に読んだ部分を覚えていられるのか。
だから、プルリクエストは、できるだけ小さいほうがいいです。
200行以内という決まりが、どのチームにも正しいわけではありません。ただ、人が理解できる大きさに分けるという考え方は、とても大切です。
大きな仕事を一度に見せるより、
「今回はここまでです」
と差し出したほうが、書いた人にも、読む人にも親切です。
玄関を見る前に、家全体を見ます
レビューを始めると、変数名や空白の位置が目に入ります。
でも、その前に確かめたいことがあります。
この変更は、そもそも何を解決しようとしているのか。
その方法で、本当に問題は解決するのか。
家の建て方がまちがっているのに、玄関の取っ手を磨いても仕方がありません。
まず全体を見る。
それから細部を見る。
この順番を守るだけで、レビューはずいぶん静かになります。
「まちがいです」より、「どうなりますか」
コードには、書いた人なりの理由があります。
ですから、「これはおかしいです」と決めつけるより、「この方法を選んだ理由はありますか」「入力が空だった場合は、どうなりますか」と聞いたほうが、話が前に進みます。
質問は、相手を試すためのものではありません。
自分が知らない理由を、受け取りにいくためのものです。
聞いてみると、こちらが見落としていた事情がわかることもあります。
よかったところも、ちゃんと残します
レビューでは、問題のある場所ばかりが言葉になります。
問題のないコードには、何も書かれません。
すると、書いた人の手元には、注意と修正だけが残ります。
「この分け方はわかりやすいです」
「境界値のテストまであるのがいいですね」
そんなひと言があると、何を続ければいいのかがわかります。
人は、直されたことだけでなく、認められたことからも学びます。
機械にできる注意は、機械に任せます
空白、改行、表記の揺れ。
こうしたものを人が毎回指摘していると、レビューが小言の交換になってしまいます。
機械に見つけられるものは、リンターやフォーマッターに任せる。
人は、設計や安全性、読みやすさを見る。
人間にしかできない仕事を、人間がするためです。
レビューは、コードより関係を残します
早く返す。
コメントには応える。
変更したら、説明も書き直す。
どれも小さなことですが、その積み重ねが、「自分の時間を大切にしてもらえた」という感覚をつくります。
コードレビューは、コードをよくする仕組みです。
でも、ほんとうに残るのは、コードだけではありません。
この人とは、また一緒に仕事ができる。
そう思える関係も、レビューのなかで、少しずつ書かれているのだと思います。
