Software Engineering at Googleの8章を読んだ
の続編
9. Code Review
この章はコードレビューについて
・Googleのコードレビュー
レビューは一人が実施する
こうすることでスケールできるので、スピードアップが図れる
オプションで一人追加することもあるが、コメントはすべてオプションになる
レビュワーを追加するとコスパが急速に悪くなる
これはまじかーって感じがする
エンジニアが優秀だと一人でレビューできるんかな
・レビューのチェックポイント
簡単に保守できるか
技術負債を加えていないか
チーム内で保守するための専門性があるか
・良いコードレビュー
もし欠陥があれば代案を指摘する
もしどの方法も有効であればレビュイーの提案を受け入れる
間違ってるという前に質問するのは良い行為
・レビュー実施までの時間
コードレビューは24h以内に実施される
難しい場合は少なくとも変更だけは見るようにする
また、レビュワーは断続的にレビューするの避けるべきである
・レビューは小さい単位で
大抵のレビューは200行に制限されてる
小さければレビュワーも楽
・コミットログ
最初の一行はサマリーで重要
ヒストリーを見るときがあるので
・バグの混入を防ぐ
バグは早く見つけた方が修正しやすい
コードレビューはバグを混入させないことに効果がある
例えばユニットテストは後でやるね!とかを防げる
他人の目は重要
・コードレビューは
ベテランエンジニアでも不安に思う
・レポジトリの管理者
OWNERSファイルがあり
そこに管理者が書かれているとのこと
レビュー一人で実施はかなり衝撃的でした
また、24H以内のコードレビューの実施は是非やりたいところ
うちの会社じゃさすがに難しいかなぁ・・・・
まだまだ続くよ
関連記事:
- Software Engineering at Googleの7章を読んだ
- Software Engineering at Googleの4章を読んだ
- Software Engineering at Googleの3章を読んだ