しばらく前に git を使い始めた。最初の頃はコツがつかめず、しょっちゅうパニックに陥っていたが、慣れるとこれほど便利なものはない。これまでブランチを切るという作業はヘビーなものだったが、git でローカルにリポジトリを持っているとこれがタダみたいなものだ。手元にじゃんじゃん開発用のブランチを作って、じゃんじゃん捨てればよい。すべてはローカルでの出来事だから、本家のリポジトリの履歴が汚れることもない。
などなど、 今さら git をほめたたえても仕方がない。今回、書こうと思ったのは、チーム単位での開発ブランチは役立つのか？というテーマである。率直にいうと私は否定的である。小さなチームならともかく、ある程度大きなチームではうまくいかないと思っている。というか、うまくいかなかった。
まず第一にコミュニケーションのコストがある。「この機能は開発ブランチXでやるんで、よろしく」とメールを投げても、メンバーが数人いれば一人くらい読まない人がいるかもしれない。読まなかったメンバーがメインのブランチで開発を続行すると混乱が生じる。このくらい周知するのは簡単そうだが、離れた場所にメンバーがいたりすると、案外むずかしいものだ。
同じコードをいじっている他のチームもいるとさらに話はややこしくなる。自分のチームが１週間くらい開発ブランチにこもって機能を作っているうちに別のチームが大規模なリファクタリングをメインのブランチで敢行して、マージがめちゃくちゃ難しくなっているかもしれない。あるいは、もっと悪ければ、自分のチームが使おうとしていたコードが消されちゃっているかもしれないのだ。
というわけで、ある程度大きなチームでは、メインのブランチで開発をするのが混乱が少なくていいと思う。継続ビルドを走らせたりするのもその方が楽だし、ワークフローもシンプルだ。
じゃあどうやって実験的な機能を実装すればいいのだろうか。C++ だと #ifdef を使うという手がある。が、これはできるだけ避けたい。ビルドの仕方が複数あると、ビルドが壊れやすくなるし、テストも大変だ。
もっと手軽なのはコマンドラインオプションや設定ファイルで実験的機能を有効・無効にするという方法だ。デフォルト動作ではこれまで通り動くようにしておいて、起動時にコマンドラインオプションで有効にしたときだけ新機能が動くという具合だ。新機能が十分に安定したら、コマンドラインオプションを取り除いて、不要になった古いコードを捨てる。新機能が失敗したら、潔くコードを削除する。削除しやすいように作っておくのが吉である。
と、ここまで書いてみて、ずいぶん平凡なことを書いているような気がしてきた。が、平凡なことというのは案外気づかなかったりするもので、私はこの方法を最初に知ったときは結構感動したのを覚えている。コマンドラインオプション、あなどりがたしである。