# レビュー

## ガイド

<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を発行していないか
* テストケースは十分か
* 境界条件で正常に動作するか
* エラーハンドリングは必要な箇所で行なわれているか