Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
レビューのやり方を(ちょっと)整理した話
Search
ken7253
December 16, 2024
Programming
630
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
レビューのやり方を(ちょっと)整理した話
@[IVRyエンジニア忘年LT大会2024](
https://connpass.com/event/333537/
)
ken7253
December 16, 2024
More Decks by ken7253
See All by ken7253
Firefoxにコントリビューションして得られた学び
ken7253
2
190
バンドルサイズを半減させた話 @Browser and UI #3
ken7253
0
87
CSS polyfill とその未来
ken7253
0
300
Browser and UI #2 HTML/ARIA
ken7253
2
380
PEPCは何を変えようとしていたのか
ken7253
3
600
Browser and UI #1 CSS
ken7253
0
190
オーバーロード関数の話 @Mita.ts #2
ken7253
0
180
フロントエンドカンファレンス北海道参加レポート
ken7253
0
100
カスタムHooksと単体テストの共通点について
ken7253
0
520
Other Decks in Programming
See All in Programming
Webの地図
yosuke_furukawa
PRO
6
4.7k
Java 27新機能 / Java 27 new features
kishida
2
150
更なる可用性を求めて、5年間運用したKotlinのアプリケーションをGoでリプレイスする話
ken_tunc
0
330
WebAssembly in Android Apps 〜 WASMはJNIの夢を見るか
keiji
1
110
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
490
アクセシビリティから考える情報設計
high_g_engineer
0
380
GKE で Pod の見方を変えたら、スケールアウト時の挙動を真に捉えられた話
stkk
0
130
Go × SIMDで高速化するベクトル検索 ~ルーフラインモデルでSIMDが効く境界を探れ! ~
po3rin
1
2.4k
AGENTS.md Is Not Enough:Build Skills, Don't Download Them
lx_t
0
120
App Storeの外へ──日本のiOSサイドローディング入門 for iOSDC Japan 2026
yuukiw00w
0
230
スマートフォンでモールス信号を送受信する 〜スマートフォンのLEDとカメラで作る光通信の設計と実装〜
atsuki_seo
0
160
What We Talk About When We Talk About XP
m_seki
2
660
Featured
See All Featured
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
6.1k
The agentic SEO stack - context over prompts
schlessera
0
940
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
74
42k
Optimising Largest Contentful Paint
csswizardry
37
4k
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
870
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
1.1k
Game over? The fight for quality and originality in the time of robots
wayneb77
1
290
Building Applications with DynamoDB
mza
96
7.2k
How People are Using Generative and Agentic AI to Supercharge Their Products, Projects, Services and Value Streams Today
helenjbeal
1
330
Art, The Web, and Tiny UX
lynnandtonic
304
22k
Highjacked: Video Game Concept Design
rkendrick25
PRO
1
460
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
500
Transcript
レビューのやり方を(ちょっと)整理した話 @IVRyエンジニア忘年LT大会2024
ブラウザの標準化まわりを追うのが趣味 最近はReactを使ったアプリケーションを書いています。 ユーザーインターフェイスやブラウザが好き。 https://github.com/ken7253 https://zenn.dev/ken7253 https://bsky.app/profile/ken7253.bsky.social https://dairoku-studio.com ken7253 Frontend developer
みなさん!レビューしてますか?
レビューは大変
レビュープロセスを見直す機会があったのでその紹介
レビューコメントのラベル レビューコメントには必ずラベルを付けてもらう運用にしていた。 ラベル 意味 Must 必ず直してほしい箇所 IMO 任意だが自分ならこうする的な意見 NITS 直さなくても問題ないが修正したほうが良い箇所
Question 質問 導入当初は分かりやすくていい印象 チームでコミュニケーションをしていると改善点が見つかる
レビューコメントのラベル 導入からしばらく経っていたのでちょっと整理してみることに 問題点はなんとなく候補があったので、ドキュメントを書いてチームに共有してみた。
問題点 IMOとNITSの使い方が人によって異なる Questionが多用され着地点が分からないコメントがある
改善しよう
話し合うと、ラベルは変更してほしい度合いで使い分けていたことが分かった。 なのでざっくり下記のような対応を行うことに。 ラベルの使い分けを変更要望度を軸としたものに レイヤーが分かれるようにラベルを定義する 質問っぽい指摘を無くす 質問としてコメントされた場合はコードの変更はしない IMOとNITSの変更要望度が人によって異なる IMOとNITSの変更要望度が人によって異なる Questionが多用され着地点が分からないコメントがある
変更要望度に合わせてラベルを整理してみる。 IMOとNITSの変更要望度が人によって異なる
ある程度整理できたので、変更要望度を軸にドキュメントに記載。 ラベル 変更要望度 利用シーン Must 100% 明らかなバグ・仕様と実装の乖離・ガイドライン違反 Want 99%-50% パフォーマンスや可読性など非機能要件的な指摘
IMO / NITS 49%-1% (主観的な)より良い書き方の提案 Ask 0% 質問 どういった場面で利用するのかなどもある程度書いておく。 IMOとNITSの変更要望度が人によって異なる
Questionが多用され着地点が分からないコメントがある
Questionが多用され着地点が分からないコメントがある 純粋な質問まで禁止してしまうのは厳しいのでラベルは残すことになった。 その上で指摘は指摘として他のラベルを使ってもらうように。 難しそうな実装部分はモブレビューを実施してそのログを残す 「大丈夫そうですか?」みたいな変更を期待した質問はNGに レビューコメントの書き方を工夫して「質問っぽい指摘」になるのを避ける
質問を避けるために文章を工夫する方法などもドキュメントにまとめてみた。 書いたこととしては下記の3つの順番でコメントを書くといいよ、という内容でした。 前提として自分の認識 前提が正しかった場合にどのような懸念があるか それを解決する方法 これによって曖昧な部分も自分の認識を前提として変更要望度が出せるように。 質問っぽい指摘を避けるための書き方
まとめ レビューのラベルは変更要望度を基準に整理するといい 質問っぽい指摘は避けてなるべく具体的にコメントを書く