TDDBCに行ってきた
久しぶりの更新になります。
本日、TDDBC in Tokyo 2016-02 - TDDBC | Doorkeeperに参加させて頂きました。
TDD自体は興味があって趣味の範囲でちょこちょこJUnit触ったりとか最近だとEspresso触ったりしていたんですが、
業務ではまったくやっていないため入門書をかじった程度で止まっていました。
そこから先に進んでみたいなと思い今回参加に踏み切りました。
午前の部(導入)
午前中は@setoazusaさんによるTDDとはなんぞや？という解説(基調講演)を聞きました。
TDDの知識はネットと本でしか得ておらず、実践している方からお話が聞けたのはとてもためになりました。
特に自分に刺さったのは
- 不安をテストで表現する
- TDDをやれば偉いわけじゃない
- なぜTDDするのか
です。特になぜTDDするのか？は考えさせられました。一番最初に興味を持ったのは当時担当していたAndroidアプリのリリース頻度が短くて毎回人力テストをしていたときに辛みが増してきて、リリース前のテストを自動化できたらいいのにとか思ってたときですね。最近では、Espressoかっけー！テストやってる感じがする！テスト書いてる自分偉い！ってなってました。開発効率全然考えてない・・・。プログラマの三大美徳がおざなりになってました。
その後は、運営チームの方がペアプロのデモをしてくれました。
デモを見ながら、あーこんなペースで話しながら開発するなんて無理だわって思ってました。
手慣れてる感がすごい。
午後の部(ペアプロでTDD)
午後は実際にペアプロしてみましょうということで早速ペア決めを。自分はJavaを選択しました。ここでKotlinとか言えたらかっこよかったのかな。
その後、お題が出されそのお題をTDDしながら２人で開発していくことに。ペアプロ自体もあまりやったことがなかったので新鮮でした。というかペアでキーボードを叩いていないときは何をすればいいかわからなかったのでとりあえず、スペルミスがないかチェックと実装に悩んでたら一緒に悩む的なことをしてました。最終的には課題4？まで終わってフィニッシュ。後半は頭の回転が鈍くなりペアの方の実装を目で追うので精一杯に・・・
ここで疑問が。ペアプロの場合、組む相手が自分の知らないライブラリやクラスを使い始めたらどうすればいいんだろう。
ペアでする以上片方がついていけなくなるとペアプロの意味がなくなるような気もする。かといって一々解説してもらってたら開発効率が下がるだろうなーと思ったり。
ためになったことは仮実装という概念です「。座標(1, 2)を与えたらgetXは1を返す」というテストをするとき、一番最初に実装するgetXの戻り値は1というハードコーディングでも良いというのは驚きでした。あるテストがあったときにそのテストを最低限の労力でグリーンにするということを念頭に置いて実装していくといいのかなと思いました。
後はレビューという時間があるのも新鮮でした。コードについて議論の経験に乏しい自分では皆の言ってることに納得しかできませんでした。もっと議論できるようになりたい。
改善点とか
終了間際に運営にフィードバックあったらお願いしますって言われましたが、TDDにより頭がパンクしていてその場ではまったく出てきませんでした。帰宅して、ブログに起こすにあたり思い当たる節があったので箇条書きでまとめます。
- デモのときにペアプロの解説が欲しかった(ドライバー・オブザーバーの役割等)
- (個人のレベルもありますが)課題が途中から急に難易度が高くなり実装を考える時間が大幅に増えたので、問題をもう少し簡単にしてもらえると実装を考える時間を減らしTDDに費やせる時間が増やせるのかなと思いました。
