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
[2019/03/23]プルリクとの上手な付き合い方
Search
tosite
March 23, 2019
Technology
0
21
[2019/03/23]プルリクとの上手な付き合い方
NaITE #30 「プルリクとの上手な付き合い方 and もくもく会」
https://nagasaki-it-engineers.connpass.com/event/121343/
tosite
March 23, 2019
Tweet
Share
More Decks by tosite
See All by tosite
[2025-02-07]生成AIで変える問い合わせの未来 〜チームグローバル化の香りを添えて〜
tosite
1
430
[2024/10/25]CREの守護者たち 〜DevOps×シフトレフト - 俺またプロダクト救っちゃいました!?〜
tosite
0
810
[2024/07/11]Guardianとして生まれ変わった俺は攻めと守りの運用で無双する 〜守りの天才が考える、攻めの運用術〜
tosite
0
900
[2024/04/23]tbls活用事例 〜 ビューポイントから データベースを整理してみた話 〜
tosite
0
430
[2023/09/15]ER図クエスト 過ぎ去りしドキュメントを求めて 〜複雑性に眠る秘宝〜
tosite
0
640
[2022/12/07]この素晴らしいアプリケーションにテストコードを
tosite
0
42
[2022/03/25]コミュニティから学ぶエンジニアリング
tosite
0
350
[2021/12/16]テストコードのないレガシーアプリケーションとの向き合い方
tosite
0
65
[2019/07/27]はじめよう、ニコカレ!
tosite
0
39
Other Decks in Technology
See All in Technology
Nekko Cloud、 これまでとこれから ~学生サークルが作る、 小さなクラウド
logica0419
2
950
Amazon S3 Tablesと外部分析基盤連携について / Amazon S3 Tables and External Data Analytics Platform
nttcom
0
130
オブザーバビリティの観点でみるAWS / AWS from observability perspective
ymotongpoo
8
1.4k
開発組織のための セキュアコーディング研修の始め方
flatt_security
3
2.1k
利用終了したドメイン名の最強終活〜観測環境を育てて、分析・供養している件〜 / The Ultimate End-of-Life Preparation for Discontinued Domain Names
nttcom
2
180
自動テストの世界に、この5年間で起きたこと
autifyhq
10
8.4k
運用しているアプリケーションのDBのリプレイスをやってみた
miura55
1
680
急成長する企業で作った、エンジニアが輝ける制度/ 20250214 Rinto Ikenoue
shift_evolve
3
1.2k
OpenID Connect for Identity Assurance の概要と翻訳版のご紹介 / 20250219-BizDay17-OIDC4IDA-Intro
oidfj
0
260
Developers Summit 2025 浅野卓也(13-B-7 LegalOn Technologies)
legalontechnologies
PRO
0
650
飲食店予約台帳を支えるインタラクティブ UI 設計と実装
siropaca
7
1.7k
マルチモーダル理解と生成の統合 DeepSeek Janus, etc... / Multimodal Understanding and Generation Integration
hiroga
0
380
Featured
See All Featured
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
174
51k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.7k
How GitHub (no longer) Works
holman
314
140k
A Modern Web Designer's Workflow
chriscoyier
693
190k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.3k
Site-Speed That Sticks
csswizardry
4
380
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
GitHub's CSS Performance
jonrohan
1030
460k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
10
1.3k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Transcript
プルリクとの 上手な付き合い方 Event / NaITE #30 プルリクとの上手な付き合い方 and もくもく会 Date
/ 2019-03-23 (Sat) Presenter / Naoto Teshima (tosite / まおちゃ)
はじめまして
わたし
None
GMOペパボ ホスティング事業部 ムームードメイングループ所属 手島 尚人 インターネット上ではまおちゃという名前で バーチャルJKやってます
最近はRuby on Railsや Laravelなどを書いています
Twitter : @mao_sum Blog : tosite.work NaITE・JaSST九州・ PHPカンファレンス福岡 の実行委員もやっています
おもしろ自己紹介
ref: https://kimromi.hatenablog.jp/entry/2019/02/23/225740
はい
はじめに
皆さん、プルリクを 作っていますか?
Git全盛期の昨今 名前だけでも聞いたことが あるかと思います
特にチーム開発を行う場合、 プロダクトの品質を担保するためにも プルリク→コードレビューの流れ は必要不可欠かなと思います
そんな中で、こんなプルリクを 見たことはありませんか?
None
None
^q^
おおよそニンゲンには 検知不可能な変更量
そしてこんなコミットを 積んでいませんか?
None
^q^
何が変わったのか わからない
今日は よいプルリクを作るには? プルリクとの上手な付き合い方 を実体験からお話ししていきます
参考文献:イシューからはじめよ
起
知的生産者 としての心構え
知的生産者としての心構え ってなんだと思いますか?
知的生産者としての心構え 最小限の時間で 最大限の生産性を出す 方法を考えていくことだと思います
知的生産者としての心構え そのためには 犬の道 から脱却しなくてはなりません
知的生産者としての心構え 犬の道とは
知的生産者としての心構え 一心不乱に仕事を することで問題解決 していこうとする姿勢のこと
知的生産者としての心構え
知的生産者としての心構え
知的生産者としての心構え 限られた時間・リソースの中で効率を高めるには 課題の本質を見抜き 解の質を高めていく ことが必要不可欠です
知的生産者としての心構え 特にありがちなのは、 丁寧にやりすぎた結果 膨大な時間を費やしてしまう ことです
知的生産者としての心構え もちろん丁寧さは大切ですが、それ以上に イテレーションの回転数・スピード感 を上げていくことが最重要です
知的生産者としての心構え 考える 答えを出す 答えを出す 考える 答えを出す 考える 答えを出す 考える 時間
知的生産者としての心構え 考える 答えを出す 答えを出す 考える 答えを出す 考える 答えを出す 考える 時間
知的生産者としての心構え そのためにも Issueやプルリクと 上手に付き合いつつ 犬の道から脱却していきましょう
閑話休題 -海の話-
閑話休題 突然ですが皆さん、海に 泳ぎに行ったらどうしますか?
閑話休題 いきなり着替えもせずに海に入る、 ということはしないと思います
閑話休題 まずは着替えて、日焼け止めを塗って、準備運動して… 事前の準備を済ませてから 泳ぎますよね
閑話休題 何かを作るときにも同じで、 いきなり飛び込まずに 最初に考える時間を作る ことが大事だと僕は思います
閑話休題 そもそも何の問題を解決するためなのか どういった問題があるのかなど、やるべきことを 大きいことから徐々に細かく分解 していくといいです
閑話休題 このあたりの詳しい話について興味のある方は イシューからはじめよ をご覧ください
ポイントは 悩まないこと
ポイントは悩まないこと 皆さん、悩むことと考えることは どう違うと思いますか?
ポイントは悩まないこと アイスブレイク3分: 自己紹介 話し合う
ポイントは悩まないこと 悩む
ポイントは悩まないこと 決めかねたり解決の方法が 見いだせなかったりして、心を痛める。 思いわずらう。 goo辞書: https://dictionary.goo.ne.jp/jn/165175/meaning/m0u/%E6%82%A9%E3%82%80/
ポイントは悩まないこと 考える
ポイントは悩まないこと 知識や経験などに基づいて、 筋道を立てて頭を働かせる。 goo辞書: https://dictionary.goo.ne.jp/jn/47607/meaning/m0u/%E8%80%83%E3%81%88%E3%82%8B/
ポイントは悩まないこと 考えても答えが出ないことに 思いを巡らせることが「悩む」 具体的に解決への道筋を 組み立てることが「考える」
ポイントは悩まないこと 僕自身悩むこともそれはそれで好きではありますが… 10分考えて分からないことは 悩んでいる可能性が高いです 悩むことをやめて聞こう・相談しよう
ポイントは悩まないこと でも、誰かに相談された場合に、 思考の順序や道筋が見えない と相談を受ける側もよくわからないことがあります…
フレームワークを 使おう
フレームワークを使おう 考えを整理するにあたって、 フレームワークの力を借りる ことはとても有益です
フレームワークを使おう 5W1Hやなぜなぜ分析 といった言葉を耳にしたことはありませんか?
フレームワークを使おう 個人的にオススメなのは マインドマップ です
フレームワークを使おう
フレームワークを使おう 思考の過程が可視化される ため、他の人が見たときにわかりやすいと思います
承
プルリクを 構成するもの
プルリクを構成するもの
プルリクを構成するもの コミット
プルリクを構成するもの どんな作業をしたのかが一言で言える ようなコミットがわかりやすいです
プルリクを構成するもの あとでレビューを受けるときに コミット単位で見られる ことを考えておこう
プルリクを構成するもの タイトル
プルリクを構成するもの 例えばリリースして半年経過して、 過去のプルリクを検索する、 といったシチュエーションを 想像していただきたいのですが
プルリクを構成するもの
プルリクを構成するもの こちらとこちら、 どちらが見やすいですか?
プルリクを構成するもの 後から探しやすいタイトル をつけることを意識していきましょう
プルリクを構成するもの 細かいことは次の概要に書いていくので、 あまり説明的になりすぎない ように気をつけましょう
プルリクを構成するもの 概要
プルリクを構成するもの 超重要
プルリクを構成するもの レビュアーがここを見たときに プルリクの意図をパッと掴める ように整えておきましょう
プルリクを構成するもの 5W1Hに沿って書き出す、 概略図などを掲載する などしておくと最高です ref: https://kimromi.github.io/2017-08-31/pull-request.html
プルリクを構成するもの GitHubであれば テンプレートを登録 することもできるので、活用していきましょう
プルリクを構成するもの コメント
プルリクを構成するもの 基本的には議論の場 なので、どんどんコミュニケーションを 取っていきましょう
プルリクを構成するもの 最近やり始めましたが、 変更したコードの補足説明を 自分で入れる などするとわかりやすいです
プルリクを構成するもの こんな感じ
プルリクを構成するもの
プルリクを構成するもの 他にもコメント部分に スクリーンショットや 実際のレスポンスなど のエビデンスを記載しておくと丁寧でGoodですね
プルリクを構成するもの ラベル
プルリクを構成するもの 僕のチームでは プルリクの状態を管理する のに使っています
プルリクを構成するもの
プルリクを構成するもの レビュー待ちの状態・マージ可能な状態・ WIP(下書き) の状態など ラベルからパッとわかる
プルリクを構成するもの レビュー
プルリクを構成するもの レビューとは
プルリクを構成するもの コードレビュー(英: Code review)は、ソフトウェア 開発工程で見過ごされた誤りを検出・修正することを 目的としてソースコードの体系的な検査(査読)を行う 作業のこと。 ref: https://ja.wikipedia.org/wiki/コードレビュー
プルリクを構成するもの 他の人からのレビューをもらうことで 考慮漏れに気づいたり コードの品質を高めたり することができます
閑話休題 -コードコメント-
閑話休題 皆さんこのツイートをご覧に なったことはありますか?
閑話休題 ref: https://twitter.com/t_wada/status/904916106153828352
閑話休題 ref: https://www.amazon.co.jp/dp/4873115655
閑話休題 動いているコードに対しては コメントなしで何をしているかわかる ことが理想だと思います
閑話休題 逆になぜこのやり方ではダメなのか をコメントで説明できると丁寧ですね
転
プルリクについての考え方 プルリク作成 レビュー 修正コミット マージ Approve プルリク 作成者 レビュアー
プルリクに ついての考え方 -プルリク編-
プルリクについての考え方 いいプルリクとは
プルリクについての考え方 意図がしっかりと説明されており レビュワーが理解しやすいもの
プルリクについての考え方 すぐにマージされるもの
こんな状態に なっていませんか?
プルリクの概要が よくわからない
プルリクの概要がよくわからない 自分で概要を書いていて、 どんなプルリクなのかすぐに書けない ことはありませんか?
プルリクの概要がよくわからない 一言でどんなプルリクなのか 言い表せない
プルリクの概要がよくわからない これは 複数のことを一つの コミットでやっている 可能性が高いです
プルリクの概要がよくわからない プルリクのスコープが明確でない 場合に起きがちです あと一歩、というところで手を止める勇気を持ちましょう
プルリクの概要がよくわからない initial commit→ プルリク作成(タイトル・概要記入)→ コード実装
プルリクの概要がよくわからない コードを書く際にコメントから書き始める手法のように はじめにどういうことをやる プルリクなのかを決めておく とブレずにいいかもしれません
コードを書いた 後で考慮漏れに 気づく
コードを書いた後で考慮漏れに気づく コードを書き終わって レビューの際に考慮漏れに 気づいて書き直し といったことがあるかもしれません
コードを書いた後で考慮漏れに気づく 先程もお伝えしたように、 飛び込む(=コードを書く)前に考える ことが大事です
コードを書いた後で考慮漏れに気づく 僕はレビューは コード以外のことにも適用できる と思っています
コードを書いた後で考慮漏れに気づく 例えば事前に 実装方針や仕様を整理しておいて レビューをもらう ことで手戻りが自然と少なくなるでしょう
コードを書いた後で考慮漏れに気づく 極端な話 コードを書かなくても レビューはできます
コードを書いた後で考慮漏れに気づく 言葉で説明するのが難しい場合は WIPでコードを書いて 先にレビューをもらう (マージはしない)というやり方も良さそうです
プルリクに ついての考え方 -レビュー編-
プルリクについての考え方 お気づきかもしれませんが プルリクの段階ではまだ コードは世に出ていません
プルリクについての考え方 そういう意味では、プルリクは バリューの原石 だと言えるでしょう
プルリクについての考え方 率先してレビューすることで 一つでも多くのプルリクを早くマージ できるようにしていきたいですね
こんな状態に なっていませんか?
プルリクがずっと 放置されている
プルリクがずっと放置されている 食い気味にお願いして レビューしてもらいましょう…
コメントが少ない
コメントが少ない これは一概に悪いとは言えませんが… 完璧に説明がなされており 見ただけで即Approveできるものなど
コメントが少ない 例えば自分の場合だと 気になったことや気づいたこと、 わからないことなど 細かいことでもコメント するようにしています
コメントが少ない このあたりはレビューの文化を 根付かせることにも つながってきますが…
コメントが少ない
コメントが少ない レビューをされる相手も 同じ人間だということを忘れず、 心地よいコミュニケーション ができるといいですね
コードスタイルへの指 摘
コメントが少ない ひたすらつらいだけなので lint入れましょう
レビューするとき 気が重い
レビューするとき気が重い これは最近、個人的に 悩んでいたことです
レビューするとき気が重い 完璧にレビューしなきゃ!とか レビュー漏れでバグが混入したら どうしよう…とか
レビューするとき気が重い でも結局のところ 自分の力量を超える コードレビュー はできません
レビューするとき気が重い 今の自分にできる最良のレビュー ができればそれでいいのかなと思っています
閑話休題 -コードレビューについて-
閑話休題 コードレビューを取り入れれば 全てが万全の状態になるというわけではない… コードレビューにも限界はある と思っています
閑話休題 特にコードの外側、例えば 仕様やプロダクトの方向性など をコードレビューで見るのは レビューの範囲を超えてしまうのでつらいだけです
閑話休題 プロダクト・コードの 知見共有はペアプロ・モブプロ などを行うほうがよいと思います
閑話休題 この辺の考え方については こちらの記事 でより深く言及されています
閑話休題 モブプロについては過去に発表した資料 コミュニケーションから 始まるアジャイル をご覧ください
結
まとめ
まとめ プルリクは決して 怖いものではありません
まとめ プルリクを通して気持ちのいい コミュニケーションをしましょう
まとめ ただ、やり方については たった一つの正解はないと 思っていますので
まとめ 形にとらわれず、チームメンバー 全員が納得できる形に変えていく ことも大事かなと
まとめ プルリクと上手に 付き合っていくことで 生産性を高めていきましょう!
ご清聴ありがとう ございました