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
ARA Ansible for the teams
kksat
0
170
15分で学ぶDuckDBの可愛い使い方 DuckDBの最近の更新
notrogue
1
350
プログラミング言語学習のススメ / why-do-i-learn-programming-language
yashi8484
0
150
PHPのバージョンアップ時にも役立ったAST
matsuo_atsushi
0
210
2025.2.14_Developers Summit 2025_登壇資料
0101unite
0
140
Flutter × Firebase Genkit で加速する生成 AI アプリ開発
coborinai
0
170
バッチを作らなきゃとなったときに考えること
irof
2
480
『GO』アプリ データ基盤のログ収集システムコスト削減
mot_techtalk
0
140
Formの複雑さに立ち向かう
bmthd
1
900
密集、ドキュメントのコロケーション with AWS Lambda
satoshi256kbyte
1
210
sappoRo.R #12 初心者セッション
kosugitti
0
270
データベースのオペレーターであるCloudNativePGがStatefulSetを使わない理由に迫る
nnaka2992
0
230
Featured
See All Featured
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Scaling GitHub
holman
459
140k
How STYLIGHT went responsive
nonsquared
98
5.4k
Designing on Purpose - Digital PM Summit 2013
jponch
117
7.1k
Become a Pro
speakerdeck
PRO
26
5.2k
Statistics for Hackers
jakevdp
797
220k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
The World Runs on Bad Software
bkeepers
PRO
67
11k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
570
Speed Design
sergeychernyshev
27
800
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 の記事が、レビューで は自分のことを棚上げする大事さについて詳しく解説してくれている
ローカルまたは開発環境で動かしてみる プルリクだけ見ればレビューできそうな小さな変更でも、意外と問題を見逃して しまうことがある ローカルや開発環境で動かしてみて、「なんかレスポンスとして返る値が違いそ うだぞ」「うまく画面が描画されないぞ」などと気づくことがある
ご清聴 ありがとうございました