コードレビューとの付き合い方

2 min read読了の目安（約2500字） 1
#
コードレビュー
#
pullrequest
idea

コードレビューとの付き合い方

年末にチームのGKPTをしました。
（弊チームでは良かったことGoodと続けたいことKeep、課題Problem、次にやってみることTryを書くようにしています）

そのGKPTで「なかなかPRのレビューをしてもらえない」というProblemがあがり、
そのリアクションとして「スキルが未熟なために良い指摘ができず、なかなか進まない」というものがありました。
自分としては「コードレビューってレベルの高い人じゃないとできないんだっけ？」という疑問が湧きました。

そこでコードレビューに対しての個人的な考えをまとめてみたいと思います。

端的にいうと

もっと気楽にコードレビューしていいんじゃないの？って思ってます

コードレビューの目的

コードレビューにはさまざまな目的があると思っています。

コードの共同所有

個人的にはこれが一番大きい目的なのかなと思っています。

『今回の修正ではこういう処理をする必要があり、それはここのファイルにこういう風に書いているよ』
みたいなことをチームメンバー間で共有するということです。

難しい処理や重要な処理は書いた本人しかわからない、把握していないということが多々発生します。
それを防ぐためにチームメンバー間で理解をすすめるというのがコードレビューの大きな目的・効果だと考えています。

学びの場であること

コードレビューは学びの場となるとも思っています。

  • この人はこういう観点で実装をしているんだ。
  • こういうメソッドがあるんだ
  • 今回の目的や仕様を満たすためには、こういう実装があるんだ

のような気付きを得られるかと思います。
このようなメリットがあるので、スキルが高いメンバーしかレビューできないということはないと考えています。

課題・問題点の指摘

この点がコードレビューの主な目的と考える方も多いのかなと思います。
冒頭で出たメンバーもこの観点を重視していたのかなと思います。
もちろんこの観点もとても大事なのですが、上に挙げている通りこれがすべてではないと考えています。

指摘ポイントとしては

  • 仕様を満たしていない処理の指摘
  • エラーが出るパターンの指摘
  • よりよい記述や実装方法の提案

などがあるかなと思います。

この点を重視したい場合にはレビュワーを複数人にし、その中にスキルが高かったりプロダクトに詳しい人を含めるとよいかなと思います。

コードレビューを依頼する際に気にかけたいポイント

コードレビューもただ「レビューしてください！」というのではなく、
いくつかの点に気をかけるとよりレビューがスムーズに進むかなと思っています。

Pull Requestの内容を端的に説明する

たまにDescriptionが真っ白なPull Requestを見かけます。
いいレビューにするためにも以下のような点を記述するとよいかなと思っています。

  • どのような課題を解決するPull Requestなのか
    • 関連するIssueがあればリンクを貼る
  • どのように解決したのか
  • どのような動作確認をしたのか
    • 動作確認観点や手順を記述する
    • 画面のスクリーンショットやスクリーンショットアニメーションがあるとわかりやすくてよいかと。

レビューしてほしい部分を記述する

特に修正が大きくなってしまったPull Requestはレビューする側もどこを見ればいいかわからなくなってしまいます。
「ここの部分は特に不安なので重点的に見てほしい」
「全体的な処理の流れを把握してほしい」
などポイントを絞るといいかなと思います。

レビュー期限を記述する

レビューはなかなか難しく、時間が必要になることもあります。
それゆえ「時間ができたらレビューしよう」となりいつまでもレビューが進まないということも発生します。
チームによってはそれを防ぐためにWorking Agreementで「レビューは最優先タスクとする」と掲げているところもあると思います。
そうでない場合には「この日までにはマージできるよう、それまでにレビューをおねがいします」などのようにいつまでにレビューすればいいかを共有するといいかなと思います。

レビューする際に心がけたいこと

レビューする側もコメントの際にいくつかの点に配慮するとよいかなと思います。

指摘事項に修正必須かどうかを明記する

単に指摘するとすべてを修正しなくてはいけないと考える方もいます。
それではお互いに不幸になってしまうので
「この点は修正をお願いします」
「この点の修正はおまかせします」
のように添えるといいかなと思います。

いじわるな指摘をしない

どういうことかというと、スキルが高い方がジュニアレベルの方のレビューをする際にたまにあるのが、
既に自分の中では解があったり、ベスト（orベター）プラクティスがあるのに
「これってなんでこの書き方をしたの？」というようなレビューコメントをすることです。

心からそう思い議論をしたい場合にはよいと思うのですが、「マウントを取りたいの？」と思われてしまうこともあります。

そうならないよう
「自分だったら〜〜〜という点から○○という書き方をするのだけれど、このように書いているのはどうして？」などのように議論が進むようなコメントをするのがよいかと思います
（これでもよくない気がするのでもっとよいコメントの仕方があったら教えて下さい）

最後に

長くなりましたが、自分なりのコードレビューに対する考え方を書いてみました。
レビューする側もレビューされる側も楽しくプログラムが書ける・プロダクトを作れるようにお互いに配慮しながらコードレビューしていきたいですね。

みなさんのコードレビューに対する考え方やご意見をお伺いしたいと思いますので、コメントやリアクションなどいただけたら幸いです。

ではまた！