読者コードレビューをしてもらいたいけど、指摘されるのが怖い。事前にセルフレビューをしようと思うのだけど、やり方がいまいちわからない。コツとかあるのかな？
こんなお悩みにお答えします。
この記事で解説する「本質的なセルフレビューのやり方」を実践すれば、コードレビューで受ける指摘量を減らすことができ、自信を持ってレビューを受けられるようになりますよ。
僕自身、現役でフリーランスエンジニアをやっています。いまの現場では週1ほどコードレビューがあり、その度にセルフレビューを実践しています。僕が実際にセルフレビューをやってきて「これは効果があったな」というポイントを解説しますね。
世の中のインターネットの記事では、「セルフレビューをするならスペルミスがないか」「既存で共通のコードがないかをみましょう」等と書いている記事が多いです。もちろんそれらのことも大事なので、実践すべきです。
ですが、この記事ではそういった細かい木の枝のような情報ではなく、もっと本質的な幹の部分について解説していきます。
セルフレビューの本質とは
まず、セルフレビューは一体なんのためにやるのか？ここを理解しておくことでセルフレビューに対する重要性がわかるので、より本記事の内容が頭に入ると思います。
セルフレビューをやる目的を簡潔にいうと、レビューする側とされる側のストレスを減らすことです。事前にセルフレビューをしておけば、レビューする側も余計な指摘をせずに済みますし、レビューされる側も余計な修正をしなくて済みます。
セルフレビューをすることで、戻りを減らしチーム全体の生産性を高めるだけでなく、自分自身がスキルアップするためでもあると僕は考えています。
セルフレビューのやり方
ではセルフレビューのやり方を紹介します。下記の順で見ていきましょう。
- その処理は何をしているのか
- 仕様通りに動いているのか
- その処理はバグやデグレは起きないか
- なぜその実装なのか
- 他にベストな方法はないか
- 既に同じコードが他にないか
- そのコードは共通化できないか
- そのコードは将来も使えるコードか
その処理は何をしているのか
セルフレビューをするなら文法がどうこうというのは二の次です。そもそも、その処理は何をしているのかを説明できないと始まりません。なぜならコーディングの目的は、アプリやシステム開発をするためだからです。
たとえば、多くのプログラマーはなぜ開発をするのかというと、プログラミングをすることが目的ではないですよね。もちろん中には「俺はプログラミングが楽しいからただやってるだけだぞ」という方もいるかもしれません。
でも仕事をしている以上、お金をもらっているわけなので、そこではビジネスが発生していますよね。プログラミングはあくまで手段であり、目的ではありません。プログラミングという手段を用いて、あなたは仕事をこなすために実装をしているはずです。
だからこそ、結局のところ「その処理は何をしているのか？」を説明できるようにしておく必要があります。
仕様通りに動いているのか
その処理は仕様通りに動いているのかを確認することもポイントです。理由としては、プログラミングの世界には正解がないことが多いからです。つまり、正解がないということは、いろいろなパターンで実装をすることが可能です。
しかし、自分が良いと思って書いたコードでも、そのプロジェクトの規約に反していたり仕様と異なっていては意味がないです。
たとえ実装はできているとしても、ちゃんと仕様通りに動いているのかを見るのが重要になってきます。
その処理はバグやデグレは起きないか
実装した処理がバグを起こさないか、またデグレを起こさないかもチェックしましょう。
バグやデグレを起こしてしまうと修正するにあたり戻りが発生し、余計な工数がかかってしまいます。また、あまりにバグが多いと参画している現場の企業からの信頼性が低下しかねません。
バグが起きていないかどうかをチェックする場合、目視確認だけでは精度が低いです。そうではなく、きちんと単体テストのテストケースを網羅した上で、必ず単体テスト仕様書をもとにテストを行いましょう。少し面倒ですが、ここを徹底すればかなりバグは少なくなります。
なぜその実装なのか
なぜその実装なのかを説明できるようにしておくと良いです。というのも、プログラミングは複数のは正解パターンがあるケースが多いからです。
たとえば、AとBの実装方法があるとします。どちらの方法でも目的は達成できるのですが、保守性やパフォーマンスを考えるとAの方がベストです。
しかし、そこでBの選択をしていた場合、レビュー時に指摘が入る可能性が高いです。指摘が入る時にBの実装にした理由を説明できればまだ良いのですが、そこで理由を説明できない場合、「この人はあまり考えずに実装しているのかな？」と思われかねません。
そのため、「ただ動けば良い」という思考は捨て、その実装にした理由を説明できるようにしておくと良いでしょう。最初は間違っていてもOKです。根拠があって実装しているというスタンスが重要です。
他にベストな方法はないか
先述した内容と多少かぶるのですが、セルフレビュー時には他にベストな方法がないかを常に考えると良いですね。
自分が実装した処理には自信を持ちたい気持ちはわかるのですが、常に他にもっと良い方法はないかを考えることで、視野が広がります。
プログラマーであれば自己都合な実装ではなく、常にユーザーのために品質の良いシステムを作ることを優先すべきです。
ただこういうと、「いやいや、納期が厳しいんだからそんな常にベストな実装にしろとか、理想論でしょ」と思う方もいるかもしれません。
もちろん納期が厳しい業界というのは、僕自身も現役エンジニアなので、重々に理解していますし実感しています。なので、全てがそう上手くベストな実装ができるとは限らないこともわかっています。
ですが、プロである以上、限られた時間の中でいかにベストパフォーマンスを尽くせるかが重要ではないでしょうか。できるかどうかは別として、こういった意識が必要ではないかと思っています。
既に同じコードが他にないか
これはあるあるだと思うのですが、頑張って実装した処理は、すでに過去に実装されていたという場合があります。
この辺りは実装時に見極めるべきなのですが、実装時に見落としていたり、そもそも「すでに同じコードがあるかどうかという考えがなかった」という場合があります。
僕自身、既に同じコードがあるにも関わらず、自分で考えて実装したことはよくあります。レビュー時に指摘が入って修正したことも。
既存である処理をまた別のところで実装すると、あとあとメンテナンスが大変になります。たとえば、仕様変更が入った場合、同じ処理が2箇所あると2箇所修正しないといけないですよね。もしここで1箇所の修正が漏れていた場合、バグにつながります。
そのため、他に同様の処理がないかはチェックしてみましょう。
そのコードは共通化できないか
実装した処理は共通化できないかを考えてみると良いです。共通化することでメンテナンス性が向上しますし、同じような処理を将来的に実装しそうな時に、未来の開発者のためになります。
プログラミングは同じような処理を使い回すことはよくあります。また、多くの現場では共通化用のクラスがあります。まずはそういったクラスを見て、こういうケースは共通化すべきという判断材料を得ると良いですね。
そのコードは将来も使えるコードか
実装したコードは将来も使えるコードかを確認しましょう。プログラミングは先を見据えて実装すると良いです。
たとえば、今動いているだけの付け焼き刃のコードでは意味がありません。そういったコードは大体バグにつながります。
もちろん、時代は変わりますので技術も進化します。なので永久的に使えるコードを実装するのは不可能に近いです。そういう意味ではなく、可能な範囲でできるだけ長く使えるコードを実装しようということです。
セルフレビューのコツ
最後にセルフレビューのコツについてもご紹介しますね。下記3つをみていきましょう。
- 頭の中で人に説明する
- 読んでも不明なコードは動かしてみる
- 複雑な処理はメモを残しておく
頭の中で人に説明する
セルフレビュー時は「頭の中で人に説明する」ようにすると良いですよ。なぜなら人に説明できるということは、自分が理解していないとできないから。
たとえば自分だけが理解しているつもりでも、いざレビュー時に人に説明しようとなった場合、上手く説明できないケースはよくあります。
そのため、セルフレビュー時に頭の中で人に説明できるレベルまで高めておくことで、スムーズにレビューを受けることができます。
読んでも不明なコードは動かしてみる
コードを読んでもわからない場合、実際にシステムを動かしてみましょう。コードは実際に動かしてみないとイメージがつかない場合があるからです。
例えば動かす際は、デバッグをしながら、コードの動きを解析してみてください。フロント系の言語であればブラウザの検証ツール、サーバー系の言語であればIDE(開発ツール)でブレークポイントを置いてデバッグしましょう。
もしコメントや変数名をわかりやすくすることでコードの動きがイメージしやすくなるのであれば、それはコメントや変数名が悪い可能性が高いので、修正しておきましょう。
複雑な処理はメモを残しておく
簡単な処理はコードやコメントを見ればわかるかもしれませんが、複雑な処理はなかなか説明しにくかったりします。実装してから時間が経つと処理の内容を忘れてしまいますので、そうなると余計に説明しにくくなります。
そういったケースに備えて、レビュー用のメモを残しておくと良いですよ。
自分自身がなんとなく理解できていたとしても、それを人に説明できなければ伝えることが難しく、伝わらなければ意味がないです。
複雑で難しいコードは、レビュー用のメモを残しておくと良いですね。
まとめ
セルフレビューのやり方について解説しました。本記事の要約です。
- その処理は何をしているのか
- 仕様通りに動いているのか
- その処理はバグやデグレは起きないか
- なぜその実装なのか
- 他にベストな方法はないか
- 既に同じコードが他にないか
- そのコードは共通化できないか
- そのコードは将来も使えるコードか
上記の通り。
本記事で解説した内容はどれも本質的なことに絞っていますので、ぜひ実践してみてくださいね。繰り返していけばセルフレビューの原理原則を理解でき、プログラマーとしてスキルアップができ、市場価値を高められますよ。
今回は以上です。
