技術・品質・チーム · 入門

遅らせるのではなく改善するコードレビュー

一行でいうと: 良いレビューは小さく、速く、正確性と保守性に集中する——自動ツールが強制すべきスタイルの好みではない。

サイズ

二百行のマージリクエストは本物のコメントを受け取る;二千行のものは「良さそうだ」を受け取る。分割する。分割できないなら、説明に推奨される読み取りパスを書く。

何にコメントするか

正確性、エッジケース、セキュリティ、機密な場所でのパフォーマンス、一年後に読む人のための明確さ。スタイル、スペース、インポートの順序——自動ツールのため、人のためではない。

コメントを質問または提案として定式化し、何がブロックで何が単なる意見かをマークする。「ブロック:これにより別のユーザーのリソースへのアクセスが許可される」は丁寧なヒントより明確だ。

応答時間

二日間待つレビューは人々を止め、長いブランチを生む。規範を設定する——例えば、半日以内に応答する——そしてすべてのチームのコミットメントと同様に扱う。

さらに深く

自動的に強制するのが難しい項目をレビューのチェックリストに追加する:テストが追加されたか、変更は後方互換性があるか、文書が更新されたか、失敗したとき何が起きるか。この四つの質問は忘れられるほとんどのことを捉える。