コードレビューの観点を4つ紹介！新人エンジニア向けに具体的な項目を解説します

多くのweb業界では、新人、ベテラン関係なく他人のレビューをする機会があります。

しかし、コードレビューのやり方は教わることがなく「何を見たら良いのかわからない」と悩む方もいるのではないでしょうか。

実際、僕も新卒でエンジニアになった頃はどのようにレビューをすればいいのか本当にわかりませんでした。

今は、コードレビューにもずいぶん慣れてきたので、新卒エンジニアの頃に感じていた

• コードレビューで何を見たら良いのか
• 指摘をするときは何を注意したらいいのか
• 上司が何を期待してコードレビューを依頼しているか

といったポイントを踏まえて、コードレビューをするときの4つの観点についてお話していきます。

なお、今回の記事はあくまでも新人エンジニアに向けてのコードレビュー観点を示すもので、ある程度レビューに慣れている方はまた別の視点があるということは最初に明記しておきます。

コードレビューを新人エンジニアに依頼する目的

新人で入って間もない頃だと「上司が書いたコードのレビューなんてできない！」と思いますよね。

なぜなら、自分よりも圧倒的に豊富な知識と経験があるため、指摘できる点なんてないと思ってしまうためです。

しかし、それでも新人のあなたにコードレビューを依頼するのは下記のような理由があります。

• コードレビューを通して新人エンジニアに学んでもらう
• ケアレスミスのチェックをしてもらう
• 読みにくい箇所を明らかにしてもらう

コードレビューを通して実装方法について学ぶ

まず始めに、多くの場合、新人エンジニアには上司よりも実装力がありません。

それもそのはず、実務経験が長い上司の方が様々なことを知っていますし知識も豊富だからです。

しかし、だからこそソースコードを読むことによって新人エンジニアは学ぶことが数多くあります。

他人のコードを読むことによって、

などといったことを学習することができます。コードレビューをしてもらうと言いつつも、

裏の意図では「新人エンジニアに見て学習してもらう」ことがあることを忘れないようにしましょう。

ケアレスミスが減らせる

上司も当然人間なので、書いてあるコードにケアレスミスが混じっている可能性があります。

多くの場合、コードレビューに慣れてしまった数年目のエンジニアよりも、コードレビューの仕方がわからない新人エンジニアの方が時間をかけて丁寧にレビューをします。

上司からすると簡単なレビューであったとしても、こうしたミスを無くす可能性が上がるなら依頼しない手はありません。

したがって、気になった点は「ここってミスですか？」と質問してみるといいでしょう。そんな小さな質問が指摘になり、技術的なレビューができるようになっていくのです。

読みにくいコードの箇所を明らかにする

新人エンジニアは経験を積んでいるエンジニアと比べるとどうしてもコードを読む力が弱いです。

しかし、読む力が弱いことはコードレビューにおいては強みになります。

なぜなら、読む力が弱いということは、コードの理解にあたって

• 理解できないコードは読みにくいコード
• 理解できるコードは読みやすいコード

と考えることができるためです。（本当に理解力がないのはだめですが）

上司からすると、自分が書き慣れている書き方をするため、そのコードが読みやすいかどうかの意識が新人よりも薄れがちです。

新人エンジニアが読めないコードは、多くの場合は綺麗なコードではありません。読みにくいなと感じたら、それとなく「ここってどんな動作をしているのですか」と質問をするのもいいかと思います。

コードレビューの4つの観点

では、コードレビューを進めるにあたっての4つの観点を紹介していきます。

新人エンジニアが見るべきコードレビューの観点は、下記の4つです。

• コードがきちんと動作するか
• 変数やメソッドの命名が適切か
• 自分が読みにくい箇所がないか
• 設計書と照らし合わせて違和感を感じないか

コードがきちんと動作するか

まず、そもそも実装された部分が正しく動作するか確認する必要があります。

「確認されているから動作しないわけがない」と思われるかもしれませんが、テストにヌケモレがあり特定のケースでは動作しなかったパターンがたまに起こりえます。

コード上からそれを読み取れれば良いですが、今回の実装でどのような変更が加えられているか？を知っておくと、あらゆる側面からコードのチェックを入れることができます。

コードレビューと言いつつも、動作テストも立派なレビューの1つになることを覚えておきましょう。

変数やメソッドの命名が適切か

まずは、変数やメソッドがわかりやすい名前であるかは見ておきたいポイントです。

変数やメソッドについては、ある程度パターン化されており下記のQiitaなどは参考になるでしょう。

タイポのチェックもそうですが、「なんとなくこの変数に違和感があるな」と思って上記記事を調べてみると、実はもっと良い変数名が見つかったりします。

変数名やメソッド名の指摘も立派なコードレビューなので、気づいたときにどんどん指摘しましょう。

コードで読みにくい箇所がないか

上記でも触れましたが、理解しにくいコードは”自分の理解不足”か”本当に読みづらいコード”のいずれかです。

理解不足であれば、レビューをするためにPull Request（以下PR）の説明をしっかり読んだ上で、内容をコード実装者に聞かなければなりませんし、もしコードが読みづらいならどこで自分の理解が止まっているのかを見極めなければなりません。

自分が理解しにくかった箇所を指摘するだけでも、コードを改善するためには大きな意味を持ちます。したがって、書いてあるコードについては、とにかく理解できるまで聞くという姿勢で臨みましょう。

設計書と照らし合わせて違和感を感じないか

おそらくどのプロジェクトにも、プログラムをどのように組み込むかの設計書が存在します。

設計に基づいてコードが実装されているかわからないと思うかもしれませんが、だからこそ設計書とコードをそれぞれ見比べることに価値があります。

コードレビューの際に設計に合ったコードを見ていると、今度自分がコードを書く際にも設計を意識したコーディングが徐々にできるようになります。

そうすると、より設計に詳しくなり、レビューを依頼されるときも「こっちのほうが設計方針に合っているのでは…？」というシーンが出てくるようになるのです。

特に新人エンジニアの間は、コードを読むことはコードを書くこと以上のスキルアップになります。どのような設計方針でどのようなコードが書かれているのか見て自分のスキルアップにつなげていきたいものですね。

まとめ

ここまでの記事のポイントをまとめます。

今回は、新人エンジニアがコードレビューをするにあたっての観点についてお話しました。

今回はあくまでも新人エンジニア向けということで省きましたが、今回紹介した観点以外にもレビューをするにあたっての観点は数多くあります。

いろいろと試行錯誤をしていく中で「何をコードレビューの観点にしておくといいか」のチェックシートを自分の中で作っていきたいですね。