7/10, 7/11 の2日間開催された「TDD Boot Camp 名古屋」に登壇させていただきました。参加くださった皆様、そして企画を立ち上げ主催した id:bleis-tift さん、ありがとうございました。素晴らしいスタッフの力により、良いイベントになったと考えています。本当に、心から感謝いたします。
イベントの構成は TDDBC 北陸と同様の2日間二部構成のコースで、次のような構成で行いました。
- 一日目午前
- TDD についての講演+デモ
- 一日目午後
- (ペアプロ+コードレビュー)×2
- 一日目夜
- いろいろ自重しない議論
- 二日目午前
- レガシーコード(テストの無いコード)改善についての講演+デモ
- 二日目午後
- レガシーコード改善実習(コーディング道場乱取り版)
一日目講演資料
二日目講演資料
TDDBC 名古屋に参加した方は、 TDD やレガシーコード改善に関して何かヒントを掴んで帰っていただけたのではないかと思います。TDDBC 名古屋で掴んだことを、これからの開発、これからの組織に役立てていただければ幸いです。当日聞けなかったけれどまだモヤモヤしている/疑問点がある場合は、遠慮なく blog やメール、 Twitter で聞いてください。
TDDBC 名古屋のトラックバックセンターはこちらです。blog を書いたら、ぜひトラックバックをお願いします。
http://blogs.yahoo.co.jp/nagoya_agile_study_group/32506622.html
また、参加者の書いたソースコードの共有を始めています
http://code.google.com/p/tddbcnagoya2010/
今回の TDDBC が終わった直後にも、何人かの若者が TDDBC を自分の地方でもやりたいという声をあげてくれました。もちろんまだ実現できるかどうかは分かりません。それでも、そういう意志を持っていただけるのが本当に嬉しいです。
前回と同じような締めになってしまい恐縮なのですが、やはり同じようなことを書かせてください。 TDDBC は開発の楽しさ、ペアプロ/TDD/コードレビューの楽しさ、そしてレガシーコードとの戦い方を伝え広めていけるようなイベントにしたいと考えています。TDDBC は「やりたい」と手をあげれば始められるイベントです。このようなイベントをこれからも開催できたらいいなと思っています。
以下 140 字形式で個人の感想を記してゆきます
- スタッフワークがとにかく素晴らしかった。事前の準備と事後の振り返り。
- イベント直後に KPT を行っていた。名古屋のコミュニティの改善魂には本当に尊敬の念を抱いた。
- 考えてみたら一日目の KPT の Problem のいくつかも二日目には改善されていた
- 一日目のTDD+ペアプロ演習 OCaml が二ペア、Scala が三ペア。関数型言語を選択する参加者が多かったし、活発に議論を行っていた
- いろいろな言語のコードはこれから blog 等で公開されていくといいなと思います
- 今回は学生の参加者が多く嬉しかった。特に豊橋技科大からは沢山の方に参加していただきました
- 複数回 TDDBC に参加してくださっている方がいて、本当に嬉しい
- 宿泊組は同じホテルに泊まり、部屋に集まって議論したり、ハッカソンしたり。まるで修学旅行のようで楽しかった。
- みんなつながっている。 Twitter でつながっている。今回の期間中 #tddbc タグを見たり、 @bleis さんの tddbcnagoya リストを見るのが本当に楽しかったです
- 動的言語には動的言語の、静的言語には静的言語なりのレガシーコードとの戦い方がある。継ぎ目(Seam)の作成に動的な性質を生かし動的置き換えで積極的に使うも良し、静的言語ならではのコンパイラの力を最大限に生かすも良し。
- GUI のテストはそもそも仕様化テスト (Characterization Test: 『レガシーコード改善ガイド』参照) が難しいので、仕様化テストを「できるように」、テストの支え無しでまず解体するという方針が多く出た。 継目(Seam) が出来たらテストを書き始める。そうでないと最初の一歩を踏み出すことがそもそも難しい。
- レガシーコードのサンプルの選択は難しい。 GUI が絡むとどうしても難易度が上がり、構造の理解や継ぎ目の作成に時間がかかる。
- テスト(仕様化テスト)の力を借りずに(もしくは借りることが適わない状況で)レガシーコードに立ち向かう際には、改善の指針が必要になる。 @biac さんのグループの指導は非常に参考になり、学ぶものが多かった。
- Scala や Ocaml を選択したグループのコードはやはり面白く、勉強になることも多かった
- 破壊的代入を行う部分と行わない部分をきっちりと分け、破壊的な部分を最小にする。複雑な部分は純粋関数として組むことで、テスト容易性が向上する。あとヌルポが無い（自分で明示的に使わない限りは発生しない) のが Scala の強み
