読者です 読者をやめる 読者になる 読者になる

ゆずめも

私による私のためのメモ的なブログです。主に勉強した事について書いてます。

自分の環境に最適なプルリクを考えてる話

会社でgitbucketサーバを立てる許可が出たので、環境を整えたりしながら運用について考えてる。 そこでプルリクエストが人によって書き方がバラバラだと、読む方はもちろん書く方も辛いな?と思ったので、フォーマットを作ろうと思って書き始めた。

まだ実際に運用はできてないけど、今後この方針でやっていきたいなとは思ってる。

TL;DR

  • 色々参考にする
  • 欲しい情報を洗い出す
  • フォーマットを考える
  • 運用ルールを決める
  • 布教する

いろんなものを参考にして、自分たちに必要な情報をフォーマットにしたがって作ることで、考えることを減らして属人性を無くしたい。最終的には楽をしてチームをハッピーに。

参考にする

現代においてプルリク開発は当たり前なので、先人たちがやってることから良さそうな所をインスパイアされる。

それぞれ気になった所とか差分で

参考1

techlife.cookpad.com

  • 目的
    • 実装の目的を1行くらいで
  • やったこと
    • 実装の内容を箇条書きで書く

画像とか使って変更点をわかりやすくしてていいなと思った。

参考2

qiita.com

  • 欲しいフィードバックを明確にする
  • ユーザを指定する場合(@yuzuみたいな)はなぜmentionしたのかを書く

参考3

blog.mmmcorp.co.jp

プルリクエスト作成時に書かなければいけない情報が多すぎると、プルリクするのが嫌になってしまいますし、少なすぎるとレビューの効率が悪くなったり、実装抜けを見抜けなかったりすることがあると思います。

まさにその通りだと思う。特に自分は怠惰担当を自称するくらい面倒くさがりなので辛いと思ったら続かない。仕事だから書くけど…というモチベーションで開発するのはしんどいので、会社で?チームで?妥協点を探すのがいいと思う。

欲しい情報

まずはプルリクエストで欲しい情報を洗い出してみる。

  • 概要
    • 1行くらいで
  • 該当issue
    • Redmineが使われているので、該当チケットへのリンク
  • 変更点
    • 何を作ったのか、何を変えたのかを箇条書きで
    • 技術的な内容もここに
    • 画面変えたらスクショ撮って貼るの良さそう
  • レビューポイント
    • レビューして欲しい所を書く
    • 「ここの実装どう思う?」「○○の部分こんな感じでいいですか?」
  • メンション
    • なぜメンションしたのか

レビューポイントとメンションは同じにしてもいい気がする。 誰に、何を、確認してほしいのかってのが明確になるんじゃないかなと思うけど、そこらへんはやってみてKPTみたいな振り返りの機会で考えたい。

フォーマットを考える

# プルリク概要

ここに概要を1行くらいで書く

- 関係のあるRedmineのチケットを
- 箇条書きで書いてリンク付ける

# 変更点

- ○○を△△にした
- □□を使って、××を実現
- のように箇条書きで

# レビューのポイント

- □□を導入してみたので導入部分について特に @yuzu に意見をいただきたいです
- とかこんな感じ想定

# メンション

@yuzu さん
□□のhoge部分が気になるのですが、うまい実装ありますか?

@team
□□初導入のため一度目を通すようにお願いします

フォーマットもgitbucketに置いて変更リクエストとか出せるようにするのもいいかもね

運用ルール

  • できるだけ絵文字使う
  • [WIP]にはレビューして欲しい所を書く
  • レビューはするけど、マージはしない
  • その日の作業その日の内に
  • etc...

絵文字を使う

会社のslackで絵文字使う人がいて、その人の発言見てると明るい感じになっていいなと思ったので、積極的に絵文字使っていくほうがレビューする人も、レビューされる人も、斜め読みする人も気分いいと思う。*1

✨✨✨✨✨ LGTM!!!✨✨✨✨✨

このくらいのテンションで使うといいかなと。

[WIP]にはレビューして欲しい所を絶対に書く

Work in Progressにはレビューして欲しいポイントを絶対に書く!

どこをレビューして欲しいのかって考えるのめんどくさくない?

レビューはするけど、マージはしない

フォーマットに従っていないプルリクはマージしない。

フォーマット作る意味がなくなってしまうので書くことを強制する。
ただ厳しすぎるのも…と思うので、レビューくらいはしてやってもいいのではと思わなくもない。結局マージされないんだから最初からちゃんと書こうって方向に持っていきたい。

その日の作業その日の内に

1つ1つのプルリクを小さく保ちたい。なのでその日の汚れその日のうちにその日の作業は(できれば)その日のうちに。

時間が開くと変更点も大きくなってレビューするのも大変だし。。。

布教する

いろいろ考えても使われないと意味がない!
なので手間と得られるメリットの折り合いを付けれる部分を運用しつつ探って行くのがいいかな。 開発文化を作るって思いながら長い目で考えていこうと思う。

まとめ

新卒入社で偉そうなこと言える立場ではないけれど、後輩と開発環境よくするという約束をしてしまったので、わかってないやつが、わかってないなりに頑張ってる。

以下、苦しんでる様子

*1:意識して絵文字使うようにしてるけどガラケー時代から絵文字使うの苦手だから、カジュアルに絵文字使ってる人から見ると使い方おかしいんだろうな