TDD Boot Camp 東京 for C++

http://www.zusaar.com/event/agZ6dXNhYXJyDQsSBUV2ZW50GK_kBgw

に行ってきました。
行ってみての感想としては今まで参加した社外イベントの中で一番よかったです。

というのも、

１．実際にプログラムを書いてTDDサイクルを回すことで、
小さいサイクルでプログラミングするスピード感を感じることができた

２．一人では導入するのが面倒くさい、TDD環境を自分のPCに導入することができた

３．ボトムアップでやっていくことの重要性を意識することができた

というのがあったからです。

１．実際にプログラムを書いてTDDサイクルを回すことで、
小さいサイクルでプログラミングするスピード感を感じることができた

これは実際にやってみないと見たり聞いたりしただけでは
分からないことだと思いました。そして、TDDとは話が逸れてしまいますが、
演習のペアプログラミングがすごく楽しくてあっという間に時間が過ぎてしまいました。
疲れましたが、久しぶりにアルゴ的な頭の使い方をして、
仕事の疲れとは違って爽快でした。

２．一人では導入するのが面倒くさい、TDD環境を自分のPCに導入することができた

TDDをやるうえで、一番の敷居はここだと思っています。
私は普段メーカーの製品のデバイスドライバのソフトを作っていますが、
かなりエレキと近いところをやっていて、業務でオシロスコープで波形を測ったりするくらいで、
開発環境がWeb系のプログラマなどに比べて非常に弱いです。
設計者も全員がとは言いませんが、構成管理ツールやテストの自動化などに対して
非常に意識が低く、人によっては作業を全部手でやらないと安心できないという人すらいます。

今回TDDをやるために導入したものは

１．GitHub（分散リポジトリ）
２．GoogleTest
３．Visual C++　2010

です。知っている人が上記をネットからダウンロードして、
使う分には何も問題ありませんが、知らない人が独力で上記をダウンロードして設定するのは
結構厳しいと思います。

てか、GitHubがすごくいい。
分散リポジトリを初めて使ったのですが、
開発者がローカルで気軽にファイルをコミット（Ｃｉｎ）できるというのがすごくいい。
テストが動いた時点ですぐにファイルをコミットしていくことができるので、
一度に大量にファイルをコミットする場合に比べてすごく安心感があります。
TDDでは失敗するテストを先に作って、
それを成功するようにプロダクトコードを書いていくので
作る側としてはテストを作れば作るほど、
動作が保証されていくので非常に安心感があります。
後、GoogleTestはテストが自動なのでテストの数が増えても苦になりません。

３．ボトムアップでやっていくことの重要性を意識することができた
自分一人だけTDDやって、生産性が向上したとしても、
あまり組織としての利益というのはあまりなくて、
周りを巻き込んでやることの重要性というのを再認識しました。
そして、何かを変えるにはトップダウンではなく
ボトムアップでないといけないのかなとも思いました。

例えば、コンサルの人が使うような資料を以って上を説得して、
トップダウンでTDDをやろうとしても、
きっと異なる開発環境や開発スタイルへの不適応が起こって、
形骸化して破綻するような気がします。
今までそういうのを何度も見てきているし。

最近、誰でもできるようなフレームワークを作って
設計は上流までで、下流のプログラミングは誰でもできるようにして、
安い人件費でコストを下げようみたいな風潮を感じることがありますが、
誰でもプログラミングできるわけがないと思っています。
分かりやすい設計をすることは重要ですが、
誰でも設計・実装できるようにするというのは夢物語で

ちゃんと技術を分かっている人が草の根でやって、教育して
全体の底上げを図っていかないとだめなのかと思います。

というわけで、自宅に環境も整ったことなので、
仕事の合間にTDDの活動にコミットしたい名と思います。

また次のイベントがあったら行きたい！

TDDについて

１年くらい更新が滞ってました。
土曜にTDDBootCampというイベントがあって、
非常に楽しかったのと非常に有益だと感じたので
ブログに書いて、シェアできないかと思った次第です。

そもそもTDDって何かについて。
Test Driven Developmentの略でテスト駆動開発といいます。

http://www.amazon.co.jp/Test-Driven-Development-Embedded-Pragmatic-Programmers/dp/193435662X

私自身の問題意識としては仕事で、作ったプログラムをCin(あるいはコミット)するまでの
開発サイクルがあまりに長いのが何とかならないものかというものがあって、
TDDBootCampに参加しました。

開発サイクルが長いと以下の問題があります

・一度にCin(あるいはコミット)するファイルの数が増えるので、バグの混入率が上がる
・上記バグにより手戻りが増え、デバッグのための開発コストが増える
・デバッグというのはいつ終わるか見通しがつきにくく工数見積もりの精度が下がる
・そもそも長期間でスケジュールを立てるので、なかなか正確な工数見積もりができない

結果として、プロジェクトの遅延と残業超過、開発者の心身荒廃につながります。

私のいる環境は気軽にCin(あるいはコミット)できる環境ではなく、
一つの対応をCin(あるいはコミット)するのに最短でも３日、通常で１，２週間、
ひどいときだと１ヶ月以上ファイルをローカルに持ち続けていることがあり、
かなり酷い目（鬼残業デバッグ）に会っています。

それに対して、TDDはその名のとおり、テストを最初に作ります。
サイクルとしては以下の１～３のとおりです。

１．プロダクトコードではなくテストコードを最初に書きます。

２．このテストコードはテストとしては失敗する状態のもので、
そのテストが成功するようにプロダクトコードを書いていきます。

３．テストが動いた（成功した）時点で、
すぐにファイルをCin(あるいはコミット)できるというところにあります。

１～３の小さなサイクルを繰り返していくのです。

以下に私がTDDのメリットだと思うことをあげます。

（１）テストを最初に書くので、最初にきちんとユースケースを意識することになり、
開発後半でのユースケース漏れする確率が減ります。

（２）失敗するテストコードが成功するまでプロダクトコードを書くので、
プロダクトコードを書いてからテストコードを書く場合に比べて、
テスト漏れやミスが起きにくいです。

（３）テストが動いた（成功した）時点で、
すぐにファイルをCin(あるいはコミット)できるので、
一度に大量にCin(あるいはコミット)する場合よりもミスや手戻りが減ります。

テストを最初にやって、開発初期の段階で
テスト結果により即フィードバックをもらいながら
小さいサイクルで物を作っていこうというものです。
バグは発見が遅れれば遅れるほど指数関数的にデバッグ・修正コストが増大していきます。
逆に言うと開発初期の段階で見つけることができれば、
プロジェクトの遅延も残業コストの低減にも開発者の健康にもつながるのです。
（TDDだけで上記が達成できるとは言いませんが）

ただ、言うことと実際にやることは全く以って異なるので、
今回TDDBootCampForC++に参加しました。
長くなったのでTDDBootCampForC++については別に書きます。