プログラマの思索

ソフトウェア開発の初期コストと保守コストのグラフの良い記事があったのでメモ。

Miros?aw Jedynak - professional .NET blog: 6 steps to successful Continuous Integration

(引用)それぞれの方法について，初期コストと維持コストの対比が提示されているところが印象的。感覚的だけど，このグラフは同意できる。

6つの観点の比較だが、経験的に非常に共感する。
この記事の主張は、「統合ビルドは重要！」の一言。

1. Use source code repository

(引用)「SCM使えって当たり前だろ」と思いつつも，未だにOSのファイル共有だけってのもあるからなぁ。現実は小説より奇なりダ。
これは鉄板。SCM使う発想がない時点で，そのプロジェクトは終わってる。

非常に同感。
開発の現場は、教科書よりも奇なり。

SCMを嫌がる現場は、バイナリファイルをいじっている所が多い。
Excelで仕様書を書いているとか、PhotoshopやIllustratorでお絵描きしているとか。

結局、テキストで管理できないと、SCMの意味がない。

2. Introduce check-in policy

Redmineを使うようになって、コミットログにチケットNOを付ける運用ルールにしている。
これができないと、RedmineとSubversionを連携する意味がない。

駄目なプロジェクトは、SCMに関する作業品質が雑なこと。
単なるプログラミングだけでなく、コミットログも重要なのだ。

3. Automate build

自動ビルドできない開発では、サーバー上でビルドするのではなく、ローカルマシン上でビルドする時が多い。
だから、他の人がビルドできない。
結局、結合テスト以降のバグ修正をテスト環境へ反映して検証するのに非常に時間がかかる。

4. Create auto-deployable test environment

Mavenのような高機能なビルドツールを使っているかどうかだと思う。
Mavenでは、一度ビルドしたjarライブラリは、ビルドサーバーに保存してくれる。
単にビルドすればよいだけではなく、テスト環境ごとにライブラリが違う場合や、複数の依存ライブラリのバージョン管理する場合、に必要になる。

大規模プロジェクトやパッケージ製品開発では、必須だろう。

5. Use code quality analysis

(引用)品質検査ねぇ。いやいやツールそのものを批判する気はないが，運用がまずくてうまく回ってないケースをよく見るんで，あまり乗り気じゃない。

正直，FindBugsやCheckStyleなどのインスペクションはプログラマ個々人がたしなみとしてやるべきだと思ってる。なんでプロジェクト全体のサマリ出しても自分がやるって意識が薄くなるんじゃないかなぁって。

これも非常に同感。
品質検査が単なる手続きになってしまい、品質Upにつながらないプロジェクトが非常に多い。

本当は、ソフトウェアメトリックスを採取して、2次開発以降の継続的な開発でソフトウェア工学の知識を使えるようにすることがしたい。

6. Use unit test

(引用)うまく行ったときは効果絶大なんだけど，度重なる仕様変更などでテスト資産が不良債権化しないように維持するのが大変なので，バランス取りがとっても難しい。
これもまた，ある程度のマメさがないと良いテストコードを組んでもらえない。

これも非常に同感。
UnitTestが重要な認識は、プロジェクトリーダーだけでなくプログラマも共有している。
しかし、2次開発以降の継続的開発が進むと、テスト資産そのものもプログラムだから2倍以上のコストがかかるように感じる。

UnitTestの威力を運用保守で感じる時は、2つある。
一つは、ソースのマージ作業。
もう一つは、サーバーやDBなどの環境周りがバージョンUpした時。

前者は、作業ブランチからTrunkへマージした時、UnitTestで問題なければ、最低限の品質と検証は立証されたことになる。
但し、UnitTestのプログラムのマージ作業もあるので、作業量も2倍に増える感覚だが。

後者は、Oracleに不具合があったのでVerUpしたとか、Tomcatの性能が遅いのでVerUpしたとか、JDKそのものをVerUPした場合。
例えば、Oracleでは、10g以前の古いバージョンでは、256日以上稼動したままだとハングアップするというバグがあったらしい。

サーバー環境やDB環境を変更することは殆どないが、2次開発以降の継続開発では、環境周りをVerUPする時もある。
この時に、UnitTestで問題なければ、少なくとも本番稼動できるお墨付きの一つになる。

果たして、あなたのプロジェクトは、6ステップのうちどれだけ実践しているだろうか？