はい、絶対にやるべきです。
これは会社の規模に関わらず、たとえプログラマーが2人しかいなくても、実施すべきです。多くの人はコードレビューが時間の無駄だとか、あら探しだと思いがちですが、全くそうではありません。一番簡単な例え話をしましょう。
あなたは非常に重要なレポートを作成し、大ボスに送ろうとしています。送信ボタンを押す前に、信頼できる同僚に一度読んでもらって、誤字脱字がないか、文章がおかしくないか、データが間違っていないかを確認してもらいませんか？
コードレビューとは、まさにこのことです。ただ、『レポート』が『コード』に、『ボス』が『ユーザー』に変わるだけです。
これを行うことで、いくつかの即効性のあるメリットがあります。
-
問題を早期に発見でき、コストが最小限に抑えられる。 バグがコードを書き終えた直後に同僚に発見されれば、修正には数分しかかからないかもしれません。しかし、そのバグが発見されずに製品がリリースされ、ユーザーが遭遇した場合、その代償は非常に大きくなります。軽ければユーザーからの不満、重ければ会社に損害を与えかねません。その時になって修正しようとすると、ロジックを再確認し、テストし、リリースするという一連のプロセスで、半日や一日があっという間に過ぎてしまいます。どちらのコストが高いかは一目瞭然です。どんなに経験豊富なベテランでも見落としはあります。複数の目でチェックすることは決して無駄ではありません。
-
知識共有により、「属人化」を防ぐ。 スタートアップ企業が最も恐れることは何でしょうか？それは、あるモジュールについて一人しか理解しておらず、その人が休暇を取ったり退職したりすると、その業務が麻痺し、誰も手を出せなくなることです。コードレビューは、この問題を大きく軽減できます。Aが書いたコードをBがレビューすることで、Bはその業務を直接担当していなくても、コードを見続けるうちに大まかなロジックを理解できるようになります。逆もまた然りです。お互いのコードを見ることで、チーム全体の技術レベルとプロジェクトへの理解度が徐々に均一化され、「知識のサイロ化」を防ぐことができます。
-
コードスタイルを統一し、メンテナンスを容易にする。 想像してみてください。あるプロジェクトで、ある人はこう書き、別の人はああ書く、といった具合にコードスタイルがバラバラだったらどうでしょう。半年後に自分の書いたコードを見返しても、理解するのに時間がかかるかもしれません。ましてや、他人が書いた「難解なコード」をメンテナンスするとなると、なおさらです。コードレビューは、全員が統一された規約に従うことを強制し、コードがまるで一人の人間によって書かれたかのように見せる効果があります。このようなコードは、誰が引き継いでも容易に理解でき、可読性と保守性が格段に向上します。
-
コミュニケーションと成長を促進する。 レビューのプロセスは、実は技術的な交流のプロセスでもあります。他人がどのように問題を解決しているかを知ることができ、また、他人から改善提案を受けることもできます。新人にとっては最も早い成長方法の一つであり、ベテランにとっても独りよがりになるのを防ぐことができます。
多くの人が懸念する「開発速度の低下」について：
短期的には、確かに一つの工程が増えることになります。しかし長期的には、バグ修正、本番環境でのトラブル対応、プロジェクトの引き継ぎにかかる時間を大幅に節約してくれます。これは車を運転するようなものです。速く走るためだけに、ブレーキやバックミラーを取り外すことはできません。コードレビューは、あなたのプロジェクトにとっての「ブレーキ」と「バックミラー」であり、より安定して、より遠くまで進むことを可能にします。
導入当初は慣れないため、「あら探し」だと感じてしまうかもしれません。だからこそ、ルールと心構えをしっかりと確立することが重要です。人ではなく事柄に焦点を当て、誰が優れているかを証明するのではなく、製品をより良くすることを目標としましょう。皆がプロジェクトのために良いことをしようという気持ちで、正しい心構えを持てば、このことはうまくいくでしょう。