【ITエンジニア向け】セルフレビューのやり方【コードの品質を高める】

こんなお悩みにお答えします。

この記事では、本質的なセルフレビューのやり方とコツを解説します。

記事を書いている僕は、現役エンジニアです。今の現場では週1回ほどコードレビューがあり、その度にセルフレビューを実践しています。

この記事を読めば、コードレビューで受ける指摘量を減らせて、自信を持ってレビューに臨めるようになります。

指摘の量を減らしたい方は、ぜひ最後まで読んでみてください。

セルフレビューを行う意味

まず、セルフレビューは一体何のためにやるのかを整理します。

目的を簡潔に言うと、レビューする側とされる側のストレスを減らすことです。

お互いの手間が減る

事前にセルフレビューをしておけば、レビューする側も余計な指摘をせずに済みます。

レビューされる側も、余計な修正をしなくて済みます。

自分のスキルアップにもつながる

セルフレビューには、戻りを減らしてチーム全体の生産性を高める効果があります。

それに加えて、自分自身がスキルアップするためでもあると僕は考えています。

なお世の中の記事では「スペルミスがないか確認しましょう」といった内容が多いです。

もちろんそれらも大事なので実践したいところですが、この記事では本質的な幹の部分を解説していきますね。

セルフレビューのやり方

セルフレビューで確認すべき観点を8つ紹介します。

下記の順で見ていきましょう。

その処理は何をしているのか

セルフレビューをするなら、文法がどうこうというのは二の次です。

そもそも、その処理が何をしているのかを説明できないと始まりません。

なぜならコーディングの目的は、アプリやシステム開発をするためだからです。

プログラミングは手段であって目的ではない

多くのITエンジニアにとって、プログラミングそのものが目的ではないはずです。

中には「プログラミングが楽しいからやってるだけだ」という方もいるかもしれません。

でも仕事をしてお金をもらっている以上、そこにはビジネスが発生しています。

プログラミングという手段を用いて仕事をこなしているので、処理の目的は説明できる状態にしておく必要があります。

仕様通りに動いているのか

その処理は仕様通りに動いているのかを確認することもポイントです。

プログラミングの世界には正解がないことが多いからです。

正解がないということは、いろいろなパターンで実装することが可能ということでもあります。

良いコードでも仕様と違えば意味がない

自分が良いと思って書いたコードでも、プロジェクトの規約に反していては意味がないんですよね。

たとえ実装はできているとしても、ちゃんと仕様通りに動いているのかを見るのが重要になってきます。

その処理はバグやデグレを起こさないか

実装した処理がバグを起こさないか、またデグレを起こさないかもチェックしましょう。

デグレとは、今まで正常に動作していたものが動作しなくなるトラブルのことです。

バグが増えると信頼に響く

バグやデグレを起こすと、修正にあたって戻りが発生して余計な工数がかかります。

あまりにバグが多いと、参画している現場の企業からの信頼性が低下しかねません。

目視確認では精度が足りない

バグが起きていないかをチェックする場合、目視確認だけでは精度が低いです。

きちんと単体テストのテストケースを網羅した上で、仕様書をもとにテストを行いましょう。

少し面倒ですが、ここを徹底すればかなりバグは少なくなるんですよね。

バグを減らす具体的な方法は、以下の記事でまとめています。

なぜその実装なのか

なぜその実装なのかを説明できるようにしておくと良いですね。

というのも、プログラミングは複数の正解パターンがあるケースが多いからです。

AとBの実装方法がある場合

たとえば実際の開発で、AとBの実装方法があるとします。

どちらでも目的は達成できますが、保守性やパフォーマンスを考えるとAの方がベストだとします。

そこでBを選択していた場合、レビュー時に指摘が入る可能性が高いですね。

理由を説明できないと印象が悪い

指摘が入る時にBにした理由を説明できればまだ良いのですが、説明できないと厳しいです。

「この人はあまり考えずに実装しているのかな」と思われかねません。

最初は判断が間違っていてもOKで、根拠があって実装しているというスタンスが重要です。

他にベストな方法はないか

セルフレビュー時には、他にベストな方法がないかを常に考えると良いですね。

自分が実装した処理には自信を持ちたい気持ちはわかります。

ですが常にもっと良い方法はないかを考えることで、視野が広がります。

「納期が厳しいから理想論でしょ」という声について

こう言うと「納期が厳しいのに常にベストな実装にしろなんて理想論でしょ」と思う方もいるかもしれません。

納期が厳しい業界だというのは、僕自身も現役エンジニアなので重々理解していますし実感しています。全てがうまくベストな実装ができるとは限らないこともわかっています。

ですがプロである以上、限られた時間の中でいかにベストパフォーマンスを尽くせるかが重要ではないでしょうか。

既に同じコードが他にないか

これはあるあるだと思うのですが、頑張って実装した処理がすでに過去に実装されていた場合があります。

実装時に見落としていたり、そもそも同じコードがあるかどうかという考えがなかったりするケースですね。

僕自身、既に同じコードがあるにも関わらず、自分で考えて実装したことはよくあります。レビュー時に指摘が入って修正したこともあります。

メンテナンスが大変になる

既存である処理をまた別のところで実装すると、後々メンテナンスが大変になります。

たとえば仕様変更が入った場合、同じ処理が2箇所あると2箇所修正しないといけません。

もしここで1箇所の修正が漏れていた場合、バグにつながります。

そのコードは共通化できないか

実装した処理は共通化できないかを考えてみると良いですね。

共通化するとメンテナンス性が向上しますし、未来の開発者のためにもなります。

判断材料の見つけ方

プログラミングでは同じような処理を使い回すことがよくあります。

多くの現場には共通化用のクラスがあります。

まずはそういったクラスを見て、共通化すべきケースの判断材料を得ると良いですね。

そのコードは将来も使えるコードか

実装したコードは将来も使えるコードかを確認しましょう。

プログラミングは先を見据えて実装すると良いです。

付け焼き刃のコードは結局バグになる

たとえば、今動いているだけの付け焼き刃のコードでは意味がありません。

そういったコードは大体バグにつながります。

永久に使えるコードは存在しない

もちろん時代は変わりますので技術も進化します。

なので永久的に使えるコードを実装するのは不可能に近いです。

セルフレビューのコツ

最後にセルフレビューのコツを3つ紹介します。

どれもすぐ実践できるものです。

頭の中で人に説明する

セルフレビュー時は「頭の中で人に説明する」ようにすると良いですね。

なぜなら人に説明できるということは、自分が理解していないとできないからです。

説明しようとして初めて気づく

自分だけが理解しているつもりでも、いざ人に説明しようとするとうまく説明できないケースはよくあります。

頭の中で人に説明できるレベルまで高めておくと、スムーズにレビューを受けられます。

読んでも不明なコードは動かしてみる

コードを読んでもわからない場合、実際にシステムを動かしてみましょう。

コードは実際に動かしてみないと、イメージがつかない場合があるからです。

デバッグの手段

読みにくさの原因がコード側にある場合

コメントや変数名をわかりやすくすることで動きがイメージしやすくなるなら、名前が悪い可能性が高いです。

その場合はコメントや変数名も修正しておきましょう。

他人のコードを効率よく読む方法は、以下の記事で解説しています。

複雑な処理はメモを残しておく

簡単な処理はコードやコメントを見ればわかるかもしれません。

ですが複雑な処理は、なかなか説明しにくかったりします。

時間が経つと自分でも忘れる

実装してから時間が経つと処理の内容を忘れてしまいます。

そうなると余計に説明しにくくなります。

レビュー用のメモを残す

そういったケースに備えて、レビュー用のメモを残しておくと良いですね。

自分がなんとなく理解できていたとしても、人に説明できなければ伝わりません。

セルフレビューは枝葉より幹を見るのがポイント

セルフレビューのやり方とコツを解説してきました。

重要なポイントをまとめます。

スペルミスの確認のような枝葉も大事ですが、それだけでは指摘は減りません。

処理の目的と実装理由を説明できる状態を作ることが、指摘を減らす決め手になります。

スキルアップの進め方は、以下の記事でまとめています。