hachimaki37/20240624-mobreview

LT勉強会で発表した資料です。保守し易いアプリケーションになっていくこと、チーム全体の技術力アップに繋がっていくことで、Jカーブのような効果が期待できるプラクティスを紹介します。

Transcript

1. 勉強会/モブレビュー 2024/6/24
2. メッセージ プロダクトフェーズにもよると考えますが、プロダクト開発を行う上で、技術的負債 を少なくして高品質のソフトウェアを作成および保守していくことは重要だと考えて います。
3. メッセージ みなさんの考えはいかがでしょうか。
4. メッセージ なぜなら、日常業務が難しすぎる場合、プロダクトのスケールやイノベーションを 起こすことなどは間違いなく困難になるからだと考えています。 だから、技術的負債を少なくして高品質のソフトウェアを作成および保守していくこ とは重要なんだと。
5. メッセージ プロダクトの未来を見据え、今よりもチームは成長し、スケール・変化へ適応し易 いアプリケーションになっていったらいいなぁなんて思いませんか？
6. メッセージ 本日の勉強会では、保守し易いアプリケーションになっていくこと、チーム全体の 技術力アップに繋がっていくことで、Jカーブのような効果が期待できるプラクティス を紹介します。 では、いきますよ。
7. 擬似モブレビューを やってみようの巻 （巻と書いていますが、続きはありません）
8. はじめに - 本日の勉強会は、チームで行なっているモブレビューを実際にやってみま しょうの会です！何か一つでも、学びや改善につながる勉強会にしていきた いと思っています - チームの新たな取り組みとして、モブレビューを今年に入ってから実施してい ます。今日までに11回モブレビューを開催してきて、全体のレビューコメント 数は93件。またモブレビューを通して、Issue 化されたリファクタリングチケッ トは15件。うち15件全て改修され、Main Branch にマージされています
9. アジェンダ ※テックブログには、同様の内容を執筆しています。重複する箇所もありますが、ご了承ください。 - 概要 ~17:10まで - ワーク：擬似モブレビュー~17:45まで - ふりかえり ~17:50まで - モブレビューの活用法を紹介 - チームの声を紹介 - まとめ ~17:55まで
10. チームの前提 - 大々的にリファクタリングの時間を取ることは難しい。そのため、開発者の善 意（ボーイスカウト・ルールなど）で適宜リファクタリングは実施されている - Main Branch へのマージスピードと品質はバランスを考慮している。つまり、 場合により優先順位が入れ替わる - 細かな技術ナレッジの共有機会は少ない - 基本的に Pull Request は、レビュアーとレビューイの1対1で行われる
11. 概要 ~17:10まで
12. 概要 ・モブレビューとは何か ペアプログラミングやモブプログラミングは、聞き馴染みのあるプラクティスかと思 います。モブレビューでは、すでに Main Branch にマージ済みの Pull Requestを 対象に、1つの Pull Request を参加者全員でレビューを行う場と定義し進めてい ます。 モブレビューの場では、機能に対するレビューを行うのではなく、あくまで「ソース コードに対しての疑問点や改善点」を絞り出すことに焦点を置き実施しています。
13. 概要 ・心得 方向性や心理的安全性を高めるため、心がけることを定義しています。 - プロダクトの未来をチームで作る - どのようなソースコードであれば、開発し易くなるのか・保守し易いソー スコードになるのか・バグの少ないソースコードになるのかを考え、モブ レビューを行う - Re.special（チームのコアバリュー：「互いのリスペクトと個々のスペシャル が、チームの価値を最大化させる」といった意味） - 紆余曲折があり、今のプロダクトが稼働しています。過去のスペシャリ ティをリスペクトしながら、人ではなくソースコードに対して言及し、モブ レビューを行う
14. 概要 ・目的 チームの状況を鑑みて、以下目的を定義しています。 - ソースコードの保守性(変更容易性および理解容易性)を高める - ソースコードレビューによる知見/観点の共有およびチームの成長 ・参加者 - Designer以外
15. 概要 ・開催 - 隔週1H（1PR/回） - 初回：キックオフ - 目的、意義、やり方などをチームに共有しました - 一回目：チームにイメージを伝えるため、私が用意した Pull Request にて進めました - オフラインで実施 - 極力リアルタイムでコミュニケーションを取れるようにしています
16. 概要 ・モブレビューの担当 - 参加者全員に担当が回ってくるように順番を決めています - レビューの題材となる Pull Request の定義は、チームにレビューして欲しい ・したい・した方が良いすでに Main Branch にマージ済みの Pull Requestを 対象にしています - すでに Main Branch にマージ済みの Pull Request であれば、自分以 外の Pull Request でもOKとしています
17. 概要 ・タイムスケジュール - 題材となる Pull Request の共有：5分 - Pull Request のソースコードレビュー：15~20分 - コメント入れる際は、[モブ会]と「must, should, nits, imo, ask」入れてコ メントを残していく - Pull Request にレビューしたコメントを各自共有：5分 - Issue にするか否かを議論：15~20分 - must, should(もしあれば)は、issueを作成し対応すること。その他は議 論で決める - ※実装方法の模索は、モブレビューの時間内ではやらない - ・・・
18. 概要 ・タイムスケジュール - モブレビュー自体のふりかえり：2分 - 次回の運営に活かすため、どうだったかをふりかえります - 次回のモブレビューの担当を決める - 我こそは or サイコロ ※モブレビューを担当した人が、後日issueを作成 - [Mob Review]ラベルを貼り、issueを作成する - 1スプリントに1~4issuesくらい入れて対応できるとベター - ↑最近いい感じになってきています
19. 補足：PRコメントのルール PRのレビューの際に `must` `should` `imo` `nits` 辺りのprefixをつけて優先度を分ける - must：リリースできない、Request Changesを使用する - 対応されないとマージすることはできない事項 - 仕様の認識齟齬がある部分、バグが生じる部分、ハードウェアリソース負荷がスパイクする作 りになっているなど - should：基本的にはリリースできない、Request Changesを使用する - 修正して欲しい点 - コードのmaintainability（保守性）を下げてしまう書き方、ベストプラクティスの遵守 - ただし、理由次第では対応しないままでもApproveできる - nits(nitpick=些細な)：リリースできる、Approveを使用する - 本当に細かい指摘（typoやコメント内での文言指摘など） - 最悪このままマージしてもよいが一応修正されていると嬉しい - imo(in my opinion)：リリースできる、Approveを使用する - 個人の嗜好性の違いレベルのコメント - 自分はこう思うけどどうだろう、的な意見 - ask：リリースできない、Request Changesを使用する - 質問，疑問 - 回答してくれないとApproveはできない
20. ということで、 早速ワークをやっていきましょう！
21. ワーク：擬似モブレビュー ~17:45まで
22. ワーク：擬似モブレビュー - チームを決めましょう！（適当に分けます） - 各チームで、チーム名を決めてください - 各チームで、チームリーダーを決めてください - チーム名とチームリーダー名をホワイトボードに記載してください - チームリーダーには、最後にどんな気づきがあったか、どんなことを思ったか をこの場で共有頂きたいと思います！ ※各チームでファシリを行います
23. ワーク：擬似モブレビュー 今回は、こちらのPRで擬似モブレビューをやっていきます！
24. ワーク：擬似モブレビュー チームhoge： - hogehoge チームfuga： - fugafuga
25. タイムスケジュール - 題材となる Pull Request の共有：2分 - Pull Request の概要がわかる人が説明をお願いします - Pull Request のソースコードレビュー：10分 - コメント入れる際は、[勉強会]と「must, should, nits, imo, ask」入れてコ メントを残していく - Pull Request にレビューしたコメントを各自共有：5分 - Issue にするか否かを議論：5分 - must, should(もしあれば)は、issueを作成し対応すること。その他は議 論で決める ※実装方法の模索は、モブレビューの時間内ではやらない
26. ふりかえり ~17:50まで
27. ふりかえり 5分 - モブレビューについて、チームで振り返ってみましょう！ - どうだった？こんな学びがあったよ！ - チームではこういうところで使えそうかな？ - もっとこうしたらモブレビューはよくなるんじゃないか？ - 率直な感想 - など - チームで話したことをこの場で共有してみましょう！ - チームでは、こんな学びがありました！ - チームでは、こんなレビューのコメントがありました！ - チームでは、こんな議論がありました！ - など ※チームリーダーが、共有をお願いします
28. チームの声を紹介 - 数分間では、Pull Request をレビューし切れないので、Pull Request のソースコード量は少量の方が良さそ うです。ソースコード量（1000行くらい）がちょうど良さそうでした - 変更行数やソースコード量が少なくてもちょうどいい場合がある（触れてないドメイン・技術の場合など） - レビューのコメントに上がった tips をぜひ残していきたい - Issue 化するレビューのコメントには、🚀スタンプを押しましょう - 直近開発している Pull Request が題材だと仕様理解にもなるのでいいなと思いました - Pull Request に対するレビューのコメントが少ない方が議論しやすい - 時間がなくて議論できなかったレビューのコメントも話せると良い - 最近はいよいよ指摘が難しくなりましたね、いい意味で。
29. モブレビューの別の使い方 本来の目的とは少し異なりますが、毎回のふりかえりから以下のような使い方に もモブレビューは適応できそうに思いました - 仕様、ソースコードの理解や共有 - 新しい技術のインプットの機会 - レガシーなソースコードの改修のきっかけ - コーディングルールや Tips の共有
30. まとめ モブレビュー自体は、何かすぐに効果のでるプラクティスではないかと考えており ますが、保守し易いアプリケーションになっていくこと、チーム全体の技術力アップ に繋がっていくことで、Jカーブのような効果が期待できるプラクティスなのではない かと感じています。
31. おしまい ありがとうございました！