これは何
先日、秀和システム様から「Looks Good To Me 〜みんなのコードレビュー」を献本いただきましたので、その感想を書きたいと思います。
読書対象
私が読んでみて、こんな人やチームが読むと良いと思いました。
- コードレビューを始めたばかりのジュニア
- レビューの文化が成熟してないチーム
- レビューに時間がかかりすぎている
- レビューに対して大きなストレスを抱えている
逆に完全に個人でしか開発してないとかは向いていないと本書にも書いてありました。
扱いやすいPR（Pull Request）とは
信頼できるガイドラインの一つは、合計500行を超えるコードを提出しないことです。
実際、これは厳密な上限であり、これよりもはるかに少なくするようにするべきです！
コード行数の多いPRほど関与度が低いことがわかっています。
中略
500行に達するとレビュー担当者の集中力が切れやすくなります。一方、500行未満のPRは、関与度が高くなりました。
*関与度 = 100行あたりのコメント数
過去に行数が長い（orファイル数が多い）PRを出して、レビュアーから注意を受けたことがあります。
そして適切なのは以下の6つだそうです。
- アトミックな変更や機能に焦点を当てる
- 関連する必要なファイルのみを含む
- それぞれの部分をそれぞれのレビューに分割する
- 10~20分でレビューできる可能性が高い
- 通常、コードの変更は500行以下
- 通常、変更ファイル数は20未満
知識移転・共有
チームメンバー間での知識移転（ある人やグループから、別の人やグループに知識を移す意図的なプロセス）と知識共有（簡単にアクセスできる環境における知識の交換）という2つの補完的な目標は、検討するに値します。
中略
コードレビューを使って知識を共有するメリットの1つは、チームが特定の個人に依存することを減らせる点です。チームに長年在籍している経験豊富なメンバーは、コードベースが現在の状態になった理由の背景にある特殊事情、ニュアンス、歴史などを熟知していることでしょう。しかし、まさにそういった情報こそ、特定の個人の頭の中だけに閉じ込めておくのではなく、共有されるべきです。
これはコードだけの問題ではなくプロジェクトにも言えることだなと思いました。
プロジェクトの概要だったり詳細を共有されることによって属人化を防ぐということにも繋がるし、本書にも「バケーション係数（バス係数）」について書かれてあります。
（なぜバケーション係数なのかというと、バスで撥ねられるのは物騒なのでバケーションのほうが良くない？みたいな意味合い）
主観的にならない
よさそうですが、私はこっちのスタイルのほうが好きです。
私の正しく機能する実装のどこが、この提案に及ばないのでしょうか？
理解できなければ、レビュー担当者に理由の説明を求めるコメントを追加しなければなりません。
これは、コードレビューが遅れる原因として、極めてよくあることです。
流石にこういったコメントは（私は）あまり見ないですが、より客観的にコメントを書けるとよいでしょう。
客観的に書くにはしっかりと「なぜ」を書くとよさそうです。
nowrapは最適ではないかもしれません。
長いエラーメッセージがあると、適切に折り返されないでしょう。
ラベルの幅を100%に設定するほうが良いと思います。
そこで「なぜかと自分に問いかける」というアドバイスをより体系化するために、5つのプロセスがあり、それが以下です。
-
立ち止まる
- 文字通り、少し時間を取って立ち止まる。深呼吸をする
-
熟考する
- 思考プロセスを辿る。その提案を思いついたきっかけは何だったのか？なぜそれが必要なのか？
-
見送る
- よく考えてみると、それは全く有効な提案ではないかもしれない。実際、言葉にまとめられなかったり、自分でも明確に理解できなかったりする
-
提案する
- 熟考の末、提案が有効だと判断した場合は、ぜひ提案すること！思考の背景ある提案を理解し、事前に提案を検証しておくと、残すコメントで提案をよりうまく伝え、明確に説明できる
-
延期する
- 内製を通じて、その提案がレビューには適切ではないが、覚えておく価値がある、あるいは議論する価値があると判断した場合はメモをしておき、次のチームディスカッションで取り上げたり、PR作成者とオフラインで話し合う
ポジティブなレビュー環境
設定するべき最も馬鹿馬鹿しいけれども必要なガイドラインは「互いに礼儀正しく接する」ことです。
「公式ドキュメントに『意地悪するな！』と明記する必要は本当にあるのか？」と思うかもしれません。
私は自身を持って「はい！」と答えます。
コードレビューが、時として人々の否定的な面を引き出すことがあるのは周知の事実です。
実際にCSSのオープンソースのリポジトリで、あるPRにつけられたコメントで以下のようなコメントがあったそうです。
でも、でも…
だね。前にも言ったけど、長方形のボタンでは、そのクラスは動かないようにするべきだよ。
これはオープンソースであった事ですが、同じ社内やチーム内での出来事であったとしたら心理的安全性が担保されているとは思えません（オープンソースでもこんなコメントされたら辛い）
レビューの際、仮にシニアがレビュアー、ジュニアがレビュイーになったとして、立場や役割が違ったとしてもお互いにHRTは心がけた方が良いと考えています。
最後に
400ページ近くの本ですが、挿絵も多く内容もわかりやすかったので、スッと読むことができました。
読者対象にも書きましたが、レビュー文化が成熟してないチームにとってレビュアー、レビュイー双方の負担を減らせるような内容が書いてあると思いました。
余談ですが最近は自分が「ここ大事だな」「読み返したいな」と思うような箇所に付箋を貼るのがブームです。
Views: 0
