TDDBC札幌2019を開催しました
6/15(土)はt_wadaさんをお迎えして札幌で8年ぶりのTDDBCでした。
当日はわざわざ仙台からi_takehiroさんがお手伝いで来てくださり、t_wadaさんの基調講演&ライブコーディング、そしてi_takehiroさん名物(？)レビューのマサカリが炸裂するというめちゃくちゃエモいイベントでした。
当日様子はnemorineがtogetterにまとめてくれましたので、こちらをご覧いただければ会場のアツい感じが伝わるかと思います。
本イベントのメイン担当のKO_SHO14もブログにまとめてくれていますのでこちらもご覧ください。
ちょっと余韻に浸っている間に他の参加者の方達がぞくぞくと参加レポートを書いてくれていて、しかもすごくよくまとまっているものばかりですので、私の方はちょっとした感想とスタッフとしての裏話を書こうと思います。
お弁当
お弁当付きのイベントだったので私はお弁当係りでした。
幕の内かちらし二段弁当からお選びいただける感じにしました（幕の内は撮るの忘れました）。
実物は写真でみるより小ぶりです。スタッフ集合時間に遅刻して朝ごはんを食べずに参加した私としてはもう少し大きかったらよかったかなぁ。この後パン１つ食べました。
午前中は基調講演だったこともあり参加者どうしで自己紹介したり会話するきっかけがまだないままお弁当タイムへ突入だったので、ちょっと静かなランチタイムとなりました。
基調講演
ざっくりなタイムテーブルを説明すると、午前はTDDの基調講演+ライブコーディング、午後はペアによるTDD体験でした。
基調講演ではこちらにそってt_wadaさんからわかりやすい説明をしていただいたあとに、実際のTDDをライブコーディングで見せていただきました。
私は、事前にTDDについて調べた時に「要件や説明文をTODOリスト化する」というところが一番悩みそうだったのですがいくつかコツを掴むことができました。
- テストが大変そうなところ、やりたくなさそうなところを後ろに回して、テストをしたら効果がありそうなところを残すようにしてわける。
- ただし書きがある場合は、そこから基本の動作を読み解くことができる。
- リスト化していくときは、表記揺れがないように言葉や言い回しも揃えていくと良い。
- 重要なところはテストしやすくし、テストしにくいところには大事なロジックを置かない。
- TODOリストは最初からパーフェクトに作らなくてよい。うまくTODOリスト化できていないとテストや実装で手が止まるが、手が止まるのは考え抜けていないということなので、そうなったらまたTODOリストに戻ってくればいい。
この辺の大事なことは時と共に忘れてしまいそうだったのでしっかり動画に収めました。
ワーク
午後のワークで、私はRuby+ Test-Unitで整数の閉区間のお題に挑戦しました。
実際にやってみてめちゃくちゃ感じたのは「TDDはやらずして習得できない」ということです。TDD習得したいと思っている人はTDD本読むだけではなくてほんとやったほうがよくわかります。*1
私も実際ここに来るまでは間違って覚えていたことがたくさんありました。
自分の場合は、どうしてもRed（失敗するテストを書く）からrefactoring（動くきれいなコード）に飛びがちで、green（失敗するテストを通すためのプロダクトコードを書く）が抜けそうになりました。私だけではなくテストを書く習慣がない人はけっこう同じ感じだったんじゃないかなーと思います。
あとはred⇒green⇒refactoringをまわす速さというかリズム感みたいなものはやってみないとわからない部分だなぁと感じました。
たとえばred⇒greenにする時に、greenにするためのプロダクトコードがうまく書けない(このテストをgreenにしようとすると他のテストが死ぬ)とか、red⇒greenまでが適当すぎてrefactoringでやたら時間かかるとか、そういうリズムは書いて詰まって初めて「ああ、テストコードの構成がよくないんだな」とか「名前適当すぎてこのテストとあのテストの区別がわからん」とかが見えてくるという感じでした。
ワークの後はいくつかのペアからピックアップして公開レビューをするのですが、ここでi_takehiroの鋭いマサカリが炸裂します。
llanowar19jは「おっしゃる通りです」を10回以上連呼してた気がします。
私はまだヒヨコすぎてマサカリを受けたら即死だと思いますが、指摘がすごく的確だったのでこういったレビューを受けることができるというのも良い機会だなと思いました。
スタンドのスタンド
nemorineのこのひとことからすべては始まりました。
デザインは私、企画と製作はnemorineで作ったスタンドのスタンドがこちらです。
なん……だと……！？#tddbc #agilesapporo pic.twitter.com/H9o6BrKjBD
— Takuto Wada (@t_wada) 2019年6月15日
likeが今でも伸び続けていて1000を超えました！ ベルトはよく見たらTDDになっていることにみなさんお気づきでしょうか。
みなさん会場に入る前に写真を撮ってSNSにあげてくれたり、t_wadaさんとの記念撮影に使ってくれたりしたので作ってよかったなと思いました。
スタンドのスタンドの裏話
まずはボツ案。
口を開けて吠えているのはt_wadaさんのスタンドっぽくないということで却下。なるほど。
最終的に大きく投影したときに、バランスが悪くならないようにちゃんと6等身を意識するよう気をつけました。
ちなみに当初案では体毛が生えてましたが、最終的には脱毛しました。
実際に現場で完成版をみると手直ししたいところがたくさんありますが、まあまあ満足です。*2
まとめ
プログラマの三大美徳の気持ちをもっと持とうと思いました。*3
動作するきれいなコードはあらゆる意味で価値があり、だけといきなりやるのは難しい。まずは動作するコード、それからきれいなコードへ。そしてそれを一度にやろうとせず１つずつ倒すことが大切だなぁと思いました。
文章からテストを起こす(文章がテストを駆動する)とか
失敗するテストを通すためのプロダクトコードを書く(テストが開発を駆動する)とか
テストが書けなくて手が止まったらTODOリストに戻る(テストがテストを駆動する)とか
greenのテストが意図せずredになったらテストを見直す(開発がテストを駆動する)
みたいに相互的に作用していて、この開発方法がテスト駆動開発と呼ばれる理由が腑に落ちた気がします。
逆にテストを先に書いても、キレイな動くコードを書くことに貢献できていないのならただのテストファーストでTDDではないということかな。
まぁちょっとまとめが雑ですが私としては学びがたくさんあってよかったです。
参加してくださったみなさんにも同じように感じてもらえていたら嬉しいです。
もしブログを見てアジャイル札幌のイベントに興味を持ちましたらぜひ来てください！
*2:最終的にはふんどしっぽいところにt_wadaさんのサインを入れていただきました。
