Upgrade to Pro — share decks privately, control downloads, hide ads and more …

hachimaki37/20240624-mobreview

 hachimaki37/20240624-mobreview

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

Avatar for Hachimaki37

Hachimaki37

June 24, 2024
Tweet

More Decks by Hachimaki37

Other Decks in Programming

Transcript

  1. 概要 ・モブレビューとは何か ペアプログラミングやモブプログラミングは、聞き馴染みのあるプラクティスかと思 います。モブレビューでは、すでに Main Branch にマージ済みの Pull Requestを 対象に、1つの

    Pull Request を参加者全員でレビューを行う場と定義し進めてい ます。 モブレビューの場では、機能に対するレビューを行うのではなく、あくまで「ソース コードに対しての疑問点や改善点」を絞り出すことに焦点を置き実施しています。
  2. 概要 ・心得 方向性や心理的安全性を高めるため、心がけることを定義しています。 - プロダクトの未来をチームで作る - どのようなソースコードであれば、開発し易くなるのか・保守し易いソー スコードになるのか・バグの少ないソースコードになるのかを考え、モブ レビューを行う -

    Re.special(チームのコアバリュー:「互いのリスペクトと個々のスペシャル が、チームの価値を最大化させる」といった意味) - 紆余曲折があり、今のプロダクトが稼働しています。過去のスペシャリ ティをリスペクトしながら、人ではなくソースコードに対して言及し、モブ レビューを行う
  3. 概要 ・開催 - 隔週1H(1PR/回) - 初回:キックオフ - 目的、意義、やり方などをチームに共有しました - 一回目:チームにイメージを伝えるため、私が用意した

    Pull Request にて進めました - オフラインで実施 - 極力リアルタイムでコミュニケーションを取れるようにしています
  4. 概要 ・モブレビューの担当 - 参加者全員に担当が回ってくるように順番を決めています - レビューの題材となる Pull Request の定義は、チームにレビューして欲しい ・したい・した方が良いすでに

    Main Branch にマージ済みの Pull Requestを 対象にしています - すでに Main Branch にマージ済みの Pull Request であれば、自分以 外の Pull Request でもOKとしています
  5. 概要 ・タイムスケジュール - 題材となる Pull Request の共有:5分 - Pull Request

    のソースコードレビュー:15~20分 - コメント入れる際は、[モブ会]と「must, should, nits, imo, ask」入れてコ メントを残していく - Pull Request にレビューしたコメントを各自共有:5分 - Issue にするか否かを議論:15~20分 - must, should(もしあれば)は、issueを作成し対応すること。その他は議 論で決める - ※実装方法の模索は、モブレビューの時間内ではやらない - ・・・
  6. 概要 ・タイムスケジュール - モブレビュー自体のふりかえり:2分 - 次回の運営に活かすため、どうだったかをふりかえります - 次回のモブレビューの担当を決める - 我こそは

    or サイコロ ※モブレビューを担当した人が、後日issueを作成 - [Mob Review]ラベルを貼り、issueを作成する - 1スプリントに1~4issuesくらい入れて対応できるとベター - ↑最近いい感じになってきています
  7. 補足: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はできない
  8. タイムスケジュール - 題材となる Pull Request の共有:2分 - Pull Request の概要がわかる人が説明をお願いします

    - Pull Request のソースコードレビュー:10分 - コメント入れる際は、[勉強会]と「must, should, nits, imo, ask」入れてコ メントを残していく - Pull Request にレビューしたコメントを各自共有:5分 - Issue にするか否かを議論:5分 - must, should(もしあれば)は、issueを作成し対応すること。その他は議 論で決める ※実装方法の模索は、モブレビューの時間内ではやらない
  9. ふりかえり 5分 - モブレビューについて、チームで振り返ってみましょう! - どうだった?こんな学びがあったよ! - チームではこういうところで使えそうかな? - もっとこうしたらモブレビューはよくなるんじゃないか?

    - 率直な感想 - など - チームで話したことをこの場で共有してみましょう! - チームでは、こんな学びがありました! - チームでは、こんなレビューのコメントがありました! - チームでは、こんな議論がありました! - など ※チームリーダーが、共有をお願いします
  10. チームの声を紹介 - 数分間では、Pull Request をレビューし切れないので、Pull Request のソースコード量は少量の方が良さそ うです。ソースコード量(1000行くらい)がちょうど良さそうでした - 変更行数やソースコード量が少なくてもちょうどいい場合がある(触れてないドメイン・技術の場合など)

    - レビューのコメントに上がった tips をぜひ残していきたい - Issue 化するレビューのコメントには、🚀スタンプを押しましょう - 直近開発している Pull Request が題材だと仕様理解にもなるのでいいなと思いました - Pull Request に対するレビューのコメントが少ない方が議論しやすい - 時間がなくて議論できなかったレビューのコメントも話せると良い - 最近はいよいよ指摘が難しくなりましたね、いい意味で。