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
1.1k
コードレビューで大事にしたいこと
コードレビューで大事にしたいこと
hayashiyoshino
February 27, 2022
Tweet
Share
More Decks by hayashiyoshino
See All by hayashiyoshino
プロジェクトへ途中参加した際 早めにやっておくと良さそうな事
hayashiyoshino
6
1.3k
How to be a better Rubyist
hayashiyoshino
0
2.3k
Other Decks in Programming
See All in Programming
AIプログラマーDevinは PHPerの夢を見るか?
shinyasaita
1
190
datadog dash 2025 LLM observability for reliability and stability
ivry_presentationmaterials
0
440
CursorはMCPを使った方が良いぞ
taigakono
1
220
技術同人誌をMCP Serverにしてみた
74th
1
560
関数型まつりレポート for JuliaTokai #22
antimon2
0
160
#QiitaBash MCPのセキュリティ
ryosukedtomita
0
830
High-Level Programming Languages in AI Era -Human Thought and Mind-
hayat01sh1da
PRO
0
710
GraphRAGの仕組みまるわかり
tosuri13
8
520
20250628_非エンジニアがバイブコーディングしてみた
ponponmikankan
0
630
ニーリーにおけるプロダクトエンジニア
nealle
0
730
A2A プロトコルを試してみる
azukiazusa1
2
1.3k
LINEヤフー データグループ紹介
lycorp_recruit_jp
0
1.8k
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
Stop Working from a Prison Cell
hatefulcrawdad
270
20k
The Invisible Side of Design
smashingmag
300
51k
Embracing the Ebb and Flow
colly
86
4.7k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
20
1.3k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.8k
Six Lessons from altMBA
skipperchong
28
3.9k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
We Have a Design System, Now What?
morganepeng
53
7.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 の記事が、レビューで は自分のことを棚上げする大事さについて詳しく解説してくれている
ローカルまたは開発環境で動かしてみる プルリクだけ見ればレビューできそうな小さな変更でも、意外と問題を見逃して しまうことがある ローカルや開発環境で動かしてみて、「なんかレスポンスとして返る値が違いそ うだぞ」「うまく画面が描画されないぞ」などと気づくことがある
ご清聴 ありがとうございました