GitHubを使った、スピードを重視する開発手法
今回は、GitHubでの開発手法に関して説明したいと思います。
開発において、私が特に重要視している点はスピードです。
このスピードには色々な意味が込められています。
- 開発の速さ
- 決断の速さ
- 気づきの速さ
- etc
Issue
Issueの粒度は、作業内容によって変わります。
Feature(機能開発)
Featureの場合は、出来るだけ大きくする様にします。
その反面、Issue内の「やることリスト」の粒度は細かくします。
Issueの粒度が細かくなるど、閲覧するIssueの数が増え、結果的に情報が散乱してスピードダウンに繋がると考えています。
Featureの場合、Issueは大きく、タスクは小さく。 を基本として考えています。
それ以外
Feature以外の場合は、出来るだけ細かくするようにします。
Issueの内容と作業することを一致させることで、Issueの数が増えないようにします。
Commit
粒度の大小ではなく、作業単位 で区切ることを心がけています。
このコミットは、この様な変更を行った。という内容と意味が一致していれば、レビュワーがレビューしやすくなります。
また、コミットが作業単位になっていると、巻き戻しをする際に非常に楽になります。
複数の作業単位を一つのコミットにまとめてしまうと、コミットを巻き戻す際に想定以上に巻き戻り、結果として手間がかかることが多いです。
作業に入る前に、ここまで作ったらコミットする。というのを決めておくと良いでしょう。
Pullrequest
Pullrequestは、なるべく細かい単位で区切ります。
細かく区切っていると、revertの際に楽になります。
また、粒度が必要以上に大きくなると、レビュワーの負担が重くなり、結果的にレビュー自体の質も下がる傾向にあります。
実装が全て終わってなくても、WIPでPullrequestを作って、他のメンバーにアドバイスをもらうようにしましょう。
ここが自信がない、ここってどうやったらいいんだっけ?といった質問や相談をPullrequest上で聞くようにしましょう。
質問や相談をオープンにすることによって、他のメンバーからアドバイスを貰えるようになります。
通知関連
各種通知はSlackへ飛ばすようにします。
GitHubからSlackへ通知するAppは、Slack側のメンションが付かないので、気づくまで時間がかかります。
通知botを作って、Slack側のメンションも付くようにすると、開発スピードが上がります。
以下のタイミングで通知を送るといいでしょう。
- IssueやPullrequestが作成、クローズされた
- コメントがついた
- Pullrequestのレビューコメントがついた
- Pullrequestが承認された、クローズされた
- Pullrequestのreviewerに誰かがアサインされた
太古の昔に作ったのであまり良い構成ではありませんが、私が作った通知スクリプトをGitHub上で公開してるので参考までにリンクしておきます。
これを参考に、lambda上で動くようなスクリプトを作ると良いでしょう。
最近だと PullPanda のようなツールを使うと良いでしょう。
PullPandaについては こちらの記事 にまとめました。