コードレビューの目的
- 品質の担保
- 知識の共有
https://プログラマが知るべき97のこと.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC/
コードレビューの目的は、ただコードの誤りを修正するだけではありません。重要なのは、チーム全員に同じ知識を共有させること、またコーディングにおいて全員が守るべきガイドラインを確立することです。
コードレビューで見たい所
- コードフォーマット
- 余計なスペース、インデント
- 変数名
- メソッド名
- ネストの深さ
- メソッドの長さ
- 仕様を満たしているか
- 考慮漏れはないか
- エンバグはないか
- セキュリティバグは無いか
- SQLインジェクション
- パフォーマンスは大丈夫か
- 不要なループ
- N+1
- 良い設計か
- 分かり易いか
- メソッドの選択
=> 人が全て見ようとすると多すぎて、大変。
漏れが起きやすく
これだと本来の目的が成せない
人が見るところを最小限にしに行く
分類してみる
ツールで担保
- コードフォーマット
- 余計なスペース、インデント
- 変数名
- メソッド名
- ネストの深さ
- メソッドの長さ
- パフォーマンスは大丈夫か
テストで担保
- エンバグはないか
まず、これで消耗は大分減る
人がレビューしたい所
- セキュリティバグは無いか フレームワークのお作法に乗っていれば基本大丈夫な箇所が多いが全部では無いので
- 分かり易いか
- メソッドの選択
- 良い設計か
- 仕様を満たしているか
- 考慮漏れはないか
人がレビューしたい所をさらに減らしに行きたい
技術力でレビューを最小にできる所
- セキュリティバグは無いか フレームワークのお作法に乗っていれば基本大丈夫な箇所が多いが全部では無いので
- 分かり易いか
- メソッドの選択
結局レビューに時間を割きたい箇所
- 良い設計か
- 仕様を満たしているか
- 考慮漏れはないか
これは結局 知識の共有 に時間を割きたいという事になりそう。
レビュイーとしての工夫
- 仕様を伝える
- やりたい事を伝える
- 設計方式を伝える
- なぜこれを採用したのか
- なぜあれは採用しなかったのか