306 Views
May 29, 25
スライド概要
私の所属するチームでの「コードレビューの変遷」というテーマでお話しさせていただきます。
ああでもない、こうでもないと1週間おきの振り返りで取捨選択しながら、いい感じに回るチームを目指して取り組んできた内容をご紹介できればと考えております。
我々のコードレビューの変遷 ツクリンク株式会社 めばしい #つくてくトーク
自己紹介 めばしい(Meba Shi) Rails歴2年目 つくてくトークの主催者 Kaigi on Railsのオーガナイザー 最近困ったこと o 暴食気味 o つくてくトークとKoRの資料作成期間が被っ た
つくてくトークってなに? ツクリンク株式会社が開催する勉強会・LT会の呼称 正式名称はTsukulink Tech Talk 情報発信、エンジニア同士の交流、技術の情報交換等の活動を 通して、ツクリンクを知っていただきたい、皆さんのことも知 りたいという思いの元活動中 不定期開催ではありますが、現状月1開催目指してますので、是非 遊びにいらしてください!
コードレビューしていますか? 必須とも言える「コードレビュー」 プルリクエストを出す前に改善してほしい、コメントでのコミュニケーションがストレス等、 コードレビューへの不満や悩みを抱えている方もいらっしゃるのではないでしょうか? 弊社で直面した事例を踏まえながらどう解決してきたか、コードレビューに向き合ってみようと 思います
事例1:長いラリー 1コメントに対しての長い長いラリー Aがコメント PR作成者がコメント Bがコメント Aがコメント Bがコメント PR作成者がコメント BがAにコメント Aがコメント 何ラリーしているかも定かでない。。
こうなった! 1往復以上ラリーする場合、すぐハドルに集まって相談する
事例2:やりすぎ注意報 想定していた実装範囲はUIのみだったが、登録処理まで実装してしまった 実装範囲が大きいので、消してという指示を出した 原因 o チケット作成を1人が担当 o それに対する理解をそろえるMTGを実施しなかった o やらないことに登録処理の部分を記載していなかった為、認識齟齬を起こしてしまった
こうなった! チケット作った後認識齟齬を起こさないように共有する o 朝会で説明する/チームチャンネルで共有する o 「何か追加したチケットありますか?」のような問いかけ チームみんなでチケット分割を行う
事例3:やりすぎ注意報(別パターン) 実装時想定外の途中変更にどこまで対応するか
こうなった! 30分〜1時間くらい待っても決まらなそうだったら別のチケットに分ける!
事例4:テキストコミュニケーションによるタイムラグ! 12日に最初のレビュー 16日に次のレビュー 17日にApprove 問題点 レビューとレビューの返信のタ イムラグ
こうなった! プルリクエストのコードレビューの優先順位を改めてチーム内で認識合わせ 優先順位 o アラート > レビュー修正 > レビュー > 実装 レビュー修正終わった後のレビューの意識を上げていく 金曜日のレビュー依頼を17時以降は、PRをOpenしない。(Draft状態だったらOK)
まとめ
まとめ チームみんなでチケット分割を行う チケット作った後認識齟齬を起こさないように共有する 朝会で説明する 「何か追加したチケットありますか?」のような問いかけ プルリクエストのコードレビューの優先順位をチーム内で認識合わせ o アラート > レビュー修正 > レビュー > 実装 レビュー修正終わった後のレビューの意識を上げていく 1往復以上ラリーする場合、すぐハドルに集まって相談する 30分〜1時間くらい待っても決まらなそうだったら別のチケットに分ける!
最後に
現状 AIの活用 CursorでPRレビュー DevinでPRレビュー PR上のレビューチェックリスト 実装者以外のコードレビュー 晴れてmerge
現状 CursorでPRレビュー DevinでPRレビュー PR上のレビューチェックリス ト 実装者以外のコードレビュー 晴れてmerge
現状 CursorでPRレビュー DevinでPRレビュー PR上のレビューチェックリス ト 実装者以外のコードレビュー 晴れてmerge
現状 CursorでPRレビュー DevinでPRレビュー PR上のレビューチェックリス ト 実装者以外のコードレビュー 晴れてmerge
現状 CursorでPRレビュー DevinでPRレビュー PR上のレビューチェックリス ト 実装者以外のコードレビュー 晴れてmerge
現状 CursorでPRレビュー DevinでPRレビュー PR上のレビューチェックリス ト 実装者以外のコードレビュー 晴れてmerge
本当の最後
伝わるコードレビュー AIを導入しても1人以上のレビュワーは存在する 対人とのテキストコミュニケーションなので、まだま だコードレビューは改善できる o コメントの記載の仕方を勉強中 o 「誤解なく、明瞭に、ストレスなく交わされるコードと チームを向上させるためのコミュニケーション」(伝わ るコードレビューより)