難しいところです。
システムに多数の修正を加える場合、効率をよくする為には、まとめて修正した方がよいです。
あるひとまとまりの修正をひとつ実施する場合の手順。
- 考える
- 直す
- ビルド
- 配置
- テスト
直す、以降はテスト完了まで繰り返されます。
ふたつの場合の手順。
- 考える
- 直す
- ビルド
- 配置
- テスト
- 考える
- 直す
- ビルド
- 配置
- テスト
まとめてやる場合。
- ふたつ分考える
- ふたつつ分直す
- ビルド
- 配置
- ふたつ分テスト
ビルドと配置1回分にかかる時間がひとつのときとふたつのときでそれほど変わらないなら、まとめてやるほうが効率は上がります。
マッチ箱開発の場合、配置にかかる時間が見落とされがちです。
マッチ箱にバイナリを転送し、再起動させたりします。UV-EPROMを消すのに40分かかっていた頃からすれば、時間は短くなったはずですが、肥大化するバイナリはフラッシュ書き込みに時間がかかります。フラッシュ(R)が誇大広告で訴えられる日も近いでしょう。
デバッグ情報付きのバイナリならさらに数倍、デバッガ経由の起動なら、マッチ箱の起動に通常の数倍かかるのも珍しくありません。それでも、紙テープを巻き戻して再セットするのに比べれば短いはずですが。
ビルドと配置で4～5分かかる場合、修正～テストのターンアラウンドタイムは最低でも5分かかるということです。間抜けな修正でも5分。ロジックの根本的なバグを直すのにも5分。これはバグ修正の民主主義あるいは、バグ平等の原理と呼ばれます。
まとめて直す場合、間抜けな修正と一緒にロジックのバグを直せば、間抜けな修正のための5分は見かけ上短縮できるのです。
作文の校正や推敲と同じと考えたらどうでしょうか。原稿用紙に書いた文章の構成を変えて書き直すのと、誤字脱字を直すのは、1枚当り４００字なら同じ時間がかかります。それならば、文章の構成を正しながら、誤字脱字を修正すればよいのです。
ビルドと配置にかかる時間の短縮には限界があります。なので、その回数を減らすことに頭を使った方がよいと思われます。たとえばひとつの修正をおこなうのに、ビルドと配置を10回も繰り返しているような開発者が居たら、代わりに1時間よく考えさせる癖をつけさせた方が良いです。ビルドと配置の繰り返し自体の効率化は手先を鍛えるだけですが、1時間の熟考は脳みそを鍛えます。
最初に難しい問題だと書いたのは、これで話が終わらないからです。
間抜けな修正だと思っていた修正が実は他に影響を与えることがあります。もしまとめて直す場合にはそこを良く考えてリポジトリへの登録は分けて実施した方がよいかもしれません。修正を巻き戻すにも、まとめてコミットされているといろいろ厄介です。
効率的な開発のためには、ビルドと配置にかかるコストについてもっとスポットライトをあてるべきだと思うのですが、make[enter]には不思議な安心感がともなうためか、あまりうるさく言う人が少ない気がします。googleの妙な差分バイナリ配信の話題くらいでしょうか。
Chromeがバイナリ差分で新アルゴリズム実装
http://www.atmarkit.co.jp/news/200907/17/chrome.html
これもフィールドでの話であって開発現場に福音をもたらすものではなさそうです。
ベテランさんはビルドを繰り返すこと自体に眉をひそめます。ターンアラウンドタイムが何十分だった頃を体で覚えているので、効率は高止まりしているという感覚に捕らわれているのかもしれません。
コメント