レビュー

ガイド

https://google.github.io/eng-practices/

コメントするときの注意事項

https://developers-jp.googleblog.com/2019/12/respectful-reviews.html

べからず集

レビューア（レビューする人）べからず集

• もやっと指摘するべからず（もう少しわかりやすくなど）。改善案と具体例を示してすべし。

レビューイ（レビューされる人）べからず集

• フィールドの更新を忘れずべからず。

• フォントの統一を忘れるべからず。

コードレビュー

こっちは自動でやる

• コードフォーマット

• 眼鏡を外してレビュー

• 記述が分かりやすいか

• セキュリティ担保

• パフォーマンス担保

リリースしたら価値が届く、本来レビューすべきだったもの

• コードが仕様を満たしているか

• 仕様に考慮漏れが無いか

• エンバグは無いか

• 良い設計をしているか

詳細設計レビュー

管理者としての懸念事項

1. I/F誤りによる混乱

2. 低性能による性能改善工数増加

3. 機能バグによる手戻り

4. 低保守性による工数増加

5. 低拡張性による機能制限

6. セキュリティ考慮不足による被害

7. DB定義変更による混乱

8. 要件実装漏れによる追加開発

9. データ破壊による業務へのインパクト

10. コミュニケーションロスの発生

レビューする視点

1. 見た目の（体裁）の読みやすさ

2. 入出力関係の正しさ

3. データ操作の正しさ

4. 認識・理解誤りの発生の少なさ

5. 要件の網羅度

6. 実装・保守の容易さ

7. 論理的な正しさ

8. プロジェクトルールの遵守度

9. 機能使用の安全性

10. 動作時の性能

コードレビュー

秘訣

1. レビューの観点を明確にすること

2. 我が身に返ることを恐れずに指摘すること

3. 何故悪いコードなのかを論理的に説明すること

4. 良いコードについて共通認識を持つこと

5. 小さい単位でレビューを繰り返すこと

6. 指摘は素直な気持ちで受け入れること

7. 指摘は人格否定でないことを理解すること

チェックリスト

• ブランチのテーマとは関係のないコードが含まれていないか

• コミットメッセージは簡潔かつ分かりやすいか

• 責務に応じてリファクタリングされているか

• メソッドを不必要にpublicにしていないか

• コードは読みやすいか/分かりやすいか

• クラス/メソッド/変数の名前は適切か

• 既存コードとの重複はないか

• 既存コードに影響を及ぼさないか

• コメントが必要な箇所はないか

• デバッグ用のコードは残っていないか

• もっとよいコードにできないか

• ファイル名は適切か

• 不要なファイルをコミットしていないか

• typoはないか

• コーディング規約に則っているか

• バリデーションは適切か

• セキュリティ上のリスクはないか

• フレームワークのレールから外れていないか

• ライブラリで代替できる処理はないか

• 将来的な負債は予期されないか

• トランザクションが必要な箇所はないか

• キャッシュが必要な箇所はないか

• 不必要なSQLを発行していないか

• テストケースは十分か

• 境界条件で正常に動作するか

• エラーハンドリングは必要な箇所で行なわれているか