NaITE #30 プルリクとの上手な付き合い方

1. プルリクとの
上手な付き合い方
Event /
NaITE #30
プルリクとの上手な付き合い方
and もくもく会
Date / 2019-03-23 (Sat)
Presenter / Naoto Teshima (tosite / まおちゃ)

2. はじめまして

3. わたし

5. GMOペパボ
ホスティング事業部
ムームードメイングループ所属
手島 尚人
インターネット上ではまおちゃという名前で
バーチャルJKやってます

6. 最近はRuby on Railsや
Laravelなどを書いています

7. Twitter : @mao_sum
Blog : tosite.work
NaITE・JaSST九州・
PHPカンファレンス福岡
の実行委員もやっています

8. おもしろ自己紹介

9. ref: https://kimromi.hatenablog.jp/entry/2019/02/23/225740

10. はい

11. はじめに

12. 皆さん、プルリクを
作っていますか？

13. Git全盛期の昨今
名前だけでも聞いたことが
あるかと思います

14. 特にチーム開発を行う場合、
プロダクトの品質を担保するためにも
プルリク→コードレビューの流れ
は必要不可欠かなと思います

15. そんな中で、こんなプルリクを
見たことはありませんか？

18. ^q^

19. おおよそニンゲンには
検知不可能な変更量

20. そしてこんなコミットを
積んでいませんか？

22. ^q^

23. 何が変わったのか
わからない

24. 今日は
よいプルリクを作るには？
プルリクとの上手な付き合い方
を実体験からお話ししていきます

25. 参考文献：イシューからはじめよ

26. 起

27. 知的生産者
としての心構え

28. 知的生産者としての心構え
ってなんだと思いますか？

29. 知的生産者としての心構え
最小限の時間で
最大限の生産性を出す
方法を考えていくことだと思います

30. 知的生産者としての心構え
そのためには
犬の道
から脱却しなくてはなりません

31. 知的生産者としての心構え
犬の道とは

32. 知的生産者としての心構え
一心不乱に仕事を
することで問題解決
していこうとする姿勢のこと

33. 知的生産者としての心構え

34. 知的生産者としての心構え

35. 知的生産者としての心構え
限られた時間・リソースの中で効率を高めるには
課題の本質を見抜き
解の質を高めていく
ことが必要不可欠です

36. 知的生産者としての心構え
特にありがちなのは、
丁寧にやりすぎた結果
膨大な時間を費やしてしまう
ことです

37. 知的生産者としての心構え
もちろん丁寧さは大切ですが、それ以上に
イテレーションの回転数・スピード感
を上げていくことが最重要です

38. 知的生産者としての心構え
考える 答えを出す
答えを出す考える 答えを出す考える 答えを出す考える
時間

39. 知的生産者としての心構え
考える 答えを出す
答えを出す考える 答えを出す考える 答えを出す考える
時間

40. 知的生産者としての心構え
そのためにも
Issueやプルリクと
上手に付き合いつつ
犬の道から脱却していきましょう

41. 閑話休題
-海の話-

42. 閑話休題
突然ですが皆さん、海に
泳ぎに行ったらどうしますか？

43. 閑話休題
いきなり着替えもせずに海に入る、
ということはしないと思います

44. 閑話休題
まずは着替えて、日焼け止めを塗って、準備運動して…
事前の準備を済ませてから
泳ぎますよね

45. 閑話休題
何かを作るときにも同じで、
いきなり飛び込まずに
最初に考える時間を作る
ことが大事だと僕は思います

46. 閑話休題
そもそも何の問題を解決するためなのか
どういった問題があるのかなど、やるべきことを
大きいことから徐々に細かく分解
していくといいです

47. 閑話休題
このあたりの詳しい話について興味のある方は
イシューからはじめよ
をご覧ください

48. ポイントは
悩まないこと

49. ポイントは悩まないこと
皆さん、悩むことと考えることは
どう違うと思いますか？

50. ポイントは悩まないこと
アイスブレイク3分：
自己紹介
話し合う

51. ポイントは悩まないこと
悩む

52. ポイントは悩まないこと
決めかねたり解決の方法が
見いだせなかったりして、心を痛める。
思いわずらう。
goo辞書： https://dictionary.goo.ne.jp/jn/165175/meaning/m0u/%E6%82%A9%E3%82%80/

53. ポイントは悩まないこと
考える

54. ポイントは悩まないこと
知識や経験などに基づいて、
筋道を立てて頭を働かせる。
goo辞書： https://dictionary.goo.ne.jp/jn/47607/meaning/m0u/%E8%80%83%E3%81%88%E3%82%8B/

55. ポイントは悩まないこと
考えても答えが出ないことに
思いを巡らせることが「悩む」
具体的に解決への道筋を
組み立てることが「考える」

56. ポイントは悩まないこと
僕自身悩むこともそれはそれで好きではありますが…
10分考えて分からないことは
悩んでいる可能性が高いです
悩むことをやめて聞こう・相談しよう

57. ポイントは悩まないこと
でも、誰かに相談された場合に、
思考の順序や道筋が見えない
と相談を受ける側もよくわからないことがあります…

58. フレームワークを
使おう

59. フレームワークを使おう
考えを整理するにあたって、
フレームワークの力を借りる
ことはとても有益です

60. フレームワークを使おう
5W1Hやなぜなぜ分析
といった言葉を耳にしたことはありませんか？

61. フレームワークを使おう
個人的にオススメなのは
マインドマップ
です

62. フレームワークを使おう

63. フレームワークを使おう
思考の過程が可視化される
ため、他の人が見たときにわかりやすいと思います

64. 承

65. プルリクを
構成するもの

66. プルリクを構成するもの

67. プルリクを構成するもの
コミット

68. プルリクを構成するもの
どんな作業をしたのかが一言で言える
ようなコミットがわかりやすいです

69. プルリクを構成するもの
あとでレビューを受けるときに
コミット単位で見られる
ことを考えておこう

70. プルリクを構成するもの
タイトル

71. プルリクを構成するもの
例えばリリースして半年経過して、
過去のプルリクを検索する、
といったシチュエーションを
想像していただきたいのですが

72. プルリクを構成するもの

73. プルリクを構成するもの
こちらとこちら、
どちらが見やすいですか？

74. プルリクを構成するもの
後から探しやすいタイトル
をつけることを意識していきましょう

75. プルリクを構成するもの
細かいことは次の概要に書いていくので、
あまり説明的になりすぎない
ように気をつけましょう

76. プルリクを構成するもの
概要

77. プルリクを構成するもの
超重要

78. プルリクを構成するもの
レビュアーがここを見たときに
プルリクの意図をパッと掴める
ように整えておきましょう

79. プルリクを構成するもの
5W1Hに沿って書き出す、
概略図などを掲載する
などしておくと最高です
ref: https://kimromi.github.io/2017-08-31/pull-request.html

80. プルリクを構成するもの
GitHubであれば
テンプレートを登録
することもできるので、活用していきましょう

81. プルリクを構成するもの
コメント

82. プルリクを構成するもの
基本的には議論の場
なので、どんどんコミュニケーションを
取っていきましょう

83. プルリクを構成するもの
最近やり始めましたが、
変更したコードの補足説明を
自分で入れる
などするとわかりやすいです

84. プルリクを構成するもの
こんな感じ

85. プルリクを構成するもの

86. プルリクを構成するもの
他にもコメント部分に
スクリーンショットや
実際のレスポンスなど
のエビデンスを記載しておくと丁寧でGoodですね

87. プルリクを構成するもの
ラベル

88. プルリクを構成するもの
僕のチームでは
プルリクの状態を管理する
のに使っています

89. プルリクを構成するもの

90. プルリクを構成するもの
レビュー待ちの状態・マージ可能な状態・
WIP（下書き）の状態など
ラベルからパッとわかる

91. プルリクを構成するもの
レビュー

92. プルリクを構成するもの
レビューとは

93. プルリクを構成するもの
コードレビュー（英: Code review）は、ソフトウェア
開発工程で見過ごされた誤りを検出・修正することを
目的としてソースコードの体系的な検査（査読）を行う
作業のこと。
ref: https://ja.wikipedia.org/wiki/コードレビュー

94. プルリクを構成するもの
他の人からのレビューをもらうことで
考慮漏れに気づいたり
コードの品質を高めたり
することができます

95. 閑話休題
-コードコメント-

96. 閑話休題
皆さんこのツイートをご覧に
なったことはありますか？

97. 閑話休題
ref: https://twitter.com/t_wada/status/904916106153828352

98. 閑話休題
ref: https://www.amazon.co.jp/dp/4873115655

99. 閑話休題
動いているコードに対しては
コメントなしで何をしているかわかる
ことが理想だと思います

100. 閑話休題
逆になぜこのやり方ではダメなのか
をコメントで説明できると丁寧ですね

101. 転

102. プルリクについての考え方
プルリク作成
レビュー
修正コミット マージ
Approve
プルリク
作成者
レビュアー

103. プルリクに
ついての考え方
-プルリク編-

104. プルリクについての考え方
いいプルリクとは

105. プルリクについての考え方
意図がしっかりと説明されており
レビュワーが理解しやすいもの

106. プルリクについての考え方
すぐにマージされるもの

107. こんな状態に
なっていませんか？

108. プルリクの概要が
よくわからない

109. プルリクの概要がよくわからない
自分で概要を書いていて、
どんなプルリクなのかすぐに書けない
ことはありませんか？

110. プルリクの概要がよくわからない
一言でどんなプルリクなのか
言い表せない

111. プルリクの概要がよくわからない
これは
複数のことを一つの
コミットでやっている
可能性が高いです

112. プルリクの概要がよくわからない
プルリクのスコープが明確でない
場合に起きがちです
あと一歩、というところで手を止める勇気を持ちましょう

113. プルリクの概要がよくわからない
initial commit→
プルリク作成（タイトル・概要記入）→
コード実装

114. プルリクの概要がよくわからない
コードを書く際にコメントから書き始める手法のように
はじめにどういうことをやる
プルリクなのかを決めておく
とブレずにいいかもしれません

115. コードを書いた
後で考慮漏れに
気づく

116. コードを書いた後で考慮漏れに気づく
コードを書き終わって
レビューの際に考慮漏れに
気づいて書き直し
といったことがあるかもしれません

117. コードを書いた後で考慮漏れに気づく
先程もお伝えしたように、
飛び込む（＝コードを書く）前に考える
ことが大事です

118. コードを書いた後で考慮漏れに気づく
僕はレビューは
コード以外のことにも適用できる
と思っています

119. コードを書いた後で考慮漏れに気づく
例えば事前に
実装方針や仕様を整理しておいて
レビューをもらう
ことで手戻りが自然と少なくなるでしょう

120. コードを書いた後で考慮漏れに気づく
極端な話
コードを書かなくても
レビューはできます

121. コードを書いた後で考慮漏れに気づく
言葉で説明するのが難しい場合は
WIPでコードを書いて
先にレビューをもらう
（マージはしない）というやり方も良さそうです

122. プルリクに
ついての考え方
-レビュー編-

123. プルリクについての考え方
お気づきかもしれませんが
プルリクの段階ではまだ
コードは世に出ていません

124. プルリクについての考え方
そういう意味では、プルリクは
バリューの原石
だと言えるでしょう

125. プルリクについての考え方
率先してレビューすることで
一つでも多くのプルリクを早くマージ
できるようにしていきたいですね

126. こんな状態に
なっていませんか？

127. プルリクがずっと
放置されている

128. プルリクがずっと放置されている
食い気味にお願いして
レビューしてもらいましょう…

129. コメントが少ない

130. コメントが少ない
これは一概に悪いとは言えませんが…
完璧に説明がなされており
見ただけで即Approveできるものなど

131. コメントが少ない
例えば自分の場合だと
気になったことや気づいたこと、
わからないことなど
細かいことでもコメント
するようにしています

132. コメントが少ない
このあたりはレビューの文化を
根付かせることにも
つながってきますが…

133. コメントが少ない

134. コメントが少ない
レビューをされる相手も
同じ人間だということを忘れず、
心地よいコミュニケーション
ができるといいですね

135. コードスタイルへの指
摘

136. コメントが少ない
ひたすらつらいだけなので
lint入れましょう

137. レビューするとき
気が重い

138. レビューするとき気が重い
これは最近、個人的に
悩んでいたことです

139. レビューするとき気が重い
完璧にレビューしなきゃ！とか
レビュー漏れでバグが混入したら
どうしよう…とか

140. レビューするとき気が重い
でも結局のところ
自分の力量を超える
コードレビュー
はできません

141. レビューするとき気が重い
今の自分にできる最良のレビュー
ができればそれでいいのかなと思っています

142. 閑話休題
-コードレビューについて-

143. 閑話休題
コードレビューを取り入れれば
全てが万全の状態になるというわけではない…
コードレビューにも限界はある
と思っています

144. 閑話休題
特にコードの外側、例えば
仕様やプロダクトの方向性など
をコードレビューで見るのは
レビューの範囲を超えてしまうのでつらいだけです

145. 閑話休題
プロダクト・コードの
知見共有はペアプロ・モブプロ
などを行うほうがよいと思います

146. 閑話休題
この辺の考え方については
こちらの記事
でより深く言及されています

147. 閑話休題
モブプロについては過去に発表した資料
コミュニケーションから
始まるアジャイル
をご覧ください

148. 結

149. まとめ

150. まとめ
プルリクは決して
怖いものではありません

151. まとめ
プルリクを通して気持ちのいい
コミュニケーションをしましょう

152. まとめ
ただ、やり方については
たった一つの正解はないと
思っていますので

153. まとめ
形にとらわれず、チームメンバー
全員が納得できる形に変えていく
ことも大事かなと

154. まとめ
プルリクと上手に
付き合っていくことで
生産性を高めていきましょう！

155. ご清聴ありがとう
ございました