コードレビューに関するRobert Bogue氏の記事について要約とコメント。
要約
効果的で痛くないコードレビュー
Effective Code Reviews Without the Pain - Developer.com
多くの組織においてコードレビューは参加者が苦痛に感じるもののようであるが、必ずしもそういうものではない。
目的を忘れないこと
コードレビューの目的は２つある。
- 書かれたコードが次行程に進むに耐える品質を持っていることを確認すること。
- 開発者がコードの品質、一貫性、メンテナンス性を改善するための方法を学ぶこと。
コードレビューはネガティブな印象を持たれがちだが、実は欠陥を最小限に押さえることができる方法なのだ。
アプローチの問題
コードレビューを個人をやり玉にあげる場ではなく共に学ぶ場にするために
- 意見を述べるのではなく、質問をせよ。
- 「ここは規約から外れているよね」ではなく、「こういう風にやっているのはどんな理由があったの？」と適切な口調で質問する。
- 「なんで？」という質問をしない。
- 時として難しいが、空気は良くなる。「なんで規約に従っていないの？」ではなく「どういう理由で規約から外れているの？」にする。
- 褒めることを忘れずに
- 人間は単に失敗を示されるだけではなくて、成功を認めてもらいたいものだ。
- 参照可能な優れたコーディング規約があることをはっきりさせる
- コードレビューは組織のコーディング規約に基礎を置くべきであり、コーディング規約とは開発者が品質とメンテナンス性の高いコードを書くためにお互いに合意したものだ。
- 議論はコードを対象としたものであって、コーダーを対象にしたものではないことをはっきりさせる
- そうすることで個人攻撃をさけることができる。
- 問題解決の方法は１つではないということを忘れない
- 開発者はレビュアーとは違うやり方をするかもしれないが、それが間違っているということではない。
開発者の立場だったら
開発者がコードレビューを受けるときの心構え
- コードと自分を切り離して考えることを忘れない
- コードに感情移入するのも分かるが、コードに対する指摘は人格攻撃ではない。
- コードレビューが焦点を当てるものについてのチェックリストを自分で作る
- コーディング規約の中で自分の弱点を絞り込んでおく。
- コーディング規約のメンテナンスを助ける
- コーディング規約にないものが議論にあがった場合には、規約に追加してもらう。
対面でない時には
文章で実施する方が対面よりも意外と簡単だが、若干のコツがある。
- 最初に要約するコメントをおくこと。それもポジティブなものを。
- これによって、読み手の受け取り方をポジティブな方向に向けることができる。
- コメントを記録するために電子媒体を使用する
- コピーと違って、自分の意図を伝えるために必要な分量をいくらでも書くことができる。
- 全ての質問に解答する必要がないことを事前に合意する
- 考えてもらうために問いを投げかけることもあるということを開発者に伝えておく。開発者が考えることは既にできあがったコードの品質には影響しないが、長い目で見ればコードの品質を改善する。
結論
Code reviews are often misused and painful for everyone, but they don't have to be. Some simple steps can convert torture into teaching and improve the long-term outlook for code quality in your organization.
コードレビューはしばしば誤って用いられ、みんなにとって痛みを伴うものとなる。しかしそうでなければいけないものではありません。単純なステップをいくつか踏むことで苦痛を教育に転換し、組織におけるコードの品質に関する長期的な見解を改善することができるのです。
コメント
極めてすばらしい示唆が実にコンパクトにまとめられている記事だと思いました。開発者がつい自分が責められているように感じてしまう空気を防ぎつつ、「あらかじめ定められた約束事が守られているかどうかを相互に確認し合う場」を作り上げていくというスタンスが大切だということですね。そういう「空気」をコントロールする方法が、過度に自己啓発っぽくなりすぎずに、いいバランスで紹介されているという印象を受けました。余談ですが、日本ではしばしば「なんで？」という質問は時に答えを求めておらず、単に責めているだけだったりするのですが、この辺りのニュアンスは英語でも同じなんですね。
ただ、契約ベースでコードレビューを実施し、品質を高めていくためには、その前提として「どのレベルの品質を規約として担保し、どこから先を開発者の技量に任せるか」という問題に対して、一定の折り合いをつけておかなければいけないということになるのですが、これはなかなか難しいように感じられます。
本筋とは外れますが、「前提」ということで言えば、こちらの方が重要かつ本質的かもしれません。
Because development is necessarily a creative work that developers pour their soul into, it often can be close to their hearts.
開発というものはどうしても創造的な仕事で、開発者はそこに魂を込めるのだから、時にとても大切に思うのもうなずけるものなのです。（本文より）
「コードに魂を込めてくれる技術者」をどう育て、あるいは集めるかということは、組織にとって最重要課題の一つだと思います。
