2011/10/17

下流から変える

自分の開発過程でありがちなこと

1. Aという要素について、すげー改善のアイディアを思いついた。
2. 興奮して実装してみているうちに、その変更によってBという要素も変えないとならないと気づいた。
3. Bを変えると一緒にCとDも変えないとならないなあ。全部変えてテストするまでコミットできないなあ。
4. 変更の作業量が2日を超えて、 だんだん萎えてきた。
5. masterブランチの方でバグ対応やらなんやら。だんだん元アイディアのトピックブランチが遅れてゆく。
6. 久々にブランチ切り替えてとりあえずrebaseするんだけど、さて、どこまでやったんだか思い出せない…

3の段階で、とりあえず動かして有効なことを確認したら、 実際のコミットは逆方向にやると良いのだ。つまり、

1. 最下流のCとDを、現状のBでも変更したB'でも動作するように直してコミット。
2. 次にBを、現状のAでも変更したA'でも動作するように直してコミット。
3. 最後にAの変更をコミット。

これだと、常に動いている状態で小刻みにコミットできる。

下流の変更を、上流からの二種類の情報形式 (データ構造なりAPIなり) に対応させなきゃ ならないのは若干面倒ではあるけれど、上流も複数ある場合には 後で片方づつ変更できるから便利だし、うまい対応を考えてるうちに よりよい抽象化を思いつくこともある。

ただまあ、最下流の変更が一見何をしたいのかわからないような場合もあって、 共同開発してるときにはそのパッチの有効性について説得するのが難しいこともある。 個人プロジェクトだとわりと自由にできるんだが。

このパターンによく出会う気がするのでメモしておく。

Tag: Programming