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