TDDBC Toyama 参加(と主催)してきた
こんなイベントに参加＆主催側として色々やってきた。
TDDBCとは
TDD Boot Camp(TDDBC) とは、テスト駆動開発(Test Driven Development)について、座学だけでなく、実習形式で手を動かして体得することを目的とするイベントです。
各地のコミュニティの方々が中心となって、全国各地で行われています。
(http://devtesting.jp/tddbc/ より引用)
Toyama.rbにも頻繁に参加してくれている @hikaruworld さんが中心となり、@kunitooさんと私で手伝うような形で準備していて、この土日に無事開催できた。
特別ゲスト
@t_wada 氏。もうこれ以上無い完璧なゲスト。
個人的には「えっ、まじで！？あの@t_wadaさん来てくれるの！？」って感じだった。
会場
秀夢木楽館
この会場がすごかった。
- 5階建
- 一棟丸々借りれる
- 立派なキッチン
- カトラリー使える
- コーヒーメーカー使える
- セミナールーム的な空間もある
- 全体的にオシャレ
- 木の雰囲気がいい感じ
こういうイベントのために存在してるんじゃないのってぐらいの会場だった。問題があるとすれば、一定の人数がいないと借りることができないというのがあって、たとえばToyama.rbで毎月借りれるような会場ではない。
TDDBC - Day1
@t_wadaさんによるライブコーディング
FizzBuzz問題を題材としてTDDを実践した場合の例を @t_wadaさん自らがライブコーディングしながら解説。
とても印象に残ったのは、「テストを減らす責任」という部分。
テストを減らす責任ってのは考えたことなかったな #tddbct
— mugi (@mugi_uno) 2017年2月18日
仕事のなかで “テストコード”, “TDD” といった文脈で会話をするときに中心に挙がるのは
- テストを書く文化をどう根付かせるか
- テストをうまく書くにはどうするか
- 効率のよいテストはどう書けばよいか
- テスト駆動をするためには何が必要なのか
みたいな、「テストを書く」といった部分にフォーカスすることが多かったように思う。
今回 @t_wada さんが言っていたのは、私の理解では以下のような内容。
- 実装者以外がテストを消すことは心理的な面でも非常にコストが高い
- 対称性の無いテストコードがあると、後から見た人には「意味があって非対称」「意味なく非対称」の区別がつかない
- 実装者であればそこの判断がつくため減らしておくことができる
書くことも大事だけど、書いていく過程でテストコード自体もリファクタリングをしていき、テストコード自体が負債とならないような意識を持つことも大事だな〜と感じた。でもこのあたりは、いかに芯を捉えたテストコードを書けるか？ということにも繋がってくると思うので、経験と勘も必要になりそうだ・・。自分はまだ修行が足らなそう。
ペアプロで実践TDD
- テーマ「セマンティック・バージョニング」
- “1.4.2” といったバージョン情報を取り扱うクラスをTDDで徐々に拡張していく
- 言語ごとにわかれてペアプロ
- このときはjsで参加した
デモ
主催者側ということで、問題のさわりの部分のペアプロの雰囲気を @kunitoo さんと二人でデモをした。色々と困惑するような雰囲気も含めて全部デモとして伝えればいいでしょ！とか思ってたら、本当に細々と困惑して期待通りの結果になった。
- 反省 : 事前に用意した不要なサンプルコードは邪魔なので消しとくべきだった。
ペアプロよかった
仕事ではまともにペアプロというものを経験する機会がなかったので、若干緊張していたのは秘密。
「ペアでやったからといって効率が落ちるわけではない。むしろ上がることもあるよ。」みたいな話を聞いたことがあったけど、実際やってみると確かにその通りだった。
一人だとついつい細かいところを考えすぎて手が止まっちゃうところで、二人でやっていると不思議と「とにかく前に進めよう」という気持ちになる。
ただ、これも噂に聞いていた通り、死ぬほど疲れるというのも事実だった。 逆に言えば一人のときに短時間でそこまでは疲れないので、「実は自分ってそんなにパフォーマンス出せてないんじゃないの？」という気持ちに。
教える学び
どちらかというとペアの方と自分とでは、自分の方がjsに関するノウハウは持っていて、教える側に回ることがちょくちょくあったけど、これは教えてる側も思考が整理される行為だった。
どこかで聞いたようなワードだけども、うまく教えるためには教える側がしっかりと理解していることが前提条件になってくるので、逆に自分がフワっとしてる部分も現実として突きつけられたりしてた。 （整数判定で自分が Number#isIntegerを思い出せなくて絶望したりした)
夜の部
なぜか尋常では無いご馳走が振る舞われた
- ぶりしゃぶ
- ぶりとふぐ
- 乾杯
- カワハギの肝
特にカワハギの肝が半端じゃなかった。
これを醤油に溶いてブリつけて食べたら、もう美味すぎて死ぬかと思った。
富山県民でよかった。
（ご用意していただいた @nagise さん、ありがとうございました）
Hololens
持ってきた方がいらっしゃったので、MicrosoftのHololensを体験させてもらった。
壁を認識しているようで、空間に映し出されているオブジェクトやウィンドウが、綺麗に壁に沿って配備されるのがなんだか不思議。
操作感としては、個人的には難しく慣れが必要だな〜と感じたけど、色々な可能性を感じるガジェットだった。
寝不足
色々と盛り上がってしまい、AM4:00まで起きてて完全に寝不足。
でも楽しかったし満足も多いので、まったく後悔はしていない。
でも寝不足。
TDDBC - Day2
ダメコード鑑賞会
二日目の朝は、まずはウォーミングアップということで、とある非常に強烈なダメコードを皆で鑑賞しながら、好きに喋ってみようみたいなことをやった。
途中、"&&“ と三項演算子が入り混じったコードがあって、全体的に「え？これって結果どうなるんだ・・？」みたいな議論が起きた。
ただ、肝心なのは「そもそもこういう議論をしないためにもちゃんとやろうね！」というところだな、という認識を改めて確認。
実践版リファクタリング＆機能追加
あらかじめ用意されている Java/C#/Javascript/Ruby/PHP のサンプルコードを利用して、リファクタリング・機能追加をTDDを交えながら実際に体験。
サンプルコードについては極力言語差異が無いように、
- 構造は同じ作り
- 変数名も完全に同じ
- 結果は標準出力のみ
といったものを事前に用意。
さらにいえば、
- 実装漏れとなっている部分も同じ
- バグも同じ
といった状態。
これは、Toyama.rbのもくもく会を使って用意した。
PHPのみに関しては事前に用意できず、1日目の夜の部のときにPHP希望者の方にご協力いただいて作成。（感謝）
※
余談として、Toyama.rbもくもく会では最初に「今日やること」を宣言しており、この時の私の宣言は「今日はJavaでクソコードを書きます」だった。もはや自分でも何を言っているのか解らなかった。
※
さらに言うと、クソコード作成中は「綺麗なコードですね。ダメです。」みたいなワードが飛び交っていて、カオスな雰囲気が実に良かった。
既存問題にどう立ち向かうか？
テーマとしては、
- すでに存在しているコード
- テストはない
- 仕様もない
みたいなものにどう立ち向かっていけば良いのか？というところだったと思う。
アプローチとしては、まずは全体のアウトプットをテストするコードを用意し、内部を変えた場合にブラックボックス的に問題が無いことを維持できる状態を作っていた。
あとは、「機械にやらせる」というワードも覚えときたい。
@t_wadaさんも含め、ガンガンIDE(WebStormとか)の機能を駆使している光景が良く目に入ってきた。当然といえば当然だけど、確かに手でやるより安心してやれるわけだし、使えるもんは使った方がいいよね。
既存バグの恐怖
サンプルコードを用意した側としては、本音を言うと軽い気持ちでバグを仕込んだものの、これが参加者に対して「既存コードのリファクタリング中に既存バグに出会ったらどうするか？」を考える良いきっかけになった。
というか仕込んだ私自身がどうしたらいいか悩んだ。
悩みどころとしては
- バグも含めて既存実装なんじゃないの？
- いやいや仕様が明確なんだから直すべきでしょ
という点。
明確なゴールが定まっている場合にはテストを書いて修正する方法もあるけれど、そうではない場合は難しいこともあるし、こればかりは状況に応じて判断する必要があるようだった。
参加してみて
学べた
実に学びが多かった。
Toyama.rbでも「手を動かしたい！」というのは前から言っていて、今回もゴリゴリに手を動かして参加するイベントで、実際に何かが身についた感がある。
次は実践
「TDDはスキル」という言葉も印象的だった。
一人でも、まずは小さいところからコツコツやっていこう。
というわけで
参加者の皆様、そして @t_wada さんありがとうございました。
@hikaruworldさん、@kunitooさん、おつかれさまでした！