読者です 読者をやめる 読者になる 読者になる

TDD Boot Camp Tokyo 2013-07 に参加しました!

TDD Boot Camp Tokyo 2013-07 に参加させていただきました。レポートではなく日記です。。

初めてのTDDBCで不安もありましたが、とても楽しかったです。
しかも、「実践テスト駆動開発」の著者 Steve Freeman さんが参加してくださるというサプライズ付きでした!
スタッフの方、会場を提供してくださった楽天さん、ありがとうございました!

なぜ参加したかったのか

忘れないうちに書いておこうと思います。
理由は、TDDの「実際」を感じたかったからです。
ユニットテストは書いていますが、TDDで開発を行ったことはありません。
今はプログラムを書く仕事から離れてきてしまっていますが、開発チームの開発力向上、また、自分のスキルアップのため、TDDに関する書籍やWebの資料を見ながら写経したりして勉強していました。
しかし、実際にTDDで開発してるわけでもないし、実際にTDDで開発してる人に出会ったことがありませんでした。
そんな状況で、漠然と自分が勉強していることは正しいのだろうか?・・・と不安になり是非今回のTDDBCに参加したいなぁと思った次第です。

やってみる

今回の課題は、自動販売機をプログラムで表現するというようなものでした。
ペアプロ->レビュー->ペアプロ->レビュー という流れで課題を解いていきます。
ラッキーなことに、2回目のレビューではJavaScriptチームの代表としてレビューしてもらうことができました!

ペアプロ初体験でしたが、これは楽しいですねー。
自分じゃ気づかない点に気づいてもらえるし、設計の議論もすぐできるし。
ただ、終わってみて気づいたのは、意外と消耗するなーということ。自分のペースで開発できない分、いつもより消耗するのかも。

TDDでは、TODOリストの作成が思いの外難しかったです。
TODOリストの作成というか、課題を細かい問題に分割する際に、どのくらいの分量を一度にテストして実装するか、の判断が難しかったです。
この部分は写経だけだと身につけるのは難しくて、色んなコードをTDDで書きながら感覚を磨いていくのがいいのかなぁと思いました。

黄金の回転、一つずつ少しずつ、この辺は実際にやってみて、プログラムに対する不安を取り除いていきながら完成に向かっていくのを感じることができました。
グリーンになるたびにペアの人と喜んで、こういう小さな成功体験がコーディングを楽しくしてくれるということも実感できました。

ペアプロは、設計に少し時間をかけたら深入りせずにテストを書いてみよう、という風に進めていました。最後の方は、色々なテストを書きながら設計について議論するという感じに。
テストを早めに書くことで、ユーザ側(オブジェクトの利用者)の視点に立てて、新たな気づきをくれるという場面に結構でくわしました。こういう点も開発を駆動してくれるということが実感できました。
ただ、テスト書く前に設計をどこまでやるのかという判断もスキルが足りず難しかったです。

ふりかえって

課題をやったり、TDDを既にやってる人・やろうとしている人の話を聞いたりして、自分の勉強してきたことはずれていなかったかな、と感じています。
@t_wadaさんの基調講演でも、写経は大事、量は質に変わる、とあったので今後も勉強を続けていきます。
あと、もう少し勉強して社内でもTDDBCのような勉強会を開いてみようと思います。
TDDBCにも何か貢献できたらいいなぁ。


TAのみなさま、親切に教えていただき本当にありがとうございました!