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
Takasaki Wataru
July 31, 2024
Programming
0
240
レビューに向けて工夫した話
Takasaki Wataru
July 31, 2024
Tweet
Share
Other Decks in Programming
See All in Programming
LangChainの現在とv0.3にむけて
os1ma
4
790
The Future of Frontend i18n : Intl.MessageFormat
sajikix
1
2.5k
今インフラ技術をイチから学び直すなら
yuhta28
1
120
Prolog入門
qnighy
3
590
私のEbitengineの第一歩
qt_luigi
0
440
Some more adventure of Happy Eyeballs
coe401_
2
160
どうしてこうなった?から理解するActive Recordの関連の裏側
willnet
5
540
Scala におけるコンパイラエラーとの付き合い方
chencmd
2
380
Swift Concurrencyとレースコンディション
objectiveaudio
1
400
1人で挑むSwiftコンパイラ 〜型システム入門編〜
s_shimotori
0
330
エンジニア1年目で複雑なコードの改善に取り組んだ話
mtnmr
1
240
月間4.5億回再生を超える大規模サービス TVer iOSアプリのリアーキテクチャ戦略 - iOSDC2024
techtver
PRO
1
720
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
179
21k
The Invisible Customer
myddelton
119
13k
KATA
mclloyd
27
13k
The Straight Up "How To Draw Better" Workshop
denniskardys
230
130k
Unsuck your backbone
ammeep
667
57k
Pencils Down: Stop Designing & Start Developing
hursman
119
11k
Clear Off the Table
cherdarchuk
91
320k
The Brand Is Dead. Long Live the Brand.
mthomps
53
37k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Art, The Web, and Tiny UX
lynnandtonic
294
20k
Side Projects
sachag
451
42k
How to name files
jennybc
75
98k
Transcript
レビューに向けて ⼯夫した話 2024.7.31 アノテーション株式会社 ⾼崎 渉
Xへの投稿の際は、 ハッシュタグ #devio2024 でお願いいたします。 2 お願い
⾃⼰紹介 3
⾃⼰紹介 4 高崎 渉 たかさき わたる 【所属】 アノテーション株式会社 エンジニア統括部 パートナーアライアンスゾーン
LINE/アプリ DevOps チーム 【入社】 2023 年 3 月 【これまで】 オンプレミス開発 約6年 組込開発 約20年 →LINEミニアプリの運用保守にジョブチェンジ
今回のお話 5
今回のお話について 6 ▪お話すること ▪対象 • レビュー資料に⼀⼯夫したこと • レビュー⾃体を⼀⼯夫したこと • 形骸化したレビューをなんとかしたい
• どういった観点でレビューすればよいかわからない
ソフトウェアにおけるレビュー 7 ▪「ソフトウェア レビュー 課題」 google 検索:約 200 万件ヒット •
レビューは合意形成の場だということを理解する • 事前にレビュー対象物を展開して準備する • 揚げ⾜取りで個⼈攻撃にならないようにする ‧‧‧といった話ではなく、 レビューの対象物ややり⽅に⼀⼯夫したお話。
背景 8 ▪LINE ミニアプリ運用保守業務 クラスメソッドグループ全体で LINE 事業の維持と拡⼤ • 脆弱性に積極対応し、安定した運⽤を維持 •
クラスメソッド開発エンジニアの負荷軽減 • LINE 業務で得たナレッジを集約、蓄積 中規模を超えた差分開発を携わることになり、 ドキュメントやソースへの確認事が増えてきた
要件や処理の 経緯が知りたいが、 あるのはドキュメント やソースのみ 9
経緯を残す 仕組みを作ろう 10
1.レビュー対象物に⼀⼯夫 11
レビュー対象物へ⼯夫したこと 12 レビュー対象物:設計書・データフロー図・ソース これらのようないわば「検討の成れの果て」ではなく、 下記のような成果物に⾄る⾏間の部分を残して記載する。 • お客様と整理した内容(Backlog や JIRA の
URL でも可) ◦ 経緯の記録を余すことなく出す • 設計⽅針の検討内容 ◦ 検討項⽬の要否 • 改修するソースの事前調査内容 ◦ 検索して調査した場合はその検索を⾏った⽂⾔と対応要否 • 追加するソースの実装⽅針 ◦ 要件実現のために実装する内容 →ADR(Architecture Decision Report)を作成
まずは ADR を確認する 13 確認内容 • お客様と整理した内容(Backlog や JIRA の
URL でも可) • 設計⽅針の検討内容 • 改修するソースの事前調査内容 • 追加するソースの実装⽅針 →整理内容のチェック →方針や検討の是非 →調査内容の是非 →コストの確認(処理時間、従量課金) →実装モレのチェック レビュアーの判断対象 検討内容の妥当性 次期開発の参考資料 新規メンバーの教育 =チームの重要な資産
1.のまとめ 14 設計書・ソースの 行間こそがレビュー対象 • 検討事項を ADR として整理 •
レビューは ADR に関する妥当性を判断 • 品質記録や今後の参考資料として活⽤
2.レビューに⼀⼯夫 15
レビュー 16 ▪英語の「レビュー(review)」 直訳すると、 • 再検査 • 評価 • 批判
• 振り返り レビューはレビューアの振り返りの場
振り返りのフレームワーク 17 ▪KPT(Keep Problem Try) • Keep‧‧‧??? • Problem‧‧‧レビュー対象物への問題指摘 •
Try‧‧‧指摘された問題に対する施策、修正 レビューでKeepするものを明らかにする
どうしたら? 18
褒めましょう 19
褒めましょう 20 その検討⽅法、 とても良く 整理されていますね 可読性の上がる リファクタリング 有難うございます とても観点の広い テストケースだと
思います 複雑な要件の整理 お疲れ様でした きめ細やかな 条件分けの検討、 さすがです そのコメント、 わかりやすいです などなど 等々 etc.
2.のまとめ 21 レビューでは褒めることも意識する • 「ダメ出し」だけではなく「良かった探し」も実施 • ⾃分だと出来なかったものをどんどんピックアップ • 出てきたものをナレッジとして後段に活⽤
まとめ 22
まとめ • 経過、経緯を残して判断する • 「良かった探し」を⾏う 23
24