TDD Boot Camp 大阪 2.0 に行ってきた
きのう、「TDD Boot Camp 大阪 2.0」に行ってきました。
楽天カフェテリア、さいこう!
ペアプロしたり、講演聞いたり。非常につかれ果てたけれど、充実の1日でした。
6/2開催の1.0が私用で行けず、いじけていたところを連日で6/3に2.0開催決定ということで
貴重な経験をする機会をえました。スタッフの皆さん、ありがとうございました。
「だれがなんのためにテストをするか?」
@t_wada さんの講演での一節。
・開発者が開発促進するために (TDDはここに含まれる)
・顧客が進捗管理するために
・品質保証担当者が品質保証のために
このテストの分類が、今回の座学系でいちばんの気づきでした。
これまでは、回帰テストやテスト自動化に使うというコンテキストでしかTDDやテストコードを説明できていませんでした。
TDDは開発促進のためであることがまず第一で、品質保証は二の次。
TDDを延長していけば、テスト自動化にも結びついてくるのだと腹落ちしました。
「テストコード書くといいよ」は相手によってコンテキストを変えなければいけないと思いました。
ペアプログラミングTDD
@momontyo さんとペアプロ。
Red/Green/Refactor(黄金の回転)を速く回転させることで得られる感覚や成果は実際にやってみないと絶対にわからない。
TDDBCはこの回転を実感できる場というだけでも、十分価値があると思います。
ドライバーとナビゲータ、10分ごとの強制交代でした。
小さいタイムボックスのなかで実現できることは少ないです。
「アレもコレも」と詰め込もうと思っても、収まりません。
最後のタイムボックス10分は「機能追加はひとつだけにして、残りはリファクタリングしよう」という思考に自然となりました。これは健全な思考です、いま思い返してみても。
今回はひとつひとつ目前の課題だけを都度設定して集中したけれども、実際にはプランニングも多少は必要で、
バックログリストを作って優先度順に消化していくことが必要なのだろうと思います。
どこまで作ったら終わりにするか、という目標設定も必要です。
2時間でできるところまで、といった設定もありだとは思います。
アレコレ悩んで重厚な設計をしてから実装するというスタイルでしたが、悩まずにとりあえず手を動かして、テストして、手を動かして…
後からきれいな状態に持っていくこともできそうだという感覚を得ました。
アレコレ悩むのも、悩んでアレコレするのは、実は頭を使っていないです。たぶん。
ダイナミックなリファクタリングも、技術を身につければ可能です。
あと、うちらが作ったコードが参加者全員に晒されました。
TAを担当していただいた、@kyon_mm さんより紹介。ありがとうございました。
ちょっとうれしかった。エヘン、エヘン。
Groovy / Spock
ここは、別途また書こう。
Groovy は1ヶ月目くらいで、Spock は初めて。
周りは Groovy 自体初めての人が多かったです。
でも、やってみたいという意欲ありというオドロキ。
新しい言語を学ぶ敷居を低くするという働きは Groovy の特徴かも知れない。
当日いきなり知らない言語でやってみるとか冒険だと思いますけど。
ショートカットキー
ペアプロデモで @irof さんがショートカットキーを多用駆使して、
ものすごいスピードでリファクタリングしてたことに驚きました。
Eclipseに多くのショートカットキーが埋め込まれているのだけれど、
「こんなもん、イラネ」と自分が無視しているようなキーを使ってたんだろうなと。
自分には、リファクタリングとか、短時間における生産性の追求という感覚がありませんでした。
Eclipseにそういう上級者向けショートカットが潜在していることが指し示すのは
リファクタリングをしている技術者がたくさんいて、その要望にEclipseが応えているということ。
『Clean Coder』には、「プロは練習しないといけない」とあります。
練習…そういうことかと身にしみました。
その他、個人的な気づき
・他の勉強会でも見たことがある人がスタッフ、参加者ともにチラホラいらっしゃった。
・Twitterでフォローしている先駆者さんたちを生で見れました。「ほんとに、うさみみだ」
・テストケースのメソッド名に日本語を書くのをためらっていましたが、今回を機に日本語メソッド名に転向します。
・本では得られない気づき。やってみないと、肌に触れてみないと。