TDD Boot Camp 横浜 3rd に参加してきました #tddbc
はじめに
こんにちは。
（id:xxxcaqui さんのエントリーにインスパイアされた挨拶。）
参加者の皆様、お家に帰ってブログを書くまでが #tddbc ですよ！皆様のご感想をお待ちしております。
— しんや (@shinyaa31) October 5, 2013
というわけで遅くなってしまいましたが、TDDBC Yokohama 3rdにスタッフとして参加したのでそのレポートです。
TDDBC Yokohama 3rd開幕
基調講演
@yattomさんによる基調講演でした。
TDDBC横浜3rd from yattom
TDDBCではt_wadaさんが基調講演をしてくださることが多いのですが、そのエッセンスがにじみ出つつ、やっとむメソッドが織り込まれていて、とても楽しかったです。
TDDやろうと思ったのはなぜですか？ → 面白そうだったから！というのはすごく共感できました。
ペアプロデモ
今回はペアプロデモにチャレンジさせてもらいました。
意識したこと
後のLTで話すのですが、今回は「リズムを大事に」というのを意識してやりました。
その点については参加者の方の感想を見ているとそこそこうまくいったような気がしています。皆さんにいい影響があればいいな、と思います。
反省点（ちょっぴり裏方の話）
反省点として、@terahide27 さんもおっしゃってるのですが、TODOリストを細かくし過ぎた、というのがあります。
@comutt 懇親会でも話題に上ってたのですが、ペアプロでもでTODOリストの書き方はちょっとミスリードしました。お題が簡単だったから、テストケースに直結するくらい具体的になってしまっただけで、本来はもっと抽象度が高いタスクを書くことになると思います #tddbc
— てらひで (@terahide27) October 7, 2013
もう少し裏方の話をすると、過去のTDDBCのFizzBuzzでのデモのときは、だいたい
- 3の倍数のとき
- 5の倍数のとき
- 3と5の倍数のとき
- それ以外の時
みたいな、前回のデモよりはおおくくりなTODOを作ります。
そうすると、経験的に3の倍数のテストから実装する、という流れになります。
その場合、最初の Red -> Green -> Refactoring のサイクルが結構長くなってしまうという悩みがありました。
事前打ち合わせで、なんとか「それ以外のとき」のテストからやる流れにもっていけないかなーと考えた末、「どの値の時にどんな値を返すか？」って問いをベースにTODO組み立てれば、それ以外のときからやる流れできるし（インプットとしてシンプルな順考えると1からやることになると思うので）、結構Greenまで早く持っていけるんじゃね？ ということであの形になりました。
その狙い自体は悪くなかったと思っているのですが、結果的にTODOリストの粒度が細かくなり、午後の実践で細かいTODOを書く人がけっこう多かったように思います。
実践のお題で、TODOを必ずしも細かく書く必要はなかったと思っており、この点をミスリードしたかな、と反省しています。
解毒の意味も兼ねて、Youtubeにあがってる他のペアプロデモの動画もご参考にしていただければ。
で、その後悔があってLTすることになります。それは後述。
実践編
実践編では、疲れ果てたり自分のGroovy力に自信がもてなかったので、
RubyのTAをやるはずだった id:sue445 さんにGroovyのペアとして入ってもらい（ごめんなさい）、後ろでうろうろとみなさんのペアプロを見てました。
最初は慣れない感じで皆さんかたくなってる印象でしたが、時間がたつにつれどんどん慣れ、
コミュニケーションが活発になっていくのがわかってすごく嬉しかったです。
やっぱりペアプロすごい！
懇親会
#tddbc ビアバッシュ懇親会のLTがカオス過ぎて超たのしい
— YASUI Tsutomu (@yattom) October 5, 2013
ですね。あんなにみんなハジケるとはびっくり！ 楽しかったー！
（お酒飲み過ぎて詳細あんま覚えてない。。。。）
LT
ペアプロデモの反省から、ちょっと準備していた内容を変えてLTしました。
当日口頭で話した内容は下記です（一部忘れたけど）
TODOリスト。思ってたより細かい #tddbc
— iyuuya (@iyuuya) October 5, 2013
これはデモのところで書いた通りです。も少し粒度が大きいほうがよかったかなーと。
「ペアの交代は赤くなったところで」いいですね。「行き詰まったとき」も。それに、議論が過熱してきたらキーボードを奪っていったんコードを書いてみるというのもお勧めです。 #tddbc
— YASUI Tsutomu (@yattom) October 5, 2013
ペアプロの交代を「疲れたからかわって」「書きたくなったから貸して」みたいにカジュアルにできるの、いいですね！ #tddbc
— YASUI Tsutomu (@yattom) October 5, 2013
ペアプロでのペア交代って、時間で縛る必要ないのか。行き詰まったら交代、良い気がする。 #tddbc
— Johnny • H • Kikkawa (@shinjukujohnny) October 5, 2013
赤くなったら交代、行き詰まったら交代は@setoazusaさんのアイデアだった気がします。ありがとうございます！
カジュアルに変わるのはアドリブでしたが、実際疲れた時にアタマを切り替えられるのでよかったですね。
時間で区切るのも有りだと思います！ 集中モードになっちゃうときとかは時間で区切るの有効ですよね。
ひらがなは斬新だ… #tddbc
— とーます (@grimrose) October 5, 2013
テストメソッド名って日本語でいいのか とはいえ違和感ありまくるｗ #tddbc
— Keisuke.I (@syguer) October 5, 2013
「いちを入れたらいちをかえす」とか最初は書きましたからねｗｗ
比較的早く「_1を入れたら」とリファクタしましたが、あれは正解だったようです。
ここらへんは、一旦TODOリストに戻って話し合いの結果を書いたほうがいいと思います。 #tddbc
— とーます (@grimrose) October 5, 2013
仰るとおりです。。。TODOリストをもっと有効活用できたと思います。この点も反省。
ペアで話し合った内容を残すのは、特に難しい要件とかだと超大事な気がしました。
isMultiply()はprivateだし直接テストする対象になっておらず、convert()の内部(実装の詳細)だから、リファクタリングの一環としてグリーンのまま進められますね。 #tddbc
— YASUI Tsutomu (@yattom) October 5, 2013
そういえば、privateメソッドのテストについての話。見事なエントリがあるんだけど実はあまり知られてないのかも。素晴らしいまとめになっています。「プライベートメソッドのユニットテストは書かないもの？」 http://t.co/EDRlG1Qks4 #tddbc
— YASUI Tsutomu (@yattom) October 7, 2013
もはや定番化したprivateメソッドのテスト問題。
まとめにかえて
思えば1年ちょっと前、TDDBC Yokohamaの2ndに参加してから、
いろんな人と出会って勉強させてもらい、3rdではスタッフとしてお手伝いできました。
反省点も多かったですが、去年目標としていた、TDDBCに恩返しするって目的は一応達成できたかなと思います。
まだまだ自分もTDDBCも成長できることがあると思うので、引き続き高みを目指せればと思っています。（まずはGroovyか。。。。）
あと、楽しかった！ と感想を持ってくれたり、
スタッフとして参加したい！ って言ってくれる人が多かったのが嬉しかったです。
是非次回はスタッフで一緒に楽しみましょー！！
最後に、主宰の@setoazusaさん、スタッフ＆参加者のみなさま、アットウェアさん、ありがとうございました。
