イベントに参加された皆様、ありがとうございました。
そして、会場を提供してくださった株式会社ドワンゴさま、そして会場設営、配信設備等々ご尽力いただいた coji さんにお礼申し上げます。ありがとうございました。
久しぶりの java-ja でしたが、 java-ja はやはり java-ja でした。話していて本当に楽しかったです。まとめると、 TDD は黄金の回転なのでみんな SBR(Steel Ball Run) を読んでくださいね。
当日資料はこちらです(またも slideshare の埋め込みに失敗。なぜだろう?)
ペアプロのデモは id:kompiro とふたりで行いました。id:kompiro は前日 Twitter で無茶振りしたにも関わらず快諾してくれました。ありがとうございます。Eclipse のショートカット機能や Quick-JUnit プラグイン、そして Kent Beck が開発している JUnitMax のデモを行いました。なかなか面白いペアプロ & TDD デモが出来たのではないかなと考えています。
参加者全員で行うペアプロのお題には優先度付きキューをペアで作ってねというお題を出しました。会場を回っていろいろなペアのコードを見ましたが、同じ設計のペアは一つとして無く、思わずにやりとしました。ペアで相談して試行錯誤しながらコードを書いていくという経験をしたことがない方には、面白い経験になったのではないかなと考えています。
体験してもらいたかったのは、テストから先に書くことで How ではなく What から考えるという頭の転換を行うことと、テストを通す最小実装とリファクタリングを行うことで実装が自分が考えたよりもずっとシンプルになることです。しかしこれはいきなり出来るようになれと言っても出来ないものであり、やっているうちにだんだん出来るようになってくる類のスキルです。なので当日はその入り口、問題意識を持ってもらうところに立ってもらうのが目標でした。
TDD とコードのシンプルさの関係はもう少し強調してもよかったかもしれません。Java が﹁書ける﹂ペアほど、最初から複雑なコードを書く傾向がありました。その複雑性は、果たしてそのとき必要かどうかを考えてみましょう。必要かもしれないし、必要無いかもしれません。もちろん、複雑さが問題なわけではありません。たとえば複雑で汎用的なものを考えた結果手が止まる、もしくはコードに無理が生じてしまうならば、 TDD の旨味を生かしているとは言いにくいと考えます。大事なのはシンプルさとフィードバックです。必要なときに、必要なだけの汎用性を持ったコードを考える、書く、という訓練、コードを小さく産んで大きく育てるという考え方をもっと伝えたいと感じました。
もちろん、シンプル (simple) とナイーブ (naive) は違います。単純なコードを書けばいいと言うわけではありません。ある制約条件を満たすシンプルな設計/シンプルなコードから、仕様変更など状況が変わった新たな制約条件下でもシンプルさを満たすコードへ、シンプルな設計を次のシンプルな設計へとスムーズにつないでいくことが TDD (特にリファクタリング) の姿です。このことを今後また伝えていきたいと思います。講演で私がもっと意識して話さなければならないことを教わりました。ありがとうございます。
また反省点として、講演では喋りすぎました…私が喋りすぎたおかげでペアプロ時間が短くなってしまいました。本当にすみませんでした。なので可能であれば TDD 企画第三回を近日中にやりたいです。こんどはペアプロの説明だけ少しして、あとは参加者みんなでずっとペアプログラミング & TDD するだけの企画をやりたいですね。
話しているほうの私にも学びが沢山ある、実りのあるイベントでした。 java-ja に感謝します。ありがとうございました!またイベントやりたいですね!
そして、会場を提供してくださった株式会社ドワンゴさま、そして会場設営、配信設備等々ご尽力いただいた coji さんにお礼申し上げます。ありがとうございました。
久しぶりの java-ja でしたが、 java-ja はやはり java-ja でした。話していて本当に楽しかったです。まとめると、 TDD は黄金の回転なのでみんな SBR(Steel Ball Run) を読んでくださいね。
当日資料はこちらです(またも slideshare の埋め込みに失敗。なぜだろう?)
ペアプロのデモは id:kompiro とふたりで行いました。id:kompiro は前日 Twitter で無茶振りしたにも関わらず快諾してくれました。ありがとうございます。Eclipse のショートカット機能や Quick-JUnit プラグイン、そして Kent Beck が開発している JUnitMax のデモを行いました。なかなか面白いペアプロ & TDD デモが出来たのではないかなと考えています。
参加者全員で行うペアプロのお題には優先度付きキューをペアで作ってねというお題を出しました。会場を回っていろいろなペアのコードを見ましたが、同じ設計のペアは一つとして無く、思わずにやりとしました。ペアで相談して試行錯誤しながらコードを書いていくという経験をしたことがない方には、面白い経験になったのではないかなと考えています。
体験してもらいたかったのは、テストから先に書くことで How ではなく What から考えるという頭の転換を行うことと、テストを通す最小実装とリファクタリングを行うことで実装が自分が考えたよりもずっとシンプルになることです。しかしこれはいきなり出来るようになれと言っても出来ないものであり、やっているうちにだんだん出来るようになってくる類のスキルです。なので当日はその入り口、問題意識を持ってもらうところに立ってもらうのが目標でした。
TDD とコードのシンプルさの関係はもう少し強調してもよかったかもしれません。Java が﹁書ける﹂ペアほど、最初から複雑なコードを書く傾向がありました。その複雑性は、果たしてそのとき必要かどうかを考えてみましょう。必要かもしれないし、必要無いかもしれません。もちろん、複雑さが問題なわけではありません。たとえば複雑で汎用的なものを考えた結果手が止まる、もしくはコードに無理が生じてしまうならば、 TDD の旨味を生かしているとは言いにくいと考えます。大事なのはシンプルさとフィードバックです。必要なときに、必要なだけの汎用性を持ったコードを考える、書く、という訓練、コードを小さく産んで大きく育てるという考え方をもっと伝えたいと感じました。
もちろん、シンプル (simple) とナイーブ (naive) は違います。単純なコードを書けばいいと言うわけではありません。ある制約条件を満たすシンプルな設計/シンプルなコードから、仕様変更など状況が変わった新たな制約条件下でもシンプルさを満たすコードへ、シンプルな設計を次のシンプルな設計へとスムーズにつないでいくことが TDD (特にリファクタリング) の姿です。このことを今後また伝えていきたいと思います。講演で私がもっと意識して話さなければならないことを教わりました。ありがとうございます。
また反省点として、講演では喋りすぎました…私が喋りすぎたおかげでペアプロ時間が短くなってしまいました。本当にすみませんでした。なので可能であれば TDD 企画第三回を近日中にやりたいです。こんどはペアプロの説明だけ少しして、あとは参加者みんなでずっとペアプログラミング & TDD するだけの企画をやりたいですね。
話しているほうの私にも学びが沢山ある、実りのあるイベントでした。 java-ja に感謝します。ありがとうございました!またイベントやりたいですね!
