leashこの広告は、90日以上更新していないブログに表示しています。2013」に参加してきました。meetup#15に参加されていた@kompiroさんがファシリテーターをされているイベントです。あの永和システムマネジメントさんが会場ということで、中に入れるのも楽しみでした!CoderetreatってなにCoderetreatとは、ざっくり以下のようなルールでペアプログラミングを行うイベントです。コンウェイのライフゲームを実装する。45分/1セッションで、複数回のセッションをやる。セッション毎に成果物(コード、メモ)は破棄する。セッション毎に必ず異なるペアを作ること。1セッション毎に15分の振り返りを行う。よいコード、よい設計を作る練習をするのが目的。完成させる必要はない。Fukuiは単独イベントだったようです。Dayということで、世界中の都市で同時開催している会場のひとつになっていました。海外の会場とハングアウトを繋いで手を振り合ったりして、Coderetreatの空気を共有している感がすごく良かったです。参加するにあたっての目標CoderetreatではTDDが推奨されています。テストの重要性は理解しつつも、テストファーストと言われるとなかなか実践出来ていない現状があるので、次3つの目標を立ててから参加しました。経験者の方教えてくれくれちゃんです。TDDなコーディングと、普段のコーディングの両方やってみるがっつりTDDやってる人にナビゲーションして貰うTDDのメリットを実感する当日セッションでやったことsession#1TDD未経験な金大の学生さんと組みました。初回なので普段のコーディングスタイルでやろうということに。こんなインターフェースが必要だよね、内部表現は二次元配列にしようか、フィールドのはじっこの扱いどうしよう、みたいな話をしてざっくり設計、8割くらい実装したところで終わり。お互いライフゲームについてあまり予習していなかったため、問題を整理するためのセッションとして有意義だったと思います。session#2愛知から来られた社会人の方と組みました。休憩時間中にRubyでやりたい人居ませんかと声をあげたところ乗っていただけました。TDDでコーディングしてみたい旨を伝えると、RSpecでのTDDをナビゲートしてもらえることに。RSpecの書き方やrubyのゆるふわいい感じなコーディングが勉強になりました。セルの生死を表す定数を定義するのに、Stringオブジェクトを拡張するというアイディアが面白かったです。最初はSymbolをひも付けていてエラーが出たのも、なるほどsingletonだからかという気づきになりました。gem使えばいいんじゃない?と言われて、確かにと思いました。initしてくれるし-tすればRSpecも入るし、細かいファイル生成してくれるし(README)、小さなコードでも使うようにしようと思います。session#3おやつスポンサーでもある(ありがとうございます!)ナンバーフォーの方と組みました。session#2で書いたコードを手に馴染ませたくて、破棄したコードを思い出しながらコーディングしていました。あとは、世代交代のルールをシンプルに定義しなおしました。Javaメインの方に、ruby面白いですねと言ってもらえたのが嬉しかったです。世代交代のルールは、注目しているセルの状態、その周囲の生きているセル数をパラメータとするとこんな風に書けます。実装する役とテストを書く役でやろうと提案していただき、実装役をやりました。このペアプロ手法は、ping-pong(ピンポン)または「ぶつかり稽古」と呼ばれているらしいです。具体的には以下のステップでやっていました。テスト役はナビゲーター.2に戻るこれがかなり面白かったです。役割が分かれたことで、TDDをやる上で大きな負荷になる(と思っている)「実装する時とテストを書く時の頭の切り替え」がそんなに要らなくなることが大きいんじゃないかと感じました。実装役とテスト書く役を交互にやっていくうちに一人で回せるようになるならば、こんなに良い方法は無いと思います。ストレスなくTDDできてるということと、一人では辿りつけないところにいる感じとがあって、ペアプロ最高!って言いたくなるセッションでした。6金大の学生さんたちとひたすらping-pongしていました。テスト役をやったり、Gitを使って並列で作業してみたり。contextとletでDRY.ping-pongかなり良い!感想6回のセッションで、2つの目標は達成できました。TDDなコーディングと、普段のコーディングの両方やってみるがっつりTDDやってる人にナビゲーションして貰うで、その実践を元に「TDD(テストファースト)のメリットを実感できたかどうか」というと少し弱い手応えです。ストレスなくテストファーストで書けるようになれば、コーディングミスをした場合の問題の切り分けが楽(細かくテストするため)だろうなとは思います。セッション中にあまりリファクタリングする機会がなかったのもあるかもしれません。それから「TDDな設計ってなんだろう」という疑問が残っています。正しい実装を保障するためにテストを書くのであって、正しい設計がテストによって導かれる(?)というのはよくわかりません。今回だって一回目にテストなしのコードを書き捨てながら問題を整理して、それからでなければTDDできなかったように思います。良さを知る事ができたのが一番の収穫だと思っています。実感が得られないというのもまだまだバットを振った回数が少ないんだろうなと。kanazawa.rbでは先輩エンジニアにぶつかり、学校では部活の後輩にぶつかられながらTDDを学んでいこうと思います。おわりに主催して下さった@kompiroさん、スポンサー企業の方々、ありがとうございました。次の機会に福井で参加できるかはわかりませんが、Coderetreatの面白さを周囲に伝えていきたいと思います!おまけお寿司おいしかったです。