TDDBC 大阪 2.0 参加してきた #tddbc

待ちに待った念願の TDDBCに参加することができました!

主催者の皆様のおかげで、今回は、 6/2 土曜日、6/3 日曜日の二日同じ内容をやっていただいていました。なぜなら、人気がありすぎて、すぐに 満席になってしまうくらいに人気で、それだけこの勉強会に参加したい方が多いって事でしょうね。

募集ページ
みんなのポジションペーパー

タイムテーブル

0930〜1000 受付
1000〜1010 会場説明
1010〜1040 和田さん講演
1040〜1110 吉岡さん or 咳さん講演
1110〜1120 休憩
1120〜1200 デモペアプロ
〜1300 ご飯食べながらペア決めしながらアイスブレイク
1300〜1530 演習と休憩
1540〜1610 関さんの講演
1620〜1650 テーブルレビュー
1700〜1730 講師・TAトークセッション
1730〜1740 KPT
1740〜1750 和田さん振り返り
1750〜1800 おわりに

和田さん(@t_wada)講演

ここでは、TDDに関する基本の考え方について学びました。TDD自体は聞きかじった程度で、ちゃんと人のお話を聞くのは初めてでした。ここで学んだことを以下に列挙します。
  • ソフトウェア開発の3本柱:バージョン管理、テスティング、自動化
  • テストに関する感覚は皆違う。
  • TDDの「黄金の回転: Red、 Green、リファクタリング、のサイクル。
  • プログラムを作成する時は、自分が最初のユーザーである事を意識すること。
  • テストを書いて、自分のコードに自信を持とう。
  • 「CleanCode」の著者、Robert C. Martin さんは、 グリーンバンドを見て、やる気を奮い立たせているそうだ。
参考:@t_wadaさんの事がよくわかるインタビュー記事

吉岡さん(@hyoshiok)講演

資料
楽天に勤めていらっしゃる吉岡さんの発表は、TDDとか自動ビルド等の歴史が分かる発表でした。
  • 1980年とか、それくらいからTDDとか、継続的インテグレーションの始まりのような開発をされていたと聞いて、ビックリ。
  • チェックアウト→コード修正→他の方のレビュー→チェックイン:レビューは大事ですね。
  • デイリービルド:ビルド専用のマシンが複数台あり、その日のチェックインをビルド、エラー時は即時ロールバックした。
  • テストプログラムは、他人の作ったコードのテストだけやるようにした。
  • 吉岡さんが会ったハッカーは、高い技術と、コミュニティをを大事にする心、を持つプロフェッショナルである。
  • テストのないコードはレガシーコードだ!

デモペアプロ

ペアプロは@t_wadaさんと@irofさんによって行われました。お二人とも楽しそうにペアプロされていました。

ワークショップ

私のペアプロのお相手は、@yoshi_naoyukiさん。若くてやる気のある方でした。今回私は、Groovy希望で受けさせていただいたのですが、当日@kyon_mmさんが「Groovy(Spock)でやりたい人?Javaが書けるならGroovy(Spock)で楽しくできるはずですよ〜」って呼びかけしたら、およそ10人くらいの方が手をあげられていました。これが「Javaと仲良くやっていくGroovyの力」なのか?呼びかけした@kyon_mmさんのカリスマ性なのか? おそらくは両方でしょう。

ペアプロの前に、まずは環境設定をしました。今回はIntelliJidea + Spockでペアプロを行いました。PCは、@yoshi_naoyukiさんがお持ちのパソコンの方が、画面が広かったので、お借り致しました。@yoshi_naoyukiさん、ありがとうございました。

実際にペアプロをやってみると、まず事前にやったはずのSpockの構文を私が すっかり忘れてしまい思ったように進みませんでした。結局、@kyon_mmさんにお教えいただき、分かるようになりましたが、少し時間をロスしてしまいました。@kyon_mmさんありがとうございます。この反省点は二つです。
  1. 予習するなら、要求される環境でちゃんとやっておく。
  2. 今回、IntelliJもちゃんとやっておくべきだったなと思いました。
  3. ワークショップ中であっても、落ち着いて行動する。
  4. 私が忘れてしまった内容はSpockのトップページを見れば一目瞭然の内容で、その時冷静にググってれば割と早くSpockで始められたと思います。
目の前にいた@hideokuさんにも質問させていただきました。ありがとうございました。

今回の演習課題
Spockについて@kyon_mmさんに教えて頂いたおかげで、TDDBCに集中できました。用意されていた課題は、「飲み物自動販売機」プログラムをTDDを用いて書いていくものでした。二人でしながらプログラムを作っていると、これが 「楽しい」と純粋に思えました。それぞれが個人の主張を貫き通すわけではなく、議論しいい方を採用しながらプログラムを作る、こういう経験はなかなかできません。とてもいい経験になりました。TDDについては、最初はテストファーストを意識していましたが、途中から「最初からグリーンバーが見える書き方」に移行してしまった私に対し、ペアプロ相手の@yoshi_naoyukiさんは冷静に「テストファースト」を考えておられました。これは、 @yoshi_naoyukiさんの長所ですね。

私たちはステップ2の途中で、タイムアップになりました。あまり進みませんでしたが、とにかくあっという間に感じるほど、集中できたし、楽しい時間でした。

関さん(@m_seki)講演

関さんのお話は、TDDをより進化させるお話でした。
  • 手動テストもいいよ?
  • たまには、デストロイしてみては?
  • レガシーコード改善ガイドを読もう。

TAさん達のパネルディスカッション

  • TDD行う上でよく詰まるところは?他のコードやライブラリが必要な時の対処。
  • DB接続周りの対処。本物の環境を使ったり、もしくはDBスキーマの変更が激しい場合はmockでできるだけがんばるという意見も。
  • ログを吐き出すコードを書き、そのログを自動で評価する。
  • テストの効果の見える化が大事!

まとめ

Twitterのまとめ:TDDBC大阪 1.0 & 2.0
いやー、勉強になりました。主催、講師のみなさん、ありがとうございました。グリーンバンドを購入したので、新しい職場の机の上に置きました。この経験を元に、テストファーストの考え方を考えながら仕事をしていきたいと思います。 「acts_as_professional」

関連書籍