コードレビューで聞く質問集
コードレビュー中には、どこを見ればいいんだっけ、ってよくなりますので、 まとめておきました 英語でまとめたものを日本語に訳しました。
- この PR の目的は何なの？
- PR 作成者がこの PR に到るまでの調査結果・決定事項・仮説は妥当か？
- もっといい解決方法はないか？コード修正以外の解決方法も検討。
- この PR は根本的な解決？それとも暫定対応？暫定対応の場合は、PR 作成者に根本的な解決の計画を立ててもらう。
- この変更点はステークホルダーにどんな影響を与えるか？ステークホルダーはエンドユーザだけでなく、チームメンバーとかも含まれてる。
- その影響は最小限に抑えられないか？
- 影響を最小限に抑えるには、具体的にどんなステップを取るか？
- この PR の動作は正しいか？（言うまでもない）
- 足りてないエッジケースはないか？
- セキュリティの穴はないか？
- コードをもっと読みやすくできないか？
- コードをもっと簡潔に書けないか？
- 削除できる不要なコードはないか？
- PR 作成者にもしものことがあったら、レビュワーである あなた はこのコードを引き継ぐ責任は取れるか？
- マージ前後にやることはないか？特に CI やチームメンバーの開発環境に影響を与える修正。
- オンラインメンテでデプロイできそうか？
- デプロイ前後にやることはないか？PR 作成者にチェックリストを書いてもらう。
下記項目は基本確認しないようにしている。
- コード規約・フォーマット。Rubocop などのリンターに任せましょう。
- テスト。上記項目の確認がぜーんぶ終わったら、テストまで確認する気がほとんど失せてるから。
ポジティブなコメントも欠かさず
レビューに慣れてない人は最初 レビュー ＝ 間違い探し と思いがち、ネガティブな指摘しか書かない。問題点が見つからなかった PR も「何か書かなきゃ！」というプレッシャー感じて、些末な nits 書いちゃったりする。そういうときは
- どんな状態からどんな状態に変わったか？良い方向に変わった場合は褒める。読みやすくなったことだけでも。レビューしやすく工夫してくれたことでも。
- コード読んで理解したことを文章化する。理解に時間がかかったときは特に文章化する価値がある。認識の確認にもなる。
このレビュー術は、Aiming で培ってきたものです。
