↓この記事を読んで。いいなぁと思って。ぼんやり考えたメモ。
Y3) PullRequestはフォーマットを決めて
プルリクエストにテンプレートを用意する。というのね。
僕はあんまり書かないのでぼやーっと考えてみた。
どうして僕のチームは書かないのか？
僕のチームはプルリクエストに内容をほとんど書かない。
なんで書かないんだろう？
全員で同じストーリーのタスクをやってるから、
お互いがお互いの作業内容を知ってて、あんまり不便を感じない。
ということなのかな？
↓の記事に書いてあることを見ながら考えてみたんだけど。
Pull Request のフォーマットを決めるとレビューの効率が3倍よくなる :: Crocos Engineering Blog
こんな感じの項目？
- 何のために作るのか
- どうやって実現したのか
- どのように使われるのか
- テストしたのか
- 共有先
そうか。
これ、全部うちのチームだと「FeatureDefinition」と呼ばれるドキュメントに書いてあるやつや。
テストしたのか、とかも、ホワイトボードにタスクとして貼ってあって、
どういうテストをやったかとかも共有されて知ってるから、なくてもいいんだな。
書いた方がいいチーム
じゃあ、どんなチームだと書いた方がいいんだろう？って考えてみた。
1) リーダーがレビュー担当者
リーダーが全体を把握はしてるんだけど、実際に開発チームに入ってコードを書いたりしてない場合。
リーダーはチームのメンバーそれぞれが何をしてるかを詳細に把握することは難しいと思うので、こういったフォーマットが有用だろうなと思う。
2) チーム全員が別々の作業
チームの全員が全くお互いの作業に関与してなくて、だけどお互いにレビューをしよう、という場合。
作業を知らないので、プルリクエストにこういうフォーマットがあると効率が良さそう。
3) エンジニアが自由にプルリクエストして良い
プロダクトに対してエンジニアが自由に思いついた改善をプルリクエストして良い場合。 そのエンジニアがやってることを他の人は知らないのでプルリクエストに全部書いてあると良いんだろうなと思う。
プルリクエストの概要フォーマットについてまとめ
てことで、うちのチームでは、
- 1) 同じような内容が別のドキュメントに書いてあって、
- 2) そのドキュメントに対して全員で作業を共有しながら進めてるので、
なくても大丈夫そう。
Y4) レビューする時は git stash で今の作業を退避させる
git stash apply って始めて知った！へぇー。
stash自体あんまり使わないけど、使うときは git stash pop だったから。
退避なら、僕は作業中の内容も一旦コミットしちゃうな。
んで、作業中のコミットをそのままにしておきたくない場合は
git commit --amend 使う。色々整理したかったら後で rebase -i とかでいいかな。
Y7) コマンドでGitを使う場合、git-prompt, git-completionが便利
おー。これ便利そうー。試してみよっと。
W1) レビューする側の心理
レビュー依頼を受けてすぐレビューすると、コンテキストスイッチが発生します。 そこで、毎日この時間（昼休み明け）にレビューする、みたいに自分ルールを決めてレビューするのがよいかなと思います。
確かにー。僕は午前中と昼休み後はコーディングに集中したい時間なので、4時-6時をレビュー時間に当ててみようかなー。
W3) レビュー中のトピックブランチから次のトピックブランチを作ることの是非
そもそも、 b1のレビューが完了し、 b1 -> master へのマージが行われて b1 がリモートリポジトリから削除されると、b1 から派生した b2 はどうなるんだ？みたいな問題があります。
これはb1がマージされた後に、b2からmasterにプルリクエストだしたら、b1の後の差分だけになるはずだから大丈夫なんじゃないかな？
ブランチからブランチ切ることは結構あるけど、そういうのが沢山発生しそうだったら、開発ブランチ切って、そこに対するプルリクエストで開発を進めたり、リリースブランチを作ってみんなの開発をマージしてリリース前のテストをしたりするかなぁ。
T1) PRの状況をHubotで通知
僕もやりたいなー。
てことで
面白かった！
