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