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
ken7253
December 16, 2024
Programming
0
66
レビューのやり方を(ちょっと)整理した話
@[IVRyエンジニア忘年LT大会2024](
https://connpass.com/event/333537/
)
ken7253
December 16, 2024
Tweet
Share
More Decks by ken7253
See All by ken7253
オーバーロード関数の話 @Mita.ts #2
ken7253
0
57
フロントエンドカンファレンス北海道参加レポート
ken7253
0
26
カスタムHooksと単体テストの共通点について
ken7253
0
300
検索エンジン最適化はWebサイトのすべてなのか
ken7253
0
39
使いやすいツールチップを実装する方法
ken7253
0
81
Reactにおけるkeyの使い方について
ken7253
1
150
テックブログ文豪への道
ken7253
0
60
関数型プログラミングの考え方を取り入れて予測しやすいコードを書く
ken7253
0
150
学び続けるための方法
ken7253
0
120
Other Decks in Programming
See All in Programming
Java Webフレームワークの現状 / java web framework at burikaigi
kishida
9
2.1k
Ruby on cygwin 2025-02
fd0
0
130
AHC041解説
terryu16
0
580
はてなにおけるfujiwara-wareの活用やecspressoのCI/CD構成 / Fujiwara Tech Conference 2025
cohalz
3
4.7k
2024年のWebフロントエンドのふりかえりと2025年
sakito
1
210
Amazon ECS とマイクロサービスから考えるシステム構成
hiyanger
3
470
Djangoアプリケーション 運用のリアル 〜問題発生から可視化、最適化への道〜 #pyconshizu
kashewnuts
1
200
パスキーのすべて ── 導入・UX設計・実装の紹介 / 20250213 パスキー開発者の集い
kuralab
1
270
GitHub Actions × RAGでコードレビューの検証の結果
sho_000
0
230
振り返れば奴(Cline)がいる
keiyagi
0
180
Flutter × Firebase Genkit で加速する生成 AI アプリ開発
coborinai
0
130
[Fin-JAWS 第38回 ~re:Invent 2024 金融re:Cap~]FaultInjectionServiceアップデート@pre:Invent2024
shintaro_fukatsu
0
400
Featured
See All Featured
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
6
530
The Cult of Friendly URLs
andyhume
78
6.2k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Why Our Code Smells
bkeepers
PRO
335
57k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
128
19k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
BBQ
matthewcrist
86
9.4k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.2k
What's in a price? How to price your products and services
michaelherold
244
12k
Building Your Own Lightsaber
phodgson
104
6.2k
Typedesign – Prime Four
hannesfritz
40
2.5k
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つの順番でコメントを書くといいよ、という内容でした。 前提として自分の認識 前提が正しかった場合にどのような懸念があるか それを解決する方法 これによって曖昧な部分も自分の認識を前提として変更要望度が出せるように。 質問っぽい指摘を避けるための書き方
まとめ レビューのラベルは変更要望度を基準に整理するといい 質問っぽい指摘は避けてなるべく具体的にコメントを書く