Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AI時代のコードレビューでの品質保証
Search
nakampany
October 28, 2025
0
790
AI時代のコードレビューでの品質保証
nakampany
October 28, 2025
Tweet
Share
More Decks by nakampany
See All by nakampany
自分発信のミーティングがノープランすぎて失敗しかけた話
nakampany
1
380
若手エンジニアのコードレビュー 〜斜め上のPRを見て学ぼう!〜
nakampany
1
81
アドベントカレンダーで投稿するのはタイパが悪いのか?
nakampany
1
79
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
Bash Introduction
62gerente
615
210k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
22k
A Modern Web Designer's Workflow
chriscoyier
697
190k
Why Our Code Smells
bkeepers
PRO
340
57k
Facilitating Awesome Meetings
lara
57
6.6k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.3k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.2k
Code Review Best Practice
trishagee
72
19k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
3.7k
Transcript
AI時代のコードレビューでの 品質保証 2024/10/24 #めぐろLT 株式会社HRBrain なかじ
2 今回話すこと • 自己紹介 • AI時代のコードレビュー • チームの課題感 • テストコード拡充の推進
• 学び • まとめ
自己紹介
4 自己紹介 • なかじ • HRBrain バックエンドエンジニア • 学習管理プロダクトの開発をしています! •
#ゴルフ #麻雀🀄 #海外旅行✈ @nakampany
今回話すこと
6 今回話すこと • 自己紹介 • AI時代のコードレビュー • チームの課題感 • テストコード拡充の推進
• 学び • まとめ
7 今回話すこと ※レビューの話というよりは、 レビューする前段階でテストコードを書こ う!という話です
なんで、テストコード?
9 なんで、テストコード? • AIがコーディングしてくれる • なので、レビューの意味が変わりつつある ◦ 以前:人のミスを見つけるためのもの ◦ 今後:AIが生成したコードを「意図」と「品質」で評価するもの
• 人が力を入れるべきは、「設計」「品質保証」だと思う
10 なんで、テストコード? つまり、レビューで「品質保証」の部分を担保するために、 今までよりテストコードを積極的に書くべき
チームでやっていること
12 チームでやっていること • テスト勉強会の実施 • レイヤーごとのテスト方針を定義 • テスト拡充 • テスティングガイドラインを策定
• 自動テスト 上記を行い、コードレビューの負担を減らしている
13 チームでやっていること • テスト勉強会の実施 • レイヤーごとのテスト方針を定義 • テスト拡充 • テスティングガイドラインを策定
• 自動テスト 今回こちらを紹介 上記を行い、コードレビューの負担を減らしている
14 テスト勉強会の実施 • テスト勉強会で、本を読みました • 「こういう書き方した方がいいよね」 • 「アプリケーションコードでこういうコード書いてあるから改善したいよね」 こういう会話をしています(1例です) •
良い単体テストは、4つの柱がある →事前データが共通しており、「保守のしやすさ」に問題があり! →じゃあ、改善したいよね! →チケットを切ろう!
15 レイヤーごとのテスト方針を定義 • 弊社では、意思決定時に組織共通でADRを書く文化がある 自分のチームはこういう方針で、テストを書きます!など • クリーンアーキテクチャを採用しているので、 各レイヤー(domain, repo, usecase,
handler)で どんなことを担保するのかを改めて明記したものを作りました
16 テスト拡充 • 既存コードで、振る舞いが変わったとき、検知できないといけない →既存コードもテストを拡充していかないとけない • テスト拡充については、機能開発と同時並行なので、まとまった時間を確保で きないので、、、 • チームで週一回必ず、1時間ほどテストのみを書く時間を設けている
意外と、感触が良い取り組みで、 テストのみに集中できるので良い!
まとめ
• レビューで「品質保証」の部分を担保するために、今後もテストコードを 積極的に書くべき • そこでやったこと テスト勉強会の実施 レイヤーごとのテスト方針を定義 テスト拡充 テスティングガイドラインを策定 自動テスト
• 引き続き、レビューの負担を下げるために、テストコードを頑張って行きます! 18 まとめ
ご清聴ありがとうございました!