※『「単体テストが面倒くさい」に立ち向かう ―5つの弾丸』のおまけとして追記しようと思ったのですが、少し長くなったので単独記事としました。
現場から
実装できた。
さあ、ビルド!
待たされる。
単体テストまたNG。
直して再試行。
ビルド待たされる。
テストチームから不具合の指摘。
修正した。
ビルド(+単体テスト実行)が終わるまでお待ちください。
改善したい
ビルド時間が長いと開発のペースが乱されます。
集中力、意欲が削がれます。
戻すのに時間がかかります。
できればテンポよく進めていきたいものです。
改善しましょう
プロジェクトが構造的なリファクタリングを許す段階にあり、自分が改善を提案できる立場にあるなら1、ビルド高速化を積極的に検討しましょう。
たとえば、
- 開発PCのスペック(メモリ/CPU)を上げる。
- 私の開発環境ははこれでかなり改善しました。ソースコード検索も速くなります。
- メモリを8GBから16GBに上げることで、7分が2分に短縮されたという改善例があります。
- なんとなく、あるいはテストのためだけに public にするのをやめる
- ソースプロジェクト(ビルド単位)を分ける
- デッドコードを削除する
- コードクローンを除去する
- 埋め込みリソースを多用している場合は外部リソース化を検討する。
- ビルドツールを並列実行させる(MSBuild 例)
- ビルド高速化ツールを導入する
- IncrediBuild は無料版でも効果を発揮しました。古いIDEですが、特にVS2008では効果があり、6分かかっていたのが2分弱になりました。
- 実行時間の長い単体テストを見直す
- ソースコードのある作業フォルダをアンチウィルスソフトの検疫から除外する
など。
そこにコストを費やす価値は十分にあります(後できっとおつりがきます)。
プログラマを増員するよりも、今いるプログラマの力を無駄にしない工夫が先でしょう。
-
すべてのプログラマがそうあるとよいのですが。 ↩