14-コードレビュー

「プログラマが知るべき97のこと」の14個目のエピソードは、コードレビューに関する話です。コードレビューの目的は「コードの品質を上げ、欠陥を減らすため」と考えがちですが、それと同じ程度に「チーム全員に同じ知識を共有させること、またコーディングにおいて全員が守るべきガイドラインを確立すること」が大切であると書かれています。
残念な事に、誰もがコードレビューが重要なことを理解している一方で、適切な形で開発プロセスにコードレビューが組み込まれているケースは希です。全コードをレビューしたとしても、バグが発生した時の言い訳にはなりますが、非常に時間を使うことになり通常は費用対効果は低くなります*1。また、レビューを組み込まなければ、各プログラマが好き勝手に実装することになります。それはそれで１つのスタイルかもしれませんが、コーディングスタイルを揃えて可読性を高める事はできませんし、経験の浅いプログラマのスキルを伸ばすこともできません。熟練したプログラマだけで組織されたチームでなければ採用はしない方が良いでしょう。コードレビューのやり方についても、被レビュー者のスキル次第なので、明確なガイドラインが作れないというのも課題です。
それでは、どのようにして効果的なコードレビューをしたら良いでしょうか？そのヒントはこのエピソードにあります。それは、コードレビューを楽しいものとし、主目的をスキルや業務知識の共有とすることです。コードレビューを軍法会議や魔女裁判にしてはいけません。プログラマであれば自分の書いたコードに少なからず誇りを持っています。そんなコードの非難ばかりをされるようなコードレビューには参加したくはありません。指摘されたならば素直に認める事も重要ですが、それ以上に「ここは理解が難しい所だから全員で共有しておこう」とか「この部分は他の人にも理解しやすいようにこう書き換えてはどうだろう？」と言った具合に前向きな議論が必要です。
また、これらのコードレビューの問題点を解決する方法の１つはペアプログラミングだと思います。不思議なもので、書き終えたコードの指摘をされ修正することは気分がよくないのですが、書き終える前に指摘されより良いコードとしていくならばむしろ気分が良いものです。相互チェックする事でつまらないミスも減り、少なくとも２人の間でスキルと業務知識が共有されるのです。ペアプロを導入していけば、コードレビューに関しても頻度を下げることができます。
コードレビューの目的は知識の共有です。知識の共有をすることでチーム全体のスキルが高まり、それが品質の向上に繋がります。回り道かもしれませんが、目先のプロジェクトだけを見るのではなくチームの成長を意識したプロジェクト運用を意識したいですね。

プログラマが知るべき97のこと

*1:人命に関わるようなプロジェクトである場合は例外