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.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
モダンJSフレームワークのビルドプロセス 〜なぜReactは503行、Svelteは12行なのか〜
fuuki12
0
120
オフライン対応!Flutterアプリに全文検索エンジンを実装する @FlutterKaigi2025
itsmedreamwalker
2
280
Vueで学ぶデータ構造入門 リンクリストとキューでリアクティビティを捉える / Vue Data Structures: Linked Lists and Queues for Reactivity
konkarin
1
350
『実践MLOps』から学ぶ DevOps for ML
nsakki55
2
470
レイトレZ世代に捧ぐ、今からレイトレを始めるための小径
ichi_raven
0
470
PHPライセンス変更の議論を通じて学ぶOSSライセンスの基礎
matsuo_atsushi
0
170
connect-python: convenient protobuf RPC for Python
anuraaga
0
270
仕様がそのままテストになる!Javaで始める振る舞い駆動開発
ohmori_yusuke
8
4.7k
All(?) About Point Sets
hole
0
210
Querying Design System デザインシステムの意思決定を支える構造検索
ikumatadokoro
1
1.2k
AIを駆使して新しい技術を効率的に理解する方法
nogu66
1
660
生成AIを活用したリファクタリング実践 ~コードスメルをなくすためのアプローチ
raedion
0
130
Featured
See All Featured
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
9.8k
Designing for Performance
lara
610
69k
For a Future-Friendly Web
brad_frost
180
10k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
54k
Leading Effective Engineering Teams in the AI Era
addyosmani
8
1.2k
Speed Design
sergeychernyshev
33
1.3k
Embracing the Ebb and Flow
colly
88
4.9k
Automating Front-end Workflow
addyosmani
1371
200k
Optimising Largest Contentful Paint
csswizardry
37
3.5k
Reflections from 52 weeks, 52 projects
jeffersonlam
355
21k
Bash Introduction
62gerente
615
210k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
37
2.6k
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 の記事が、レビューで は自分のことを棚上げする大事さについて詳しく解説してくれている
ローカルまたは開発環境で動かしてみる プルリクだけ見ればレビューできそうな小さな変更でも、意外と問題を見逃して しまうことがある ローカルや開発環境で動かしてみて、「なんかレスポンスとして返る値が違いそ うだぞ」「うまく画面が描画されないぞ」などと気づくことがある
ご清聴 ありがとうございました