Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
コードレビューで大事にしたいこと
Search
hayashiyoshino
February 27, 2022
Programming
0
1.3k
コードレビューで大事にしたいこと
コードレビューで大事にしたいこと
hayashiyoshino
February 27, 2022
Tweet
Share
More Decks by hayashiyoshino
See All by hayashiyoshino
プロジェクトへ途中参加した際 早めにやっておくと良さそうな事
hayashiyoshino
6
1.4k
How to be a better Rubyist
hayashiyoshino
0
2.4k
Other Decks in Programming
See All in Programming
アーキテクチャと考える迷子にならない開発者テスト
irof
9
3.4k
モビリティSaaSにおけるデータ利活用の発展
nealle
1
670
Java_プロセスのメモリ監視の落とし穴_NMT_で見抜けない_glibc_キャッシュ問題_.pdf
ntt_dsol_java
0
230
チーム開発の “地ならし"
konifar
8
6.4k
CSC305 Lecture 17
javiergs
PRO
0
200
Duke on CRaC with Jakarta EE
ivargrimstad
0
300
OSS開発者の憂鬱
yusukebe
14
12k
生成AIを活用したリファクタリング実践 ~コードスメルをなくすためのアプローチ
raedion
0
160
データファイルをAWSのDWHサービスに格納する / 20251115jawsug-tochigi
kasacchiful
2
100
20251127_ぼっちのための懇親会対策会議
kokamoto01_metaps
2
230
FlutterKaigi 2025 システム裏側
yumnumm
0
1.2k
All(?) About Point Sets
hole
0
230
Featured
See All Featured
Leading Effective Engineering Teams in the AI Era
addyosmani
8
1.2k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.3k
A Tale of Four Properties
chriscoyier
162
23k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.3k
Building Adaptive Systems
keathley
44
2.8k
Making Projects Easy
brettharned
120
6.5k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Making the Leap to Tech Lead
cromwellryan
135
9.6k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.8k
Rails Girls Zürich Keynote
gr2m
95
14k
Typedesign – Prime Four
hannesfritz
42
2.9k
Docker and Python
trallard
46
3.7k
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 の記事が、レビューで は自分のことを棚上げする大事さについて詳しく解説してくれている
ローカルまたは開発環境で動かしてみる プルリクだけ見ればレビューできそうな小さな変更でも、意外と問題を見逃して しまうことがある ローカルや開発環境で動かしてみて、「なんかレスポンスとして返る値が違いそ うだぞ」「うまく画面が描画されないぞ」などと気づくことがある
ご清聴 ありがとうございました