レビュー指摘は成長のチャンス!新人エンジニアが1年間で受けたレビュー指摘を分析してみた

こんにちはカズシです。世間では東京オリンピックが始まりましたね。私が好きな卓球を観戦している時は熱が入って部屋の温度が2℃くらい上がっている気がします。
早いもので7月で私がシステム開発グループに配属されてちょうど1年になりました。今では4つの機能拡張プロジェクトを経て、メキメキと成長しております。今回はコードレビューについてお話したいと思います。

アトラスのレビュー文化

アトラスのシステム開発グループ(以下、シス開)ではサービス開発のコードはもちろん、GASなどの簡単な社内ツールでもコードレビューを実施しています。コードではありませんが、仕様書や設計書、ブログの記事など、様々なドキュメントに対してレビュー工程を設けています。またレビューはコミュニケーションの一種であるという考えから、相手を思いやる行動が重視されています。レビューの目的は以下の2つです。

  1. 間違い(バグ)を早期に発見して、品質を高めること
  2. 改善と学習の機会を作ること

一般的には1の内容が重視されがちですが、私の中では2の意識が強く、アドバイスをもらえる場所と捉えています。コードレビューでは、シス開の必読書であるリーダブルコードプリンシプルオブプログラミングの内容や各言語のコーディング規約をレビュー観点としています。また、シス開ではGitHub上でのプルリクエスト(PR)とレビュー指摘を受けた数をスプレッドシートに集計しています。せっかくデータを集めているので活用しようということで、今回は私がこの1年間受けたレビュー指摘を振り返りました。

数値で見るレビュー指摘

では早速、1年間 (2020年8月~2021年7月) の結果を見ていきましょう。
PR:144件, レビュー指摘:160回, PR1件あたりの指摘数:1.1回
参考までにアトラスでの開発歴が3年以上の先輩方のPR1件あたりの指摘数が0.2回以下ですので、私がいかに沢山指摘を受けているかわかると思います。
次に月毎のそれぞれの数値の推移を見ていきましょう。

月間PRあたりのレビュー指摘数

順調な右肩下りですね!年明けからはPRあたりの指摘数が1.0回を下回り始めました。しかし、気を抜くと4月のように、いきなり数値が高くなるのでまだまだ油断できない状態です。

内容で見るレビュー指摘

次にレビュー指摘を内容から4つに分類し、件数が多い順にランキング形式で見ていきます。

1位 コーディング規約違反 (38.0%)

コーディング規約の違反に対する指摘です。各言語の規約は実装前に一通り確認していますが、いざコードを書いていると意識が薄れてしまいます。最初のうちは1つのPRで20近くの規約違反を指摘されたこともありました。こうしたコーディング規約ミスはJavaならばCheckstyle、JSならばESLintなどの静的解析ツールを設定することで、レビュー前に自身で気づくことができます。またIDEでのフォーマッターの設定も有効です。アトラスでもこれらのツールの設定は必須としていますが、私は設定したつもりができておらず数ヶ月間、レビュワーの方の負担を大きくしてしまっていました。レビュワーの方に本来のレビューに集中してもらうためにも指摘0を目指すべき項目です。

2位 改善の提案 (28.2%)

「こう書いた方がシンプルで読みやすい」「こう書いた方が効率が良い」「この部分は共通化できる」などコードが間違っている訳ではありませんが、さらに改善するための指摘です。単に動くだけでは良しとはせず、細部まで美しいコードにするためのプロ意識をこれらの指摘から学びました。私自身もこの指摘を受けて視野が広がり、コーディングの幅も広がったので、一番成長に直結する指摘でもあります。

3位 ミスの指摘 (25.3%)

コードが間違っている場合の指摘です。単純に不等号が逆のようなケアレスミスもありますが、システムや仕様、言語に対する理解が浅く、「知らなかった」ことが原因であることが多く、まだまだ勉強が足りないなと日々感じています。例外処理も実のところ、構文を知っているだけの状態だったので、レビューのやりとりの中で実践的な使い方を学びました。この項目の指摘を減らすことがビギナー脱却への第一歩だと思うので、成長の指標としていきます。

4位 誤字脱字 (8.5%)

コメント文章や変数名のスペルミスなどの指摘です。自分でも十分に確認しているつもりなのですが、やはり誤字脱字は0にはなりません。私の場合、英語のスペルミスが大半でした。自分なりに考えた結果、キャメルケースではパッと見てスペルが正しいか判断しにくいので、ミスを見逃しているのではないかと思います。言い訳で終わらせず、英語のスペルには、より一層注意を払いたいと思います。また、エディタの機能で、スネークケースとキャメルケース・大文字と小文字を簡単に切り替えられるというアドバイスもあったので活用していきます。

おわりに

実際に数値化することで、自身の成長を実感できたので個人的には大満足です。コードレビューはプロダクトの品質向上だけでなく、自身やメンバーのスキルアップにも繋がる大切な工程です。今後は指摘を受けるだけでなく、後輩の成長に繋がる良い指摘も増やしていきたいです。

この記事を書いた人