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
コードレビューで大事にしたいこと
Search
hayashiyoshino
February 27, 2022
Programming
0
950
コードレビューで大事にしたいこと
コードレビューで大事にしたいこと
hayashiyoshino
February 27, 2022
Tweet
Share
More Decks by hayashiyoshino
See All by hayashiyoshino
プロジェクトへ途中参加した際 早めにやっておくと良さそうな事
hayashiyoshino
6
1.2k
How to be a better Rubyist
hayashiyoshino
0
2.3k
Other Decks in Programming
See All in Programming
責務と認知負荷を整える! 抽象レベルを意識した関心の分離
yahiru
7
670
Rails アプリ地図考 Flush Cut
makicamel
1
120
お前もAI鬼にならないか?👹Bolt & Cursor & Supabase & Vercelで人間をやめるぞ、ジョジョー!👺
taishiyade
6
4k
データベースのオペレーターであるCloudNativePGがStatefulSetを使わない理由に迫る
nnaka2992
0
170
GAEログのコスト削減
mot_techtalk
0
120
GitHub Actions × RAGでコードレビューの検証の結果
sho_000
0
270
ペアーズでの、Langfuseを中心とした評価ドリブンなリリースサイクルのご紹介
fukubaka0825
2
330
『品質』という言葉が嫌いな理由
korimu
0
160
楽しく向き合う例外対応
okutsu
0
150
バックエンドのためのアプリ内課金入門 (サブスク編)
qnighy
8
1.8k
なぜイベント駆動が必要なのか - CQRS/ESで解く複雑系システムの課題 -
j5ik2o
12
4.1k
法律の脱レガシーに学ぶフロントエンド刷新
oguemon
5
740
Featured
See All Featured
Building Adaptive Systems
keathley
40
2.4k
Navigating Team Friction
lara
183
15k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Automating Front-end Workflow
addyosmani
1368
200k
Documentation Writing (for coders)
carmenintech
67
4.6k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
For a Future-Friendly Web
brad_frost
176
9.5k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
What's in a price? How to price your products and services
michaelherold
244
12k
Transcript
コードレビューで大事にしたいこと 2022/2/27 とにかくほめる!マウントなしのLT会 林 佳志乃
自己紹介 名前:林 佳志乃 所属:エーテンラボ株式会社 部署:サーバーサイド
None
テーマを選んだ背景 コードレビューで何を大事にすべきかなんとなく考えはあったものの、明確に なっていなく、そのせいでレビューにムラがあったり、優先度を間違えて後回 しにしてしまったりしていた これを機に明確にしておきたいと思った
コードレビューの目的 - コードの品質担保 - 実装者だけでなく他のメンバーも実装を理解する - 勉強
コードレビューで大事にしたいこと - issueやEPICに必ず目を通す - わからない箇所があれば質問する - 内容が難しい時はプルリク作成者に説明依頼する - 2開発日以内にレビューする -
レビューでは自分のことを棚上げする - ローカルまたは開発環境で動かしてみる
issueやEPICに必ず目を通す 仕様や機能の全体像が頭にないとコードを読むのに苦戦する 仕様を満たした実装になっているかをレビューするには、何のためにどんな機 能を作ろうとしているのか、どんな検討をしたのかを理解してからじゃないとで きない よっぽど小さな不具合修正などは別として、きちんとEPICやissueの内容を頭 に入れてからレビューを行いたい
わからない箇所があれば質問する よくわからない箇所がある場合は、自分の理解力の問題もあるが、コードに問 題がある可能性もある 自分の理解力がなかったケースでは質問することで勉強になる コードに問題があるケースではコードの品質担保になる
内容が難しい時はプルリク作成者に説明依頼する 内容が複雑だったり難しいときはレビューに時間がかかるし、億劫になって後 回しにしがち 効率よく理解して早くレビューをするために、内容が難しすぎる時は説明依頼を するようにしている 説明依頼は相手の時間を取ってしまい、申し訳ないな〜と感じたりするが、レ ビューまで時間がかかりすぎたり、ぼんやりした理解のままLGTM出すよりは 良いと考えている だいたい快く丁寧に教えてくれるし、一人で調べてレビューするより断然短時間 で理解が深まると感じている
2開発日以内にレビューする レビューする = 変更差分を一通り確認してコメント or LGTM する プルリクが滞留している時間が長いとリリースが遅れるし、rebaseが大変にな るし、健全じゃない 会社の開発メンバー間でのWorking
Agreementになっているが、私はあまりで きていない汗 これからはもっと2開発日以内のレビューを守っていきたい
レビューでは自分のことを棚上げする これも、会社の開発メンバー間でのWorking Agreementになっている 自分ができていないことを他の人に指摘するのは、申し訳ない気持ちになる が、コードの品質を保つためには自分ができていないことでも、気になったこと は指摘する必要がある チーム内で合意が取れていると少し気が楽 https://qiita.com/jnchito/items/0a0b46106681f41f2f0e の記事が、レビューで は自分のことを棚上げする大事さについて詳しく解説してくれている
ローカルまたは開発環境で動かしてみる プルリクだけ見ればレビューできそうな小さな変更でも、意外と問題を見逃して しまうことがある ローカルや開発環境で動かしてみて、「なんかレスポンスとして返る値が違いそ うだぞ」「うまく画面が描画されないぞ」などと気づくことがある
ご清聴 ありがとうございました