明日のコードレビューから取り入れられるヒント

紹介されているテクニックの中でも私自身が個人的に特に参考になったヒントや、自分のレビューで意識していきたいと思ったポイントを3つに絞ってまとめます。

また前提となりますが、この本はレビューにおけるエンジニア間のコミュニケーションや上手な伝え方に特化して解説した本です。具体的なコードの指摘方法といった技術的な観点については書かれていません。

まず、「率直さ」を心がけること。「率直さ」について本では以下のように定義されています。

相手に対する敬意を忘れず、伝えるべきポイントを的確に、かつ簡潔に伝えること（p.30）

若手で先輩に対して高圧的な物言いをする人はあまりいないと思います。しかし、自信のなさや遠慮から、表現が回りくどくなってしまうことはないでしょうか。（私はよくあります…）

でも、コメントが回りくどいと相手に意図が伝わりづらく、コミュニケーションコストも増えてしまいます。よく考えれば、自分がレビューされる側だとしても、変に気を遣われたコメントをもらったらあまりいい気はしないですよね。

レビューにおける率直な姿勢の大切さについては以前からなんとなく気づいてはいたものの、この本で改めて考えさせられました。相手が誰であっても、敬意や配慮を前提とした上でできる限りシンプルに伝える努力をすることが大切だと思います。

レビュアーが間違ったということは、1つのサインです。そこには間違いやすい理由があるのかもしれません。（p.98）

これはもともとレビュイーに向けたアドバイスとして書かれていますが、私はレビュアー側の心構えとしても重要な視点だと感じました。

自分はチームの中で最も経験年数が浅く、レビューをするにもなにせ自信がありません。明らかなタイポとかならまだしも、判断に迷うようなケースだと自分のほうが間違っていたらどうしようと尻込みしてしまうんですよね。

でも実際のところ、レビュアーが迷うのは当人の知識不足だけが原因ではないと思います。

自分の経験に照らしてみても、自分で一通り調べてわからなかったケースでは、コード自体は正しくても可読性が低かったり前提条件が共有されていなかったりなど、なんらかの課題があったことも少なくなかったと感じます。

その場で自分がコメントしなければ、他のメンバーや将来そのコードを読む人たちも同じように迷うかもしれません。そう考えると、勇気を出してコメントをする価値は十分にあると思います。結果的に自分の勘違いだったら、一言謝ればいいだけです。

間違った指摘でも役に立つ可能性があるので、もっと気軽にコメントしたり質問したりしていいんだな、と思わせてくれた一文でした。

最後は具体的なテクニックですが、「聞きたいことを絞る」（p.180-181）です。

聞きたいことが複数あるとき、まとめて全部質問してしまうと、回答者が混乱して必要な答えが漏れてしまうことがあります。そのため、優先度の高いものから1つ1つ順番に質問していこう、という内容です。

私は今まで、複数質問したいときは箇条書きにして同時に聞いていました。箇条書きにすれば情報が整理されているからOKだと思っていたのです。
でもやはり、一番初めの質問に対する回答しか得られなかったという経験がありました。同時に質問すれば一気に解決して効率的、とはいかないわけです。

まず1つ目を聞いて、それが解決したら次を聞く。少し時間はかかるように感じますが、順を追って質問していったほうが、結果的に自分の必要な回答が確実に得られやすくなるということですね。

これはコードレビューに限らず、Slackなどの日々のテキストコミュニケーションでも活きるテクニックだなと思いました。

おわりに

この本は、特に1〜2年目くらいの若手エンジニアの方におすすめしたいです。

この本を読んで真っ先に思ったのは、「1年目の時に読んでいればな〜！」ということでした。

私自身、現在新卒2年目（もうすぐ3年目）の若手Webエンジニアです。
コードレビューは日常的な業務として行っていますが、そのやり方は誰かから教わったわけでもなく、チームの先輩たちを見よう見まねでやってきたに過ぎませんでした。

実際、私が過去にやってしまった失敗もいくつかこの本に書かれており、1年目の最初の時に読んでいればそんな間違いも犯さなくて済んだのかも…と思いました。

とても読みやすい本ので、技術書に苦手意識のある方にもおすすめです。

ここに挙げた3つ以外にも明日からすぐ使えるヒントがたくさん載っていたので、気になる方はぜひ読んでみてください。