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 さんは、 グリーンバンドを見て、やる気を奮い立たせているそうだ。
吉岡さん(@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さんありがとうございます。この反省点は二つです。
- 予習するなら、要求される環境でちゃんとやっておく。 今回、IntelliJもちゃんとやっておくべきだったなと思いました。
- ワークショップ中であっても、落ち着いて行動する。 私が忘れてしまった内容はSpockのトップページを見れば一目瞭然の内容で、その時冷静にググってれば割と早くSpockで始められたと思います。
今回の演習課題
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」
関連書籍