GitHubを使った、スピードを重視する開発手法

2019-05-07GitHub

今回は、GitHubでの開発手法に関して説明したいと思います。

開発において、私が特に重要視している点はスピードです。

このスピードには色々な意味が込められています。

Issue

Issueの粒度は、作業内容によって変わります。

Featureの場合は、出来るだけ大きくする様にします。

その反面、Issue内の「やることリスト」の粒度は細かくします。

Issueの粒度が細かくなるど、閲覧するIssueの数が増え、結果的に情報が散乱してスピードダウンに繋がると考えています。

Featureの場合、Issueは大きく、タスクは小さく。 を基本として考えています。

Feature以外の場合は、出来るだけ細かくするようにします。

Issueの内容と作業することを一致させることで、Issueの数が増えないようにします。

粒度の大小ではなく、作業単位 で区切ることを心がけています。

このコミットは、この様な変更を行った。という内容と意味が一致していれば、レビュワーがレビューしやすくなります。

また、コミットが作業単位になっていると、巻き戻しをする際に非常に楽になります。

複数の作業単位を一つのコミットにまとめてしまうと、コミットを巻き戻す際に想定以上に巻き戻り、結果として手間がかかることが多いです。

作業に入る前に、ここまで作ったらコミットする。というのを決めておくと良いでしょう。

Pullrequestは、なるべく細かい単位で区切ります。

細かく区切っていると、revertの際に楽になります。

また、粒度が必要以上に大きくなると、レビュワーの負担が重くなり、結果的にレビュー自体の質も下がる傾向にあります。

実装が全て終わってなくても、WIPでPullrequestを作って、他のメンバーにアドバイスをもらうようにしましょう。

ここが自信がない、ここってどうやったらいいんだっけ？といった質問や相談をPullrequest上で聞くようにしましょう。

質問や相談をオープンにすることによって、他のメンバーからアドバイスを貰えるようになります。

各種通知はSlackへ飛ばすようにします。

GitHubからSlackへ通知するAppは、Slack側のメンションが付かないので、気づくまで時間がかかります。

通知botを作って、Slack側のメンションも付くようにすると、開発スピードが上がります。

以下のタイミングで通知を送るといいでしょう。

太古の昔に作ったのであまり良い構成ではありませんが、私が作った通知スクリプトをGitHub上で公開してるので参考までにリンクしておきます。

これを参考に、lambda上で動くようなスクリプトを作ると良いでしょう。

最近だと PullPanda のようなツールを使うと良いでしょう。

PullPandaについてはこちらの記事にまとめました。