コードレビューを「するとき」「してもらうとき」の注意点

コードレビューを「するとき」「してもらうとき」の注意点

プログラマーが書いたソースコードに、完璧なものはありません。特に、自分一人で書いていると客観性を欠いたプログラムになってしまうことがよくあります。開発現場では、他者からの視点が重要になります。そこで今回は、コードレビューの基礎知識と、効率的なコードレビューの方法を解説します。

コードレビューとは

プログラマーが書き上げたソースコードは、大抵の場合、バグや脆弱性を抱えた不完全なものになります。そこで、誰かが書いたプログラムのソースコードを、別の誰かも査読します。これをコードレビューといいます。

コードレビューを行うことで、バグや脆弱性が発見されます。また、処理手順の効率化を発見できることもあり、コードレビューを行うことで質が上がる可能性があります。

コードレビューは誰がすべきか

コードレビューの目的は、一言でいえばソフトウェアの品質向上にあります。しかし、実はそれだけではなく、コードレビューにはさまざまなメリットがあります。たとえば、コードレビューをすることで、ソースコードを手の入れやすいものにすること (属人性の排除) 、コードを書いた人の技術レベルの把握ができること、コードを書いた人のレベルアップを図れること、他人のコードを読むことで気づきや学びを得られること、などが挙げられます。

品質向上のためだけであれば、コードレビューはプログラムに精通している上級者が行うほどいいことになります。実際にそうした場合も多いのですが、同等のレベルの技術者同士や初心者がコードレビューをすることにも意味があります。同等レベルの技術者同士の場合はコードレビューを通じてお互いの技術力を高め合うことができ、技術者同士のコミュニケーションの活性化にもつながります。初心者や中級者が上級者のコードをレビューする場合は、優れたコードを精読すること自体で学習でき、スキルの上達やナレッジの共有につながります。

初心者がコードレビューした場合は、上級者が再チェックし直すなどの配慮も必要ですが、いずれにせよ、コードレビューは会社の方針やそのときどきの状況によってさまざまな技術レベルのプログラマーが担当することになります。

コードレビューをするときの注意点

コードレビューは、単にコードの悪いところ、おかしなところだけを指摘すればいいというものではありません。誰しも、自分が書いたコードについて強い言葉で一方的にダメ出しをされてしまうと気持ちが沈んでしまうものです。良い部分は褒めること、ミスを責めたり人格を否定したりするような伝え方をしないことなどを心がけ、相手の気持ちについても配慮すべきです。神経質になりすぎる必要はありませんが、コードレビューは伝え方によって相手の受け取り方が大きく変わることは確かです。

その上で、良くないと思った部分について理由を添えて伝えます。ロジックを用いて相手が納得できるように伝えることが大切です。また、自分なりの提案とその理由も書くようにすれば前向きなコードレビューになります。さらに、意図がわからない部分については本人に確認しましょう。

初級者が上級者のレビューをする場合も、わからなければ尋ねることを基本とすべきです。手間はかかりますが、結果として誰が読んでもわかりやすいコードにブラッシュアップされれば、コードレビューをする意味があったということになります。

コードの品質向上だけではなく、スキル向上やナレッジ共有もコードレビューの目的に含まれていることも意識しておくべきです。このことが抜け落ちてしまうと、レビューの中身が単なる揚げ足取りや、自分のやり方の押し付けになってしまうおそれがあるからです。相手のスキルの向上 (あるいは自分のスキル向上) を視野に入れながら、一緒により良いコードにしていくことを目指す、ということをゴールにすべきでしょう。

コードレビューをしてもらうときの注意点

コードレビューを受ける側も、きちんと「聞く耳を持つ」ことが求められます。レビューを受ける側も、コードレビューは品質向上以外にスキル向上などにも役立ち、コミュニケーションの一環だということを自覚している必要があります。

技術的なポイントも挙げておきましょう。コードレビューのためにコードを提示する際は、そのプログラムのソースコードの目的や意図もあわせて伝えるのが定石です。というのも、プログラムだけを単体で渡されても、レビューする側はそのプログラムのソースコードの意図がわからないことが多いからです。どのような目的のために書かれたソースコードかが理解できれば、処理手順の効率化などについての指摘もしやすくなります。さらにソースコードに適切なコメントも挿入しておくと、レビュアーが解読しやすいコードになります。

また、プログラムが期待どおりに動くかどうか確認するテストコードを作成したときは、そのテストコードも一緒にレビューしてもらいましょう。テストコード自体にバグがないことを確認するのはもちろん、テストコードを同時にレビューするほうがソースコードの完成度は向上します。テストコードがあるほうがレビューしやすいという理由もあるので、すべての材料を提供するよう心がけましょう。

もう一つ、コードレビューがあると、ともすればレビュアーにバグを見つけてもらえばいいという考え方になってしまいがちですが、これは間違いです。バグを作ってしまう最終的な責任はあくまでコードを書いたプログラマーが背負うべきものだということを忘れないようにしましょう。

コードレビューを効率よく行う方法

ここからはコードレビューを効率よく行う方法を解説します。

コードレビューは絶対に必要な作業ではないので、業務に含まれていない会社も多いです。しかし、コードレビューを行うことで会社全体のスキルが飛躍的に向上するので、以下を参考にしてぜひ実施してみましょう。

小さな単位で行う

コードレビューは小さな単位で行います。特に、プロジェクトに参画して間もない人のソースコードはこまめにレビューする必要があります。

通常、変数名の付け方やフレームワークの使い方は、最初に間違えていると指摘されるまでずっと間違え続けるものです。このようなソースコードをまとめてレビューすると、すべての部分に改善点があるソースコードになります。

ですので、小さな単位でコードレビューを行えば、間違いがあった場合も、その後のソースコードに活かせます。また、レビュー者も数分~数十分で終わるコードレビューなら負担になりにくいのです。

コードレビュー用ツールを活用する

コードレビューを支援するためのツールを上手に活用して、レビューの効率化を図ることもできます。レビューの依頼の自動化、複数レビューの進捗管理、修正の状況の可視化などの機能があるツールを、必要に応じて導入してみましょう。また、こうしたツールを使っていても、重要な箇所については対面でやりとりしたほうがスムーズに意思疎通ができる場合もあります。ツールを通じたコミュニケーションと対面でのコミュニケーション、両者をシーンによってうまく使い分けるようにしましょう。


日常業務の中に少しコードレビューの時間を組み込むだけで、プログラミングに対する全体の意識が向上するかもしれません。このような技術に対して意欲的なエンジニアを職場全体で増やすことによって、プロジェクトに追われない理想の職場ができるのです。

求人詳細ページへのリンク

関連コラム

職種関連カテゴリ

コードレビューを「するとき」「してもらうとき」の注意点のページです。ITエンジニア・移動体通信エンジニア(技術者)の派遣求人ならブレーンゲート。株式会社ブレーンネットはシステムエンジニアやネットワークエンジニア、プログラマーの派遣・転職をサポートいたします。