実務でコードレビューする立場になって感じたアレコレ
はじめに
This is poem.
筆者が実務で開発メンバーのプルリクエスト（以下、PR)をレビューする立場になって感じたアレコレを雑にですが、ポエムとしてまとめてみようと思います。
筆者
2020年4月にITエンジニアとしてのキャリアをスタートしたいわゆるジョブチェンジ組です。
2021年11月時点で現在、実務経験1年8ヶ月目、ITエンジニアとしては2社目です。
現在は業務でTypeScript/React/Next.js/PHP/Laravel/Dockerらへんをメインで使っています。フロントは苦手ですが、頑張ってます！！
補足：メインのアウトプットはブログに書いています。
本題の前に
結論、コードレビューすることには多くのメリットがあると感じています。
この記事では実際に僕がレビュワーとしてどんな観点でコードレビューしているかも恐縮ですが併せて書きますので、現在業務でコードレビューしている方に少しでも参考になったら嬉しいです。
また、現在は主にレビューされる側（レビュイー）の方に対してはコードを書くときのマインドとか注意点とかの参考になれば嬉しいです。
実務でコードレビューをやって感じたメリット
まずはメリットから挙げていきます。
コードのクリーンさが保てる
複数人のエンジニアで開発すると（コーディング規約等をちゃんと定めていたとしても）どうしても我流のコードが生まれてしまう可能性が高いと思います。
ここでいう我流のコードというのは既存コードと書き方が異なる書き方のコードというに意味も含んでいます。
複数人開発で大事なこととして、1つのアプリケーションの中ではコードの書き方の所作は統一されているべきだと思います。
API開発を例にすると
- どこに例外処理を入れるか
- DIはコンストラクタインジェクションにするかメソッドインジェクションにするか
- 変数命名、メソッド命名が他の既存コードに合わせているか
などなど。
レビュワーが上記についてのルールを把握しており、そのルール通りにコーディングできていることが前提にはなりますが、開発用のブランチに我流のコードがマージされてしまうことが防げることが大きなメリットだと思います。
レビュイーの勉強になる
これまでコードレビューを受けたことがある方であればわかると思いますが、コードレビューを受けることはとても勉強になります。
経験が浅い場合（僕もまだまだ浅いですが）、振られたチケットに書かれている仕様を満たすために全力でコードを書きますが、どうしても「仕様を満たすことだけ」に力を注いでしまうことが多いと思います。
アプリケーションの開発の最大の目的は顧客や社会の課題を解決することなので「仕様を満たすことだけ」に力を注いでしまうことが悪いわけでないですが、保守性や拡張性を意識したコードを書くこともエンジニアの仕事としては大事です。（保守性や拡張性の乏しいアプリケーションが育つと、世間のニーズへの対応スピードが遅くなってしまいます）
人は自分の実力以上のコードを書くことはできないので、自分以上の実力を持つ人に自分では気づけない保守性、拡張性を意識した観点からレビューを受けることは大きな学びになります。（僕は副業で開発案件に入らせてもらった時に初めてコードレビューというものを受けたのですが、衝撃でした）
（ちなみに僕はいつも自分にできる限界のレビューをしているつもりです...）
また、僕はレビューする時になるべくレビュイー自身が実装したコードを説明してもらっています。
自分が書いたコードは必ず自分で理解した上で書くべきだと思っており、これは間違っていないと思って続けています。
余談ですが、初学者向けの「コードの質を上げる方法」について結構前ですがまとめていますので興味があれば読んでみてください。そもそろブラッシュアップしたい。
レビュワーの勉強になる
コードレビューを実際にやって思ったのですが、結構レビュワーの勉強にもなります。
僕は現在、Next.jsとLaravel両方を書いているのですが、開発メンバーの1人が僕よりReact/Next.jsの使用歴は長く、上がってくるPRで「ああ、ここはこんなふうに書くといいのか〜」と思うことがしばしばあり、勉強になっています。
（この状態は良いのか悪いのかは置いておきます）
そういう意味での勉強ももちろんですが、「発者として」だけでなく「レビュワー」としてのレベルアップにも繋がると感じました。
レビューする時に「レビュイーのため（＝勉強）になるレビュー」をしようと色々調べたりしてコードの質にコミットすることができます。
これはプログラミングに限らず人に教えることで自分の理解も深まるというよくあるやつです。
また、レビューコメントの言い回しや良いコードへのコメントなど、1人のエンジニアとしてのレベルアップにも繋がっているのではないかと（勝手に）思っています。
コードレビューはアドバイスをするだけじゃなく、良いコードを褒める機会でもありますからね。
と言いつつ、忙しい時は褒めるコメントを入れることができていないのでこの記事を書きながら反省しています😢
実務でコードレビューをやって感じたデメリット
次にデメリット。
工数が膨らむ
僕が現状感じているデメリットはこの1つですが、やはり単純に工数が膨らむことですね。
この工数に関しては「我流のコードや低品質のコードをレビューすることなく開発用ブランチにどんどんマージしていった末、他メンバーがジョインした後や、改修・バグフィックスの時にその対応工数が膨らんでしまう」ことと比較するとマシなのではないかと思っているので、クリティカルなデメリットではないかもしれません。
ただ、これまで（ほとんど）レビューすることがなかった僕がレビューをしてみて、開発メンバーのPRレビューによって自分の担当タスクの実装時間が減ってしまっていることは体感しています。体感というか実際にそうなっています。
まあ単純に１つのタスクを終えるまでに
- 担当者の実装時間
- レビュワーによるコードレビュー時間
- 担当者によるレビュー反映時間
がかかるので仕方がないことですよね。
最近は上記の状況にも慣れてきて、コードレビューもれっきとした開発業務の1つと思っていますし、そもそもコードレビューは大切な業務です。
今後案件の見積をすることがあればレビューの時間も工数試算に入れると誓った。（通常積んでいるものかもですがw）
さいごに
この記事の内容の比率的に明白ですが、個人的にはコードレビューをすることはデメリットはあるものの、メリットの方が断然大きいと思っています。
もし良ければ以下の内容等についてご意見やご経験があればコメントを書いていただけたら嬉しいです。
- レビュワーはこういう観点を持つことも大事だよ！
- 実際にレビュワーを経験してこういうところが大変だった
- レビュワーしてレビュイーに伝えたいこと
- 記事で書いた内容以外でコードレビューして感じたメリットやデメリット
最後の最後に宣伝になりますが、神戸で「つながる勉強会」という勉強会を運営しています。関西圏の方、ご参加お待ちしてます。
Discussion