以前、コードレビューそのもののポイントについてはコードレビュー時のポイントでまとめましたが、レビュー自体の体制の注意点やそこでの気づきなど。
目的
基本ルールに則っているかどうかを見るといった初歩的な意味もありますが、人間の思考の漏れを検証するといった意味あいが強いため、多人数で行わないとそもそもの意味がない・・・と思います。
定型的なものはチェックリストを
これについてのなるべく頭を使わずに自動ではじける仕組みが大切。
- ドキュメントの体裁→チェックリストやなるべく標準のテンプレート、標準の修正機能で防げるようにしたい
- 規約的なものは例えば規約ツールで自動ではじくなど
このレベルで毎回指摘する、指摘事項が変わる。。。などがないようにしたい。
レビュアーの負担軽減
- 仕様が複雑だったり、粒度が大きいものは対面でまずざっくりとレビュイーが説明をし、改善点に関しては回覧レビュー(メッセージのやり取りだけ)を行う
- 当事者意識を持たせるために、レビュアーにノルマを付与するといいかも(一回のレビューの際に必ず何らかの指摘事項をもうけるなど・・)
- リマインダーなどで自分の分を告知する仕組みが必要かも(Slackへの告知など)
- 参加する際の前提知識やそもそもの仕様の共有が最も大切
- そもそもの人間関係を壊さないような文化づくり(根本的にある信頼関係の構築)が最も大切
- 神学論争的なものは最終決定権のある人間に決めてもらう(当人同士で争わないように)
レビューポイントについて
- 見るポイントを各人で担当制にする(仕様的な部分、コードの設計的な部分)
- できればファイルなどを細かく分割して、小分けにする
- 必ずなおす、直してほしい、できたら、のようにウェートをつける
(理想論でいえば全て直してほしいが、そのタスクがブロックになってしまい、後続タスクへの影響などをなくすため。できたら・・などは別タスクとして別途レビューをする) - 指摘事項で多いもののリストアップ→なるべく他のメンバーでもレビューをできるようにする、見れるようにするため
- 余裕があればレビューの指摘事項で上がっているものの類型化など
