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
[2024/10/25]CREの守護者たち 〜DevOps×シフトレフト - 俺またプロダクト救っちゃいました!?〜
tosite
0
360
[2024/07/11]Guardianとして生まれ変わった俺は攻めと守りの運用で無双する 〜守りの天才が考える、攻めの運用術〜
tosite
0
770
[2024/04/23]tbls活用事例 〜 ビューポイントから データベースを整理してみた話 〜
tosite
0
360
[2023/09/15]ER図クエスト 過ぎ去りしドキュメントを求めて 〜複雑性に眠る秘宝〜
tosite
0
580
[2022/12/07]この素晴らしいアプリケーションにテストコードを
tosite
0
39
[2022/03/25]コミュニティから学ぶエンジニアリング
tosite
0
330
[2021/12/16]テストコードのないレガシーアプリケーションとの向き合い方
tosite
0
49
[2019/07/27]はじめよう、ニコカレ!
tosite
0
32
[2018-12-12]ティファニーで転職を〜夏の日の2018〜
tosite
0
37
Other Decks in Technology
See All in Technology
Why App Signing Matters for Your Android Apps - Android Bangkok Conference 2024
akexorcist
0
130
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
1.3k
テストコード品質を高めるためにMutation Testingライブラリ・Strykerを実戦導入してみた話
ysknsid25
7
2.7k
CysharpのOSS群から見るModern C#の現在地
neuecc
2
3.5k
rootlessコンテナのすゝめ - 研究室サーバーでもできる安全なコンテナ管理
kitsuya0828
3
390
オープンソースAIとは何か? --「オープンソースAIの定義 v1.0」詳細解説
shujisado
10
1.3k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
0
110
プロダクト活用度で見えた真実 ホリゾンタルSaaSでの顧客解像度の高め方
tadaken3
0
200
個人でもIAM Identity Centerを使おう!(アクセス管理編)
ryder472
4
240
誰も全体を知らない ~ ロールの垣根を超えて引き上げる開発生産性 / Boosting Development Productivity Across Roles
kakehashi
2
230
Python(PYNQ)がテーマのAMD主催のFPGAコンテストに参加してきた
iotengineer22
0
530
Platform Engineering for Software Developers and Architects
syntasso
1
520
Featured
See All Featured
Being A Developer After 40
akosma
87
590k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
840
How STYLIGHT went responsive
nonsquared
95
5.2k
Designing for Performance
lara
604
68k
A designer walks into a library…
pauljervisheath
204
24k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
Building a Scalable Design System with Sketch
lauravandoore
459
33k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
The Art of Programming - Codeland 2020
erikaheidi
52
13k
Done Done
chrislema
181
16k
Measuring & Analyzing Core Web Vitals
bluesmoon
4
130
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入れましょう
レビューするとき 気が重い
レビューするとき気が重い これは最近、個人的に 悩んでいたことです
レビューするとき気が重い 完璧にレビューしなきゃ!とか レビュー漏れでバグが混入したら どうしよう…とか
レビューするとき気が重い でも結局のところ 自分の力量を超える コードレビュー はできません
レビューするとき気が重い 今の自分にできる最良のレビュー ができればそれでいいのかなと思っています
閑話休題 -コードレビューについて-
閑話休題 コードレビューを取り入れれば 全てが万全の状態になるというわけではない… コードレビューにも限界はある と思っています
閑話休題 特にコードの外側、例えば 仕様やプロダクトの方向性など をコードレビューで見るのは レビューの範囲を超えてしまうのでつらいだけです
閑話休題 プロダクト・コードの 知見共有はペアプロ・モブプロ などを行うほうがよいと思います
閑話休題 この辺の考え方については こちらの記事 でより深く言及されています
閑話休題 モブプロについては過去に発表した資料 コミュニケーションから 始まるアジャイル をご覧ください
結
まとめ
まとめ プルリクは決して 怖いものではありません
まとめ プルリクを通して気持ちのいい コミュニケーションをしましょう
まとめ ただ、やり方については たった一つの正解はないと 思っていますので
まとめ 形にとらわれず、チームメンバー 全員が納得できる形に変えていく ことも大事かなと
まとめ プルリクと上手に 付き合っていくことで 生産性を高めていきましょう!
ご清聴ありがとう ございました