レビューに向けて工夫した話

Transcript

1. レビューに向けて ⼯夫した話 2024.7.31 アノテーション株式会社 ⾼崎 渉
2. Xへの投稿の際は、 ハッシュタグ #devio2024 でお願いいたします。 2 お願い
3. ⾃⼰紹介 3
4. ⾃⼰紹介 4 高崎 渉 たかさき わたる 【所属】 アノテーション株式会社 エンジニア統括部 パートナーアライアンスゾーン LINE/アプリ DevOps チーム 【入社】 2023 年 3 月 【これまで】 オンプレミス開発 約６年 組込開発 約２０年 →LINEミニアプリの運用保守にジョブチェンジ
5. 今回のお話 5
6. 今回のお話について 6 ▪お話すること ▪対象 • レビュー資料に⼀⼯夫したこと • レビュー⾃体を⼀⼯夫したこと • 形骸化したレビューをなんとかしたい • どういった観点でレビューすればよいかわからない
7. ソフトウェアにおけるレビュー 7 ▪「ソフトウェア レビュー 課題」 google 検索：約 200 万件ヒット • レビューは合意形成の場だということを理解する • 事前にレビュー対象物を展開して準備する • 揚げ⾜取りで個⼈攻撃にならないようにする ‧‧‧といった話ではなく、 レビューの対象物ややり⽅に⼀⼯夫したお話。
8. 背景 8 ▪LINE ミニアプリ運用保守業務 クラスメソッドグループ全体で LINE 事業の維持と拡⼤ • 脆弱性に積極対応し、安定した運⽤を維持 • クラスメソッド開発エンジニアの負荷軽減 • LINE 業務で得たナレッジを集約、蓄積 中規模を超えた差分開発を携わることになり、 ドキュメントやソースへの確認事が増えてきた
9. 要件や処理の 経緯が知りたいが、 あるのはドキュメント やソースのみ 9
10. 経緯を残す 仕組みを作ろう 10
11. １．レビュー対象物に⼀⼯夫 11
12. レビュー対象物へ⼯夫したこと 12 レビュー対象物：設計書・データフロー図・ソース これらのようないわば「検討の成れの果て」ではなく、 下記のような成果物に⾄る⾏間の部分を残して記載する。 • お客様と整理した内容（Backlog や JIRA の URL でも可） ◦ 経緯の記録を余すことなく出す • 設計⽅針の検討内容 ◦ 検討項⽬の要否 • 改修するソースの事前調査内容 ◦ 検索して調査した場合はその検索を⾏った⽂⾔と対応要否 • 追加するソースの実装⽅針 ◦ 要件実現のために実装する内容 →ADR（Architecture Decision Report）を作成
13. まずは ADR を確認する 13 確認内容 • お客様と整理した内容（Backlog や JIRA の URL でも可） • 設計⽅針の検討内容 • 改修するソースの事前調査内容 • 追加するソースの実装⽅針 →整理内容のチェック
 →方針や検討の是非
 →調査内容の是非
 →コストの確認（処理時間、従量課金） 
 →実装モレのチェック
 レビュアーの判断対象 
 検討内容の妥当性 
 次期開発の参考資料 
 新規メンバーの教育 
 ＝チームの重要な資産 

14. １．のまとめ 14 設計書・ソースの 行間こそがレビュー対象 
 • 検討事項を ADR として整理 • レビューは ADR に関する妥当性を判断 • 品質記録や今後の参考資料として活⽤
15. ２．レビューに⼀⼯夫 15
16. レビュー 16 ▪英語の「レビュー（review）」 直訳すると、 • 再検査 • 評価 • 批判 • 振り返り レビューはレビューアの振り返りの場
17. 振り返りのフレームワーク 17 ▪KPT（Keep Problem Try） • Keep‧‧‧？？？ • Problem‧‧‧レビュー対象物への問題指摘 • Try‧‧‧指摘された問題に対する施策、修正 レビューでKeepするものを明らかにする
18. どうしたら？ 18
19. 褒めましょう 19
20. 褒めましょう 20 その検討⽅法、 とても良く 整理されていますね 可読性の上がる リファクタリング 有難うございます とても観点の広い テストケースだと 思います 複雑な要件の整理 お疲れ様でした きめ細やかな 条件分けの検討、 さすがです そのコメント、 わかりやすいです などなど 等々 etc.
21. ２．のまとめ 21 レビューでは褒めることも意識する 
 • 「ダメ出し」だけではなく「良かった探し」も実施 • ⾃分だと出来なかったものをどんどんピックアップ • 出てきたものをナレッジとして後段に活⽤
22. まとめ 22
23. まとめ • 経過、経緯を残して判断する • 「良かった探し」を⾏う 23