TDDBootCamp北陸に行ってきました。
遅くなりましたが3月13日 TDD Boot Camp 北陸(石川県)にお邪魔してきました。
今回は北陸の、まだまだ雪の残る金沢で１泊２日の合宿でした。
id:t-wada先生の指導を受けながらTDDでペアプロの練習が出来るということで東京から夜行バスで飛び込んだ訳ですが、想像以上に得るものは多かったです。
流れとしては、告知にあった通り
2010年3月13日（土曜日）
- 10:00 〜 やんわりと受付開始
- 11:00 〜 12:00 id:t-wadaによる入門講演
- 12:00 〜 13:00 ランチタイム
- 13:00 〜 15:00 第一弾 ペアプロによるTDD、コードレビュー
- 15:00 〜 15:30 休憩
- 15:30 〜 17:30 第二弾 ペアプロによるTDD、コードレビュー
- 17:30 〜 18:00 ふりかえり。--TDD Boot Camp 終了
- 19:30 〜 夕食
- 21:00 〜 やんわりとディスカッション「テーマ：TDD導入への課題について（と、明日やることについて）」
2010年3月14日（日曜日）
- 10:00 〜 ２日目開始 （詳細未定）
- 12:00 〜 13:00 ランチタイム
- 〜 15:00 終了
という形でした。
第一弾、第二弾のペアプロ＆コードレビューは「ワードフィルターを実装する。」と「ワードフィルターに仕様追加を実装する。」
ということで、僕はJavaを選び、ペアプロに参加させていただきました。
２日目は、レガシーコードを対象にして、「テストの無いコードにどうアプローチするか」という内容でした。
TDDのやXPについては本やその写経による学習もありますが、実際にお手本を見たり、やりながら直接指導を受けられたりすることで得られるものはやっぱり多いですね。
特に最初にid:t-wadaさんとid:katzchangさんのペアプロのデモを見ただけでも、二人が掛け合う言葉や、PCを取り合うタイミングや掛け合いみたいなものを見るだけでも雰囲気が大分つかめます。そのあとすぐにそれを実践して分からないところがあればすぐに聞けるので、普段思っていたこと、やって始めて気づいたこと、色々教わることが出来ました。
また「レガシーコード=テストの無いコード」は、現場側としては切実な問題でもあり、実際にレガシーコードをどう切り崩すかのデモも見せていただけました。新規開発で最初からTDDで行くなんていう機会自体は多分少なくて、現状動いているコードを相手にすることの方が恐らく多いので、その点ではとても実践的だったと思います。
夜中も、みんな色々ディスカッション(TDDだけでなく、技術話や宗教戦争まで)して、id:t-wadaさんにも色々聞くことが出来ました。
おかげで「分かった気になっていた部分」の矯正等も結構出来た気がします、逆に分からないことも見えてきた意味では自分なりの課題も宿題として持ち帰ることが出来ました。
あと、ペアプロをする機会って、自分の職場や近しい周囲で同じ目的を持っている人がいない限り、なかなか実施できる機会が無いと思います。さっき始めてあった人とペアプロをするという機会自体もとても刺激的でした。
自分はあまり経験が無いので、終始緊張して凡ミスを連発し足を引っ張っていましたが、こういう体験はもっと積んで行きたいです。
Java-jaでペアプロの勉強会もあるし、和田さんは「他の場所でも機会があれば行く」ということをおっしゃっていましたが、実際は大変だと思います。ただ、そういう講師的な方に来ていただけなかったとしても、「みんなでペアプロをする」っていう機会自体、もっとあったらいいなと思いました。（これ需要ある気がするのは僕だけか？）
特に、これはかなり狭い話だけど、javaではeclipseがメインになります。このeclipseは人それぞれ結構使い方が違って、そういう「他の人のコーディング環境／スタイル」が見られるのも結構貴重な気がしました。実際に今回ペアプロさせていただいた方は、かなりeclipseを使い込んでいて、「あーそうやっても出来るのか」みたいな場面が結構あったりしました。
eclipseはそれ自身はシンプルだけど、拡張やカスタマイズが色々できるので、分かってはいましたがまだまだ知らないことが多いです。そこですらまだ勉強の余地があることも今回の収穫の一つでした。
あと合宿は純粋に楽しいですね、次の日大変なのも分かっていながら、夜通し色々な方と色々な話が出来ました。
リテラシーの高い方達が集まる場は本当に勉強になります。
完全にアウェイな北陸に、飛び込んでみて良かったと思いました。
主催のid:katzchang さん、そしてid:t-wadaさん、参加された皆さん、本当にありがとうございました。お疲れさまでした。
メモ
- キャラクタライゼーションテスト、仕様が分からない状態で、現在のコードがどう動いているのかを知るためにテストを書く。
- スコープが狭いと、テストコードまで引っ張りだせないので、そういう場合は一旦スコープを広めて一時的に引っ張りだす。getterを付けるより変更量が少なくて済む。
- コンパイラや強力なIDEがある言語は、変えてみて出てくるエラーを見ながら構造を把握する。
- 強結合な場合は、外からコンストラクタやsetterで渡せるようにし、引きはがす。するとテスト時にパラメータを渡したり、モックを渡したり出来るので、テストする余地が増える。
- オブジェクト指向的に抽象化や再利用性の向上を頑張っても、テスタビリティーとは関係ないので、テストしやすいかどうかは別で考える必要がある。
- テスト名より、テストデータが意味を持ってくる場合は、データファイルを使用したテストの方がいいかもしれない合図。
- 金沢のバグ取りはひと味違うw
