👀
Altiveでのコードレビュー推奨事項
Altive株式会社で推奨するコードレビューの心得です。
最新の推奨事項・非推奨事項をチーム内で共有できることで誤解や瑣末な判断が減り、コードレビューがスムーズになることを期待しています。
推奨事項
- コードレビューするときは自分自身ができているかどうかは棚に上げて、指摘すること
- いいコードがあったら積極的に褒めること
禁止事項
- 攻撃的な態度
- 人格攻撃されたと一方的に勘違いすること
心得
Draft（WIP）PRの扱い
- （推奨）実装・進捗の共有のため、作業中であっても積極的にコミット・プッシュし、Draft PRを作成する
- （任意）レビュワーは、手戻りが大きそうな設計に近いところ等をレビューする
- タイポなど細かいところは、後でまとめて修正するところかもしれないので指摘しなくても良い
依頼フロー
- レビュワーが設定されたプルリクエストをOpenした時点で、暗黙的レビュー依頼済みとする
- （推奨）しかし、GitHubの通知のみでは気づかれない恐れがあることや作業進捗共有の利点もあることから、 Slackのプロジェクトチャンネルでチームにメンションを付けたレビュー依頼を行うこととする
例： 「@xxx-team 〇〇を修正したPRを作成しました！レビューお願いします」 - （推奨）レビュワーに指定されたメンバーは必ずPRに目を通すこと。
再レビュー依頼フロー
- 複数人のレビュワーのうち、1人だけ Request changes があった場合
- （必須）修正後は、Request changesを選択したレビュワーが確認する。
- （推奨）他のレビュワーは修正コミットの確認は行うがコメントは任意とする。
- （必須）再レビューを依頼する場合はレビューア横の更新ボタン
Re-request reviewを押して依頼する
レビュー選択肢の意味と選び方
- Comment：まだマージ可能かを判断できないが、何かコメントしたい時に使用する。
- Approve：マージしても良い（軽微な修正のお願いなど含む）という意思表明に使用する。
- Request changes：マージする前に修正してほしい箇所があるという意思表明に使用する。
マージ済みのPRも修正箇所を知るために目を通す
- （推奨）リアクション（emoji）を残す。
- （推奨）修正した方が良い箇所や疑問点があればコメントする。
レビューの優先度と期限
- （推奨）1日の稼働開始時に、自分の実装より先にPRのレビューを優先的に行うこと。
- （任意）自分の作業中に届いた新規PRのレビュー依頼については、その場ですぐレビューするか、前項の通り翌稼働開始時に優先的にレビューする。
マージについて
- 誰がマージする？
- （推奨）原則、PRを作成した人がマージを行う。
- マージに必要な条件
- チームメンバーが2人以下：条件なし。任意のタイミングで責任を持ってマージする
- チームメンバーが3人以上：最低1人がApproveしていること。
必ずApproveされることを期待するPRについて
- CIを使って自動で作成されるように改善する
- 改善されるまでの対処方法としては、依頼されたレビュワーは積極的にApproveを押すこと。
参考文献
以下、参考にさせていただいた記事です。
Discussion