技術・品質・チーム · 入門
遅らせるのではなく改善するコードレビュー
一行でいうと: 良いレビューは小さく、速く、正確性と保守性に集中する——自動ツールが強制すべきスタイルの好みではない。
サイズ
二百行のマージリクエストは本物のコメントを受け取る;二千行のものは「良さそうだ」を受け取る。分割する。分割できないなら、説明に推奨される読み取りパスを書く。
何にコメントするか
正確性、エッジケース、セキュリティ、機密な場所でのパフォーマンス、一年後に読む人のための明確さ。スタイル、スペース、インポートの順序——自動ツールのため、人のためではない。
コメントを質問または提案として定式化し、何がブロックで何が単なる意見かをマークする。「ブロック:これにより別のユーザーのリソースへのアクセスが許可される」は丁寧なヒントより明確だ。
応答時間
二日間待つレビューは人々を止め、長いブランチを生む。規範を設定する——例えば、半日以内に応答する——そしてすべてのチームのコミットメントと同様に扱う。
さらに深く
自動的に強制するのが難しい項目をレビューのチェックリストに追加する:テストが追加されたか、変更は後方互換性があるか、文書が更新されたか、失敗したとき何が起きるか。この四つの質問は忘れられるほとんどのことを捉える。