若手がコードレビュー専任担当になった話

はじめに

id:d_shr です。
MailDealer開発チームでコードレビューを担当しています。
去年の４月からコードレビュー担当になり１年が経とうとしているので、若手(新卒2年目)がコードレビューをやって良かったこと、難しかったことなどを振り返ってみようと思います。

はじめに
コードレビューとは
コードレビュー担当をしていて良かったこと
コードレビュー担当をしていて難しかったこと
まとめ

コードレビューとは

一言で言えば、書いたコードを他の人にレビューしてもらうこと。
主に以下について確認します。

コード規約違反がないか？
保守性の低いコード、冗長なコードになっていないか？
コードミスがないか？
仕様通りのコードになっているか？

コードレビュー担当をしていて良かったこと

① コードを読む力がつく

元々コードを読むことには自信がありましたが、ここ１年でかなりのコードを見たので、さらに自信がついたかなと思っています。
いろんな人が書くコードを読むので、読む力はかなりつきます。

② レビュワーの観点がつく

コードを書くときに、良いコードを書かなきゃと可読性を意識しますよね。
コードレビューをするようになってから実装をするときに、「このコードを自分がレビューするとしたら…」という視点が持てている実感あり、良いコードが書きやすくなっている自覚があります。
レビュワーとして指摘しているようなミスはできないし、書いた段階で気づけるので、効率よくコードが書けるようになった気がします。

③ 指摘が自分に返ってくる

②と繋がる話ですが、指摘した内容が自分に刺さることは少なくありません。
「偉そうに指摘したけど、人のこと言えないなぁ…自分がコード書くときは気をつけないと。」
みたいな感じです。
このようなことも含めて自分の成長に繋がっています。

④ 他の人が書くコードが読める

他の人のコードを読むことはすごく参考になります。
自分よりもエンジニア歴が長い人たちのコードが読めるので、「こういう書き方もあるんだ」と参考になることが多いです。

⑤ いろんな機能の仕様、中身を把握できる

コードレビューを行うためには最低限仕様を把握している必要があります。
開発中の機能の3〜4割程度のコードレビューを担当していますが、その分だけ仕様を把握することができています。
開発中によくわからないエラーに直面したときはいろんな機能を把握できているおかげで解決が早い事が多いです。

コードレビュー担当をしていて難しかったこと

① 指摘を出す

ベトナムの開発メンバーが書いたコードをレビューすることがほとんどです。
顔を合わせて話ができない、日本語で説明できない相手に指摘をすることになります。
指摘を返すときに、理由を明確にして相手が納得できるような指摘を返すことを心がけていますが、言語の壁があったり、指摘したことに実は意図があったりと最初は難しかったです。

② ついでに直して欲しいを指摘で返してはいけない

修正したことに関連して既存でイケてないコードがあると、ついでに直して欲しいと思うことがあります。
修正すべきなので良かれと思って指摘として伝えると、コードを書く人は不満を持ってしまうことがありました。
指摘ではないけど修正してほしいという意図をしっかり伝えて、コードを書く人に不満を持たせないように心がけています。

③ コード規約に載っていない暗黙のルール

コード規約や正しく書いていることを確認するチェックリストなどのドキュメントはありますが
どこにも書かれていないけど、こういうコードは良くないみたいな観点はあると思います。
「こういう書き方はしてほしくない」、「この場合はこういう書き方をしてほしい」、「この関数はこういう使い方をしてほしい」…etc
そういったことを明確なルールにしていくことが難しいと思いました。
ルールになっていなかったものや、指摘が多かったことをまとめたドキュメントを作成してメンバーに展開しました。

まとめ

若手のコードレビューはオススメ

コードを読む力、読むことで参考になること、コードを書くときに活かせるなど
メリットがたくさんあり、成長に繋がることが多かったと思います。
出した指摘から自分の意識と高めることができたり、レビュワーの視点が身についたり良かったことが多かったです。
コードが読めて、ある程度実装ができるなら、どんどんコードレビューを積むことは良いことではないかと思いました。