コミュニケーションとしてのコードレビュー

コードレビューが自発的に活発に行われる文化を創ろうと思っています。
チームが最近少しずつそのような雰囲気になってきましたので、
そうなるまでに感じたことについて思ったことを少し。

そもそもコードレビューすることについては、大概の人は、実施したほうがよいと思うでしょう。

・セキュリティホールやバグの発見とその共有できる
・仕様やコードが共有され、属人化を防止できる
・良いコードはお手本となり、チームのスキル・レベルアップにつながる

「良い効果」があるのであれば、やらない理由はないハズですが、実施できなかったり、実施しても続かないケースがあります。
その理由として、たとえば以下のような課題があるのではないでしょうか。

・人数分の印刷物を用意するなど、レビューの準備が大変
・他の開発者の時間を多く拘束してしまい、プロジェクト全体の開発効率が落ちる
・「コードレビュー」のイメージが「検査」「減点」されるイメージ

前述の「良い効果」は、緊急対応を減らし、皆で助けあいながらスキルアップができ、
エンジニアの健全な労働環境作りに効果のあるものだと思いますので、
これらの課題をうまくクリアして、コードレビューの文化を醸成したいと考えました。

課題１：人数分の印刷物を用意するなど、レビューの準備が大変

我々のチームでは Redmine を利用していましたので、
リポジトリをRedmineと連携させ、CodeReview Plugin を導入しました。
CodeReview Plugin 自体は使いやすいとまではいきませんが、
なんとか使えるレベルではありましたので、利用しています。
# 機会があれば Gerrit を使ってみたいと思っています。

課題２：他の開発者の時間を多く拘束してしまい、プロジェクト全体の開発効率が落ちる

コードレビューを依頼するときは開発担当者が Redmineでコードレビューチケットを発行し、
そのURLをメーリングリストに投げるようにしています。
我々のチームは10人ほどいますので、その中の数人が開発の合間などにレビュー出来れば良い。
また、コードの一部でも良いので【だれでも気軽にレビューして良い】ことにしています。

課題３：「コードレビュー」のイメージが「検査」「減点」されるイメージ

自分の書いたコードが他人に採点され、様々な指摘を受けることになります。
よほど人間ができていて謙虚な人でなければ憂鬱になるのではないでしょうか。
そのような状況に自ら進んでいこうとする人は相当の変わり者ではないでしょうか。

・コードレビューで、良いコードがあればそのことを遠慮無く書いて良いのです。
・コードレビューで、知らない書き方があったら質問して良いのです。逆に学びましょう。
・コードレビューで、バグがあったらそのうち修正すれば良いのです。
・コードレビューで、クリティカルな指摘は真摯に受け止めて修正すれば良いのです。

コードレビューはエンジニア同士のコミュニケーションの１つであり、
お互いにレベルアップする１つの手段であれば良いと思います。
指摘するだけでなく、褒め合ったり質問したり、同意したり…
そして、CodeReview Plugin に Facebook の Like ボタンのような機能が欲しいと思う、今日この頃です。