レビューのガイドライン

レビューには、品質の向上とノウハウの共有という２つの意義がある。正しい方法でレビューを挟むことによって、見落としや認識の齟齬がないかを確認でき、品質の向上が見込まれる上に、メンバーが作業中に得た知見やスキルの異なるメンバー同士のノウハウを共有できる。

レビューを依頼する際の留意点を以下にまとめる。

レビューを依頼する際には、レビューしてもらうために必要な情報を揃えておかなければならない。例えば、コードレビューであれば、ソースコードの差分や参照した仕様書・要件定義書・画面イメージなどのドキュメントが必要である。さらに、プロジェクトの経緯や状況、コーディングの完成度、何のための修正なのか、なぜそのように実装したかの情報があると、レビュー対象の理解が容易になり、より効果的なレビューが受けられる。

コーディングスタイルや表記方法についての議論や指摘は、品質の向上とノウハウの共有に集中する際にノイズになってしまう。コーディングスタイルや表記方法は事前に定めて、リンターなどのツールを使って整えておくことで、より効果的なレビューが受けられる。

レビューの際に、何をどう見てもらいたいのかや不安な箇所や重点的に見てほしいところを伝えておくことで、論点が明確になってより効果的なレビューが受けられる。コーディングやテストの時に難しかった箇所をチームメンバーに共有しておくと、もっと良い方法を提案してくれる可能性もある。

レビューで受けた指摘はすべて確認して修正し、修正後に再度確認してもらう。前提知識の共有ができていなかったための指摘については、追加で説明してしっかり認識をすり合わせておく。

レビューを実施する際の留意点を以下にまとめる。

コーディングスタイルや表記方法についての形式的なチェックは時間の無駄。レビューを実施する際は、レビュー依頼された観点に加えて、仕様通りにプログラムが実装されているか、仕様漏れがないか、設計や実装が効率的かという点に集中するべき。

レビューする際にすべての前提知識を把握できているわけではないので、レビュー対象のコードに疑問を持つことがある。前提が共有されていない可能性を考慮して、そのようなコードになった背景や経緯を質問し、適切なレビューができるように努める。

コードの中のコメントには、実装の背景や経緯を記載しておくと後から読む人の理解に役立つ。一方で、コードを読めばわかるようなことを冗長に説明するコメントや消すべきなのに残ったままになっているコメントは、むしろ読み手の理解を阻害する。コードに残すコメントは実装上注意が必要な難解な部分をカバーしておく程度で良い。

レビューにおける指摘内容について、いつ修正するかやそもそも修正するかどうかは、内容の重要性とスケジュールへの影響を考慮して判断する。可読性を考えると修正した方が良くても、小さなコードなら注意するように促すだけのこともあるし、コード修正作業を別タスクとしてチケットを発行しておいて、作業自体は後回しにすることもある。

レビューコメントにプレフィックスをつけて、指摘の重要度を伝えておくと、指摘を受けた人はそのプレフィックスを参考にして、対応する優先順位を検討できる。これにより、さほど重要でない指摘への修正に時間を費やすことを防げる。

レビューの際は、コードの稚拙さと仕様や設計上の問題意識を分けて考える。コードは稚拙でも仕様や設計上の問題意識が妥当でよく考えれられているなら、問題意識についてはしっかり評価して、コードの書き方についてはちゃんと指摘する。