コードレビュー時のコミュニケーションについて

Posted on 2016-03-11 , Tags: Code Review, Communication

コードレビューする、というのは難しい。何が難しいのかというと、自分が書いたコードは自分の一部のように感じてしまって、レビューを自分自身に対する批判として重ねてしまうことがある。
という話は前々から散々いわれていたきたことなので、今更ではあるが、自分の学んだことなどを書き残しておきたくなったので書く。


1. 純粋にコードに対する批判と受け取れるように書く

書き方の問題。「なんでこんな書き方するの？」->「このコードはこういう欠点があるので、こうしたほうがよい。」

2. 逆によいところはその人自身に重ねていうといいかも。(これは人によりそう。)

「このコード、ここがこうなのでいいですね。」->「よくこんなこと知ってるね。」

3. 意図、理由を明確にする。

「ここはこうしたほうがいいですよ」 -> 「このコードはこういう欠点があるので、こうしたほうがいいですよ。」

4. 修正がMustなのかを書く

絶対にFixすべき箇所とそうでない箇所がある
コードが少々きたない、くらいで全部なおさせるのはどうなの？という話。もちろん趣味プロジェクトなら別。


逆にレビューをお願いする側としては、以下のことが必要だと感じている。

1. どういう修正をやったか概略を伝える

レビュワーとしては、どうしてもコードだけだとボトムアップな理解になり、結構つらい。
画面の見た目とかの修正であればスクリーンキャプチャのGIFを貼るなどしたことがあるが、結構よかった。

2. 修正の結果どうなっていたらいいのか、修正のゴールを伝える

上と同じ理由。

3. 自信がないポイントがあれば積極的に伝える

なんとなく隠したくなるが、隠してレビュワーが見落とすとコードレビューの意味がない。


コードレビューに限らず、一般的なコミュニケーションに通じる部分は多い。
これを書いていてなんとなく昔オーケストラに所属していたときの頃をおもいだした。あの頃は練習のときにマサカリなげまくっていた気がする。後輩達すみません。

自分も自分の作ったものを見せる、という行為は苦手だ。できるなら一人で安全に楽しみたい。
だが、チームとしていいものをつくれるように、自分一人でも次からはもっといいものをつくれるように、こういうことは重要だと思っている。
自分の一部を公開することでだれかに何かしら貢献できることがあれば、というのがこのブログをはじめた理由のひとつでもある。

参考