DMM.com 購入改善推進チーム におけるCodeRabbitを用いた レビューフロー改善の一例

CodeRabbit User Group Osaka #3 での登壇資料です。
https://crug.connpass.com/event/398184/

Transcript

1. DMM.com 購入改善推進チーム におけるCodeRabbitを用いた レビューフロー改善の一例 Kanon ysknsid25 ysknsid25 合同会社DMM.com プラットフォーム開発本部 第二開発部 購入グループ 購入改善推進チーム
2. まえがき
3. # DMM.com について
4. # 購入改善推進チーム について DMMの決済の入り口となる購入処理全体に対しての改善を推進するチーム 購入処理全体 レジ ポイントチャージ 直近ではこのレジ/ポイントチャージサービスのフロント/BFF部分をPHP製→Next.jsへのリプレースを推 し進めています。help me!!
6. # Why CodeRabbit? 購入改善推進チームでは当初、CodeRabbit + α社製レビューツールのダブル運用体制でした。 背景 DMM.com 全体で様々なAIツールの利用について検証されており、その一環でCodeRabbitを含む 様々なレビューツールを試していた 前職でもCodeRabbitを使っており、ある程度使い勝手を把握していた 異なるツールを使うことで、異なる観点のレビュー指摘を得られるかも 良いところ、悪いところを比較して、最終的にこのチームに合う一つに絞ろうとお試し運用をしてい た そんな折、α社製レビューツールが値上げしたことで、CodeRabbit 一本で運用することに。
7. # 今日のトピックス CodeRabbit でレビューフローを整備していくにあたって、 その過程での困りポイント その困りポイントをどう改善し、どう変わったのか？ が今日お話しすることです。
8. 困りポイント1
9. # 無邪気に使うと大量の指摘に忙殺される CodeRabbitは導入してすぐにレビュワーとして機能する素晴らしいツールなのですが、きちんとしたコ ンテキストなしでレビュー依頼すると以下のような問題が起こります。 レビューの内容が薄い 芯を喰った指摘でなく、文脈を無視した指摘をしてくる 以上の性質の指摘コメントを大量に入れてくる 結果、芯を喰った指摘とそうでない指摘が 体感 0.5:9.5 の比で混在。
10. # するとどうなるか… 一応全ての指摘を確認して、0.5の芯を喰った指摘が混じってないか？を探すことになる。 この比を逆転させたい!!
11. 改善1
12. # .coderabbit.yaml を育てる .coderabbit.yaml = CodeRabbitをチューニングするための設定ファイル 育てる = レビュー観点をできるだけ具体的にする 詳しい設定内容:https://docs.coderabbit.ai/getting-started/yaml-configuration
13. ## VSCode利用者のためのTips https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml
14. ## VSCode利用者のためのTips これを入れておくと存在しない設定を入れようとしたら怒ってくれるので便利
15. ## 1. reviews > path_instructions の設定 特定のパス、あるいはファイルごとにレビューの観点を提供するための設定。 これを細かく設定してあ げる。例えばフロントエンドなら、 全体( **/* ) コンポーネント全般( *.tsx ) 業務ロジック全般( *.ts ) API( **/route.ts ) テスト( **/*.{test,spec}.{ts,tsx} ) のように分類し、それぞれ違った観点を記述してあげる。
16. ## 1. reviews > path_instructions の設定 また以下のプロンプトをコード全体( **/* )への観点として入れることで、先述の芯を喰った指摘とそう でない指摘の比が明らかに変わり始めました。 広く浅くではなく、重大な問題に対して深く掘り下げてコメントしてください。コード全体を通 じて最も重要な問題に焦点を当てましょう。つまり必然的に指摘箇所は少なくなります。 ただし、同じ処理を繰り返し書いている。マジックナンバー。未使用変数が残っている。変数名 の改善提案。Typo。PRの概要と照らし合わせて、関係のない変更が入っている。このようなプロ グラミングにおける基本的なお作法が守られていない場合は上記とは別に指摘を行なってくださ い。
17. # 2. reviews > path_filters の設定 1の経験から、 「広く浅く」がアンチパターンなことがわかったので、とにかくCodeRabbitに読ませるフ ァイルが必要最低限になるように設定する。 node_modules knip.json などdevでしか使わないツールの設定ファイル こういうのは除外していく。
18. # 3. knowledge_base > code_guidelines > filePatterns の設定 コーディング規約をCodeRabbitに教える設定。ファイルパスを指定する。 設定内容の一例 Google TypeScript Style Guideをベースにしたコーディング規約を教える CLAUDE.md を指定することでAIに守らせたいルールをそのまま伝えられる skills ディレクトリのうちレビューに役立つSkillを伝えられる 例えば vercel-labs/agent-skills/introducing-react-best-practices
19. 困りポイント2
20. # CODEOWNERSを設定しているとCodeRabbitと 同時にレビュワーがアサインされてしまう CODEOWNERS （人間） CodeRabbit 開発者 CODEOWNERS （人間） CodeRabbit 開発者 par [ 同時レビュー] 重複した指摘も両方確認しなければいけない 本来CodeRabbit が拾うべきTypo も 最初から人間が確認しないといけない PR を作成 PR を作成（同時アサイン） 指摘コメント 指摘コメント Approve 場合によってはCodeRabbit の方が後に指摘コメントを入れることも 再Approve を依頼
21. 改善2
22. # 独自ワークフローを作成する CODEOWNERSと同じ記法でREVIEWERSというファイルを用意する フォルダ・ファイルに対する責任者を明記しつつGitHubの自動アサインを回避 PRを作成するとCodeRabbitが自動アサイン レビュー完了後、指摘があれば修正し、CodeRabbitのコメントをResolveする レビュイーが"ReviewReady"というLabelを貼る レビュワーアサインのためのActionが起動する CodeRabbitからのコメントがResolveされている or そもそも指摘がない を判定 REVIEWERに記載の内容をもとに特定ルールに基づいてレビュワーをアサインする 回数が一定になるように…といったアサインの仕方も可能 以降は従来の人間に対するレビューフローと同じ
23. # 改善後レビューフロー REVIEWERS （人間） GitHub Action CodeRabbit 開発者 REVIEWERS （人間） GitHub Action CodeRabbit 開発者 PR を作成（CodeRabbit 自動アサイン） 指摘コメント 指摘を修正 & コメントをResolve "ReviewReady" Label を貼る Resolve されているか判定 レビュワーをアサイン 本質的なレビュー 指摘があれば修正 Approve 必要数Approve されてれば"ReviewReady" Label を剥がす
24. # 外部向けの Action を Marketplace で公開中 https://github.com/ysknsid25/assign-reviewers-after-resolve 自チームで使っているものとは別に、Publicに別途公開。他チーム・組織でも利用可能 これはCodeRabbitに限らず、そのほかのレビューツールであっても利用することが可能 ファイル名やラベルは REVIEWERS , ReviewReady に限らず任意のものに設定することが可能
25. おわりに
26. # まとめ やったことと効果 .coderabbit.yaml を育て、レビュー観点を具体的にすると芯を喰った指摘が増えていく AI to Human となるようにレビューフローを整備することで人間のレビュー負荷を下げる その結果得られたもの CodeRabbitによって極力単純な指摘がし尽くされた状態 そのPRで解決したい問題に対する本質的な部分へのレビューに集中できる環境 それではよき CodeRabbit レビューライフを 👋