https://google.github.io/eng-practices/
https://developers-jp.googleblog.com/2019/12/respectful-reviews.html
- もやっと指摘するべからず（もう少しわかりやすくなど）。改善案と具体例を示してすべし。
- フィールドの更新を忘れずべからず。
- フォントの統一を忘れるべからず。
こっちは自動でやる
• コードフォーマット
• 眼鏡を外してレビュー
• 記述が分かりやすいか
• セキュリティ担保
• パフォーマンス担保
リリースしたら価値が届く、本来レビューすべきだったもの
• コードが仕様を満たしているか
• 仕様に考慮漏れが無いか
• エンバグは無いか
• 良い設計をしているか
- I/F誤りによる混乱
- 低性能による性能改善工数増加
- 機能バグによる手戻り
- 低保守性による工数増加
- 低拡張性による機能制限
- セキュリティ考慮不足による被害
- DB定義変更による混乱
- 要件実装漏れによる追加開発
- データ破壊による業務へのインパクト
- コミュニケーションロスの発生
- 見た目の（体裁）の読みやすさ
- 入出力関係の正しさ
- データ操作の正しさ
- 認識・理解誤りの発生の少なさ
- 要件の網羅度
- 実装・保守の容易さ
- 論理的な正しさ
- プロジェクトルールの遵守度
- 機能使用の安全性
- 動作時の性能
- レビューの観点を明確にすること
- 我が身に返ることを恐れずに指摘すること
- 何故悪いコードなのかを論理的に説明すること
- 良いコードについて共通認識を持つこと
- 小さい単位でレビューを繰り返すこと
- 指摘は素直な気持ちで受け入れること
- 指摘は人格否定でないことを理解すること
- ブランチのテーマとは関係のないコードが含まれていないか
- コミットメッセージは簡潔かつ分かりやすいか
- 責務に応じてリファクタリングされているか
- メソッドを不必要にpublicにしていないか
- コードは読みやすいか/分かりやすいか
- クラス/メソッド/変数の名前は適切か
- 既存コードとの重複はないか
- 既存コードに影響を及ぼさないか
- コメントが必要な箇所はないか
- デバッグ用のコードは残っていないか
- もっとよいコードにできないか
- ファイル名は適切か
- 不要なファイルをコミットしていないか
- typoはないか
- コーディング規約に則っているか
- バリデーションは適切か
- セキュリティ上のリスクはないか
- フレームワークのレールから外れていないか
- ライブラリで代替できる処理はないか
- 将来的な負債は予期されないか
- トランザクションが必要な箇所はないか
- キャッシュが必要な箇所はないか
- 不必要なSQLを発行していないか
- テストケースは十分か
- 境界条件で正常に動作するか
- エラーハンドリングは必要な箇所で行なわれているか