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
hachimaki37/20240624-mobreview
Search
Hachimaki37
June 24, 2024
Programming
0
5
hachimaki37/20240624-mobreview
LT勉強会で発表した資料です。保守し易いアプリケーションになっていくこと、チーム全体の技術力アップに繋がっていくことで、Jカーブのような効果が期待できるプラクティスを紹介します。
Hachimaki37
June 24, 2024
Tweet
Share
More Decks by Hachimaki37
See All by Hachimaki37
hachimaki37/20250617-setting-targets
hachimaki37
0
100
hachimaki37/20250417-productivity-in-development
hachimaki37
0
58
hachimaki37/20250306-devex
hachimaki37
0
340
hachimaki37/20240617-devexmodel
hachimaki37
0
6
hachimaki37/20240527-scrum
hachimaki37
0
4
hachimaki37/20230511-techblog
hachimaki37
0
5
hachimaki37/20240427-graphql
hachimaki37
0
3
hachimaki37/20220825-retrospective
hachimaki37
0
5
Other Decks in Programming
See All in Programming
AWS CDKの推しポイント 〜CloudFormationと比較してみた〜
akihisaikeda
3
310
Elixir で IoT 開発、 Nerves なら簡単にできる!?
pojiro
1
150
Blazing Fast UI Development with Compose Hot Reload (droidcon New York 2025)
zsmb
1
200
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
46
31k
すべてのコンテキストを、 ユーザー価値に変える
applism118
2
790
A2A プロトコルを試してみる
azukiazusa1
2
1.1k
都市をデータで見るってこういうこと PLATEAU属性情報入門
nokonoko1203
1
570
Result型で“失敗”を型にするPHPコードの書き方
kajitack
4
370
Cline指示通りに動かない? AI小説エージェントで学ぶ指示書の書き方と自動アップデートの仕組み
kamomeashizawa
1
570
既存デザインを変更せずにタップ領域を広げる方法
tahia910
1
240
型付きアクターモデルがもたらす分散シミュレーションの未来
piyo7
0
810
Google Agent Development Kit でLINE Botを作ってみた
ymd65536
2
180
Featured
See All Featured
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Optimizing for Happiness
mojombo
379
70k
Site-Speed That Sticks
csswizardry
10
660
Git: the NoSQL Database
bkeepers
PRO
430
65k
What's in a price? How to price your products and services
michaelherold
246
12k
How to Ace a Technical Interview
jacobian
277
23k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
48
5.4k
Done Done
chrislema
184
16k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.4k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
490
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3k
Transcript
勉強会/モブレビュー 2024/6/24
メッセージ プロダクトフェーズにもよると考えますが、プロダクト開発を行う上で、技術的負債 を少なくして高品質のソフトウェアを作成および保守していくことは重要だと考えて います。
メッセージ みなさんの考えはいかがでしょうか。
メッセージ なぜなら、日常業務が難しすぎる場合、プロダクトのスケールやイノベーションを 起こすことなどは間違いなく困難になるからだと考えています。 だから、技術的負債を少なくして高品質のソフトウェアを作成および保守していくこ とは重要なんだと。
メッセージ プロダクトの未来を見据え、今よりもチームは成長し、スケール・変化へ適応し易 いアプリケーションになっていったらいいなぁなんて思いませんか?
メッセージ 本日の勉強会では、保守し易いアプリケーションになっていくこと、チーム全体の 技術力アップに繋がっていくことで、Jカーブのような効果が期待できるプラクティス を紹介します。 では、いきますよ。
擬似モブレビューを やってみようの巻 (巻と書いていますが、続きはありません)
はじめに - 本日の勉強会は、チームで行なっているモブレビューを実際にやってみま しょうの会です!何か一つでも、学びや改善につながる勉強会にしていきた いと思っています - チームの新たな取り組みとして、モブレビューを今年に入ってから実施してい ます。今日までに11回モブレビューを開催してきて、全体のレビューコメント 数は93件。またモブレビューを通して、Issue 化されたリファクタリングチケッ
トは15件。うち15件全て改修され、Main Branch にマージされています
アジェンダ ※テックブログには、同様の内容を執筆しています。重複する箇所もありますが、ご了承ください。 - 概要 ~17:10まで - ワーク:擬似モブレビュー~17:45まで - ふりかえり ~17:50まで
- モブレビューの活用法を紹介 - チームの声を紹介 - まとめ ~17:55まで
チームの前提 - 大々的にリファクタリングの時間を取ることは難しい。そのため、開発者の善 意(ボーイスカウト・ルールなど)で適宜リファクタリングは実施されている - Main Branch へのマージスピードと品質はバランスを考慮している。つまり、 場合により優先順位が入れ替わる -
細かな技術ナレッジの共有機会は少ない - 基本的に Pull Request は、レビュアーとレビューイの1対1で行われる
概要 ~17:10まで
概要 ・モブレビューとは何か ペアプログラミングやモブプログラミングは、聞き馴染みのあるプラクティスかと思 います。モブレビューでは、すでに Main Branch にマージ済みの Pull Requestを 対象に、1つの
Pull Request を参加者全員でレビューを行う場と定義し進めてい ます。 モブレビューの場では、機能に対するレビューを行うのではなく、あくまで「ソース コードに対しての疑問点や改善点」を絞り出すことに焦点を置き実施しています。
概要 ・心得 方向性や心理的安全性を高めるため、心がけることを定義しています。 - プロダクトの未来をチームで作る - どのようなソースコードであれば、開発し易くなるのか・保守し易いソー スコードになるのか・バグの少ないソースコードになるのかを考え、モブ レビューを行う -
Re.special(チームのコアバリュー:「互いのリスペクトと個々のスペシャル が、チームの価値を最大化させる」といった意味) - 紆余曲折があり、今のプロダクトが稼働しています。過去のスペシャリ ティをリスペクトしながら、人ではなくソースコードに対して言及し、モブ レビューを行う
概要 ・目的 チームの状況を鑑みて、以下目的を定義しています。 - ソースコードの保守性(変更容易性および理解容易性)を高める - ソースコードレビューによる知見/観点の共有およびチームの成長 ・参加者 - Designer以外
概要 ・開催 - 隔週1H(1PR/回) - 初回:キックオフ - 目的、意義、やり方などをチームに共有しました - 一回目:チームにイメージを伝えるため、私が用意した
Pull Request にて進めました - オフラインで実施 - 極力リアルタイムでコミュニケーションを取れるようにしています
概要 ・モブレビューの担当 - 参加者全員に担当が回ってくるように順番を決めています - レビューの題材となる Pull Request の定義は、チームにレビューして欲しい ・したい・した方が良いすでに
Main Branch にマージ済みの Pull Requestを 対象にしています - すでに Main Branch にマージ済みの Pull Request であれば、自分以 外の Pull Request でもOKとしています
概要 ・タイムスケジュール - 題材となる Pull Request の共有:5分 - Pull Request
のソースコードレビュー:15~20分 - コメント入れる際は、[モブ会]と「must, should, nits, imo, ask」入れてコ メントを残していく - Pull Request にレビューしたコメントを各自共有:5分 - Issue にするか否かを議論:15~20分 - must, should(もしあれば)は、issueを作成し対応すること。その他は議 論で決める - ※実装方法の模索は、モブレビューの時間内ではやらない - ・・・
概要 ・タイムスケジュール - モブレビュー自体のふりかえり:2分 - 次回の運営に活かすため、どうだったかをふりかえります - 次回のモブレビューの担当を決める - 我こそは
or サイコロ ※モブレビューを担当した人が、後日issueを作成 - [Mob Review]ラベルを貼り、issueを作成する - 1スプリントに1~4issuesくらい入れて対応できるとベター - ↑最近いい感じになってきています
補足: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はできない
ということで、 早速ワークをやっていきましょう!
ワーク:擬似モブレビュー ~17:45まで
ワーク:擬似モブレビュー - チームを決めましょう!(適当に分けます) - 各チームで、チーム名を決めてください - 各チームで、チームリーダーを決めてください - チーム名とチームリーダー名をホワイトボードに記載してください -
チームリーダーには、最後にどんな気づきがあったか、どんなことを思ったか をこの場で共有頂きたいと思います! ※各チームでファシリを行います
ワーク:擬似モブレビュー 今回は、こちらのPRで擬似モブレビューをやっていきます!
ワーク:擬似モブレビュー チームhoge: - hogehoge チームfuga: - fugafuga
タイムスケジュール - 題材となる Pull Request の共有:2分 - Pull Request の概要がわかる人が説明をお願いします
- Pull Request のソースコードレビュー:10分 - コメント入れる際は、[勉強会]と「must, should, nits, imo, ask」入れてコ メントを残していく - Pull Request にレビューしたコメントを各自共有:5分 - Issue にするか否かを議論:5分 - must, should(もしあれば)は、issueを作成し対応すること。その他は議 論で決める ※実装方法の模索は、モブレビューの時間内ではやらない
ふりかえり ~17:50まで
ふりかえり 5分 - モブレビューについて、チームで振り返ってみましょう! - どうだった?こんな学びがあったよ! - チームではこういうところで使えそうかな? - もっとこうしたらモブレビューはよくなるんじゃないか?
- 率直な感想 - など - チームで話したことをこの場で共有してみましょう! - チームでは、こんな学びがありました! - チームでは、こんなレビューのコメントがありました! - チームでは、こんな議論がありました! - など ※チームリーダーが、共有をお願いします
チームの声を紹介 - 数分間では、Pull Request をレビューし切れないので、Pull Request のソースコード量は少量の方が良さそ うです。ソースコード量(1000行くらい)がちょうど良さそうでした - 変更行数やソースコード量が少なくてもちょうどいい場合がある(触れてないドメイン・技術の場合など)
- レビューのコメントに上がった tips をぜひ残していきたい - Issue 化するレビューのコメントには、🚀スタンプを押しましょう - 直近開発している Pull Request が題材だと仕様理解にもなるのでいいなと思いました - Pull Request に対するレビューのコメントが少ない方が議論しやすい - 時間がなくて議論できなかったレビューのコメントも話せると良い - 最近はいよいよ指摘が難しくなりましたね、いい意味で。
モブレビューの別の使い方 本来の目的とは少し異なりますが、毎回のふりかえりから以下のような使い方に もモブレビューは適応できそうに思いました - 仕様、ソースコードの理解や共有 - 新しい技術のインプットの機会 - レガシーなソースコードの改修のきっかけ -
コーディングルールや Tips の共有
まとめ モブレビュー自体は、何かすぐに効果のでるプラクティスではないかと考えており ますが、保守し易いアプリケーションになっていくこと、チーム全体の技術力アップ に繋がっていくことで、Jカーブのような効果が期待できるプラクティスなのではない かと感じています。
おしまい ありがとうございました!