テスト駆動開発プロジェクトの経験 [時の流れ]
11年前の2003年9月末に、あるハードウェアを制御する最も低レベルのコンポーネントのインタフェース仕様書の最初のバージョンを、私は書き上げています。それは、それから6年間におよぶテスト駆動開発の序章でした。最初は、(親会社と子会社の開発者から構成される)約10名の小さなチームでした。
1990年代までは、テストと言えば手作業というのが当たり前のソフトウェア業界でしたが、2000年に入り、テストは手作業ではなく自動で行うことが当たり前なる時代の幕開けでした。今日では、テスト駆動や継続的インテグレーションは当たり前ですが、2003年は、Jenkinsもなく、CruiseControlも登場していましたが、広くは普及していなかったと思います。
1978年に大学に入学してプログラミングを学び始めてから、すでに25年が過ぎていました。大規模になると予想されるシステム全体のテストをすべて自動化するという仕組みを導入するというのは、私自身にとっても未知の経験でした。しかし、技術的には可能であり、テスト駆動開発にするのが正しいということで、最終的なシステム全体をどうやって自動テストするかまでの青写真を描いたのもこの頃だと思います(ひょっとしたら、翌年かもしれませんが)。
私がインタフェース仕様書を最初に書いたモジュール(コンポーネント)から、完全にテスト駆動の開発が始まりました。C++でマルチスレッドプログラミングを私自身が再び行う開発の始まりでした。
さらに10年さかのぼると、1993年5月には、4年半の米国駐在を終えて帰国しました。駐在時代の開発の継続となるFuji Xerox DocuStation IM200※の開発が本格的に始まろうとしていた年です。それからの3年間におよぶこのプロジェクトでは、私自身は、C++とマルチスレッドプログラミングを学びましたし、当時としては社内でも画期的だった夜間自動ビルドシステムを私自身で構築しています。
※ 「商品・サービスの歩み」の1996年の欄に写真が掲載されています。1986年には、私が就職して最初に開発に従事した「Fuji Xerox 6060 Workstation」も掲載されています。
こうやって振り返ってみると、当時、画期的だと思った開発手法(夜間ビルドやシステム全体のテスト駆動開発)が、10年後には当たり前になっていたり、時代遅れになっていることになります。
(つづく)
1990年代までは、テストと言えば手作業というのが当たり前のソフトウェア業界でしたが、2000年に入り、テストは手作業ではなく自動で行うことが当たり前なる時代の幕開けでした。今日では、テスト駆動や継続的インテグレーションは当たり前ですが、2003年は、Jenkinsもなく、CruiseControlも登場していましたが、広くは普及していなかったと思います。
1978年に大学に入学してプログラミングを学び始めてから、すでに25年が過ぎていました。大規模になると予想されるシステム全体のテストをすべて自動化するという仕組みを導入するというのは、私自身にとっても未知の経験でした。しかし、技術的には可能であり、テスト駆動開発にするのが正しいということで、最終的なシステム全体をどうやって自動テストするかまでの青写真を描いたのもこの頃だと思います(ひょっとしたら、翌年かもしれませんが)。
私がインタフェース仕様書を最初に書いたモジュール(コンポーネント)から、完全にテスト駆動の開発が始まりました。C++でマルチスレッドプログラミングを私自身が再び行う開発の始まりでした。
さらに10年さかのぼると、1993年5月には、4年半の米国駐在を終えて帰国しました。駐在時代の開発の継続となるFuji Xerox DocuStation IM200※の開発が本格的に始まろうとしていた年です。それからの3年間におよぶこのプロジェクトでは、私自身は、C++とマルチスレッドプログラミングを学びましたし、当時としては社内でも画期的だった夜間自動ビルドシステムを私自身で構築しています。
※ 「商品・サービスの歩み」の1996年の欄に写真が掲載されています。1986年には、私が就職して最初に開発に従事した「Fuji Xerox 6060 Workstation」も掲載されています。
こうやって振り返ってみると、当時、画期的だと思った開発手法(夜間ビルドやシステム全体のテスト駆動開発)が、10年後には当たり前になっていたり、時代遅れになっていることになります。
(つづく)
2014-10-02 04:22
コメント(0)