$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

今のコードレビューのやり方

コードレビュー - hitode909の日記 この話。

 大体こういう風なやり方をしてる。Diffだけを見るんじゃなくて手元でもコードチェックアウトしてて、それとDiffを行ったり来たりしながらレビューすることが多い。こういう方法のほうがかっこいいよねみたいなのは書くけどその通りにしてもらうことを強制はしないというのも賛同。

 逆にcommitの中身*1はあえて見ないようにしてる。僕はレビューする時に、そのコードについての学習が行われていない状態で見たほうが良いなと思っている。commitの中身を1つずつ見ていくと学習が進んでしまって、少しわかりづらいコードもあっても、学習が進んでいるせいで無意識に目からすり抜けてしまうという経験があったので、あえてcommitみないということをしてる。

 例外もあって、少し大きめなリファクタリングが行われた時はcommitを1つずつ読んでいくことが多い。少し大きめだとDiffだけだとかなり変わるので何が起こっているか分かりにくいけど、そういう場合は1commitがメソッド移動リファクタリングとか、クラスへの抽出リファクタリングとか、そういう1単位になっていることが多くて、こういう場合はcommitで見たほうが見やすい。
 リファクタリングの1単位は結構この本に載っている通りの単位になっていることが多い。なので軽く流し読むくらいならおすすめ。詳細まで読み込む必要はない。でも今は売ってなくて悲しい。

 コードレビューのやり方はbestなやり方はなくてチームによってケースバイケースだと思うけど、betterな方法が知りたい。けど今のところよく分からない。何か知見があったら共有されたい。

*1:ここで中身と言ったのは、commitメッセージは見るため。commitメッセージを見るとこのPull Requestがしたいことのdescriptionになっていることが多いので、さらっと眺めたりする