DroidKaigi 2023 - [JA] 突撃！隣のコードレビュー | Sato Taichi, Okumura を視聴した
視聴元
レビューのメリット
- 不具合混入リスクの低減
- 可読性・保守性の品質向上
- メンバのスキル向上
その一方で
- 時間が...
- ギスギスする...
この登壇を通して、レビューに対してちょっとだけ前向きになってもらうことが目標。
DMM.com の開発体制や環境
- いくつかのアプリチームが例にあがったが、共通して以下のフロー。
- プルリク作成
- チェックリストに沿ってセルフチェック
- CIチェック
- レビュー
- Approveされるまで指摘⇔レビューを繰り返す。
- マージ
コードレビューの工夫
DMMで展開されている３つのアプリチーム（DMM TV, DMMポイントクラブ, DMMブックス）でのコードレビューの工夫が挙げられた。
- 1プルリクの修正量を200行〜500行
- レビューのリマインド通知（Slack）
- コードレビュータイム（レビューを集中して実施する時間）を以下の構成で
- AM：口頭
- PM：実際のレビュー
- 効果：コミュニケーションがとりやすくなった／質問しやすくなった
- 設計を重めにとる／設計レビューで実装の流れを共有
- レビューでの問題は設計プロセス／コミュニケーション不足が原因ととらえたため
- レビュー工数の軽量化（設計フェーズでの合意がとれているため）
レビュアーとしての工夫
認識合わせをしっかりと
- ちょっとした疑問でも確認
- 会話が3往復以上になりそうなら、対面レビューへ
記録・ナレッジとして活用させる
- 口頭で確認したこともコメントで記録する
- レビューコメントは今後役立てられるようにできる限り詳細に
スムーズなレビュー
- なるべくすぐ見る
- 自分のタスクよりコードレビューを優先する
心地よいコミュニケーション
- やわらかい口調にする
- 良いと思ったところもコメント
- 緩い感じの文体で
その他
- レビュアーは説明できるくらいに責任を持つ
- 自分ならどうするかを意識して、それを踏まえたコメント
レビューされる側の工夫
- 差分のサイズを小さくする
- サイズを小さくできなくても、コミットを分ける
- 見てほしい所をコメントでピックアップ
- 読みやすいプルリクにする
- 意味のあるまとまりでプルリク
- プルリクコメで具体的に補足
- レビューに必要案情報をそろえてプルリクに
- 以下にレビューしやすくするかにフォーカスしたもの
結論
- レビューは コミュニケーション と 思いやり が重要
最終更新: 2025.6.17