コミットログに開発を駆動させよう

この記事はGit Advent Calendar 2013の6日目の記事です。 前日は @DQNEO さんの「Gitが連想配列記憶装置であることを低レイヤーな操作を通して体感しよう!」でした。

はじめに

実は僕は昨年のGit Advent Calendarで次のような記事を書きました。

rebaseのすすめ

この記事はこれの続編です。上記記事をご存知ない方はまずはそちらをお読みください。

コミットログに開発を駆動させるということ

この業界にはxDDと呼ばれるプラクティスが多いですね。 TDD(テスト駆動開発)、BDD(振る舞い駆動開発)、ATDD(受け入れテスト駆動開発)、TiDD(チケット駆動開発)など。

僕はGitのコミットログも開発を駆動する力があるのではないかと思っており、今回はそれについてご紹介したいと思います。コミットログ駆動開発(CDD)とでも名付けましょうか?笑

理想のコミットログをはじめに考える

ある機能を実装する際にまずはそれを様々な具体的な作業に要素分解すると思います。クラス/モジュール設計、DBスキーマ設計、UI設計、DBへのアクセスと問い合わせ処理の実装、ビジネスロジック、フロントエンドのインタラクションの実装等、ひとつの機能は複数の小さな作業の組み合わせの上に成り立っており、通常それらは別々にコミットを作成します。

そのコミットログの理想の形を最初に考えることを意識するとその「理想のコミットログ」は開発を駆動する存在となり、あとは各コミットに具体的な差分を追加していくという作業になると考えています。

WIP PR というプラクティス

先日行われたDevLove現場甲子園という勉強会で次のようなLTをさせていただきました。

僕の職場ではGithubのPull Request(PR)の仕組みを利用して開発を進めているのですが、ここで紹介しているのは作業中(Work In Progress)の状態でPRを出してしまうWIP PRというプラクティスです。

WIP PRは

  • PRのタイトルに[WIP]という接頭辞をつける
  • PRの本文に作業中であることを明記する
  • PRの本文に残っている作業を記載する

というシンプルなルールで運用できるのですが、その効果は非常に大きいと感じています。

特に残りの作業を記載することの効果は絶大で、これによりひとつずつ順番に積み上げていくという作業のやり方ではなく、まず全体を俯瞰して何と何と何を完了すればその一連の作業が終わったと言えるのかを最初に定義してしまう*1という癖がつきます。

「この変更はどのコミットに含めるべき?」と常に問いかける

WIP PRを実践するとコミットもリズミカルにできるようになります。最初に作業内容を定義しており、それに適したコミットをどんどん作成することができるからです。

ただ、当然作業を進めていくうちに、テストが落ちたり、直前まで動いていた機能が動かなくなったりして、コードを変更する必要が生じることがあります。そのときに「その変更は本来どのコミットでするべきだったのか?」という問いかけましょう。これこそがコミットログに駆動される開発のあり方です。

それが仮に以前の別のコミットに含まれるべきだったもので考慮が漏れていただけだったのであればそのコミットに含めてしまいましょう。

もしもそれが最初に考えた「理想のコミットログ」に含まれていない変更だったのであれば新たに適切な順序で新しいコミットを作成しましょう。

「理想のコミットログ」が変化し新しいコミットが作成されるのは、まるでTDDにおいて新しいテストケースを追加することに似ています。現状のテストだけでは要件を満たせないときにRedになる新たなテストを書くのと同様、現状のコミットログで要件を満たせないときには新たにコミットを作成すればいいのです。

Gitのコミットはリモートリポジトリに同期するまでは何度でも変更できます。何度rebaseしても構いません。何も恐れる必要はないでしょう。

バトンタッチ

次は taczge さんです。 よろしくお願いします。

*1:スクラムでは「Doneの定義」などと呼びますね。