TDDBC名古屋に参加してきましたー #tddbc

7月10〜11日の2日間に渡って開催された「テスト駆動開発」について勉強しようというイベント(合宿?)、「TDD Boot Camp 名古屋」に参加してきました。 id:t-wada さん、 id:bleis-tift さん、名古屋アジャイルの皆様、開催して頂きありがとうございました。お陰様でTDDについてモヤモヤしていたものが晴れました。
というわけでその感想について書きたいと思います。




僕以外の参加された皆さんの記事はこちらにトラックバックされていますので是非ご覧ください。
http://blogs.yahoo.co.jp/nagoya_agile_study_group/32506622.html


イベントは下記のような構成で行われましたので、それぞれについて順番に感想などをまとめたいと思います。

1日目 午前
和田さんによるTDDについての講演+デモ
1日目 午後
ペアプログラミング+TDD+コードレビュー体験
1日目 夜
いろいろ自重しない議論
2日目 午前
レガシーコード改善についての講演+デモ
2日目 午後
レガシーコード改善の実習

1日目 午前 和田さんによるTDDについての講演+デモ


和田さんによるTDDとはどういったものなのか、何が大切なのか、また実践した結果どのような成果が出るのかといった講演と実際にどのように行うかのデモが行われました。
で、そのまとめがこちら↓です。

TDDBC 1日目の和田さんの講演を聞きながら作成したマインドマップ

1日目 午後 ペアプログラミング+TDD+コードレビュー体験


言語ごとにわかれてペアを組み仕様書公開→ペアプロ&TDD→コードレビューと行い、一区切りついたところでペアを変えての恐怖仕様変更といった感じの事を行いました。で、感想としては・・・


最初はどのテストから書くのかとかに結構悩みましたが徐々に感じが掴めてきたのでよかったです。自分でTDDをやってみた際にも最初にどのテストから書くのかや、書くテストはどのようなものにするのかとか結構悩んでいたのですがそれなりに答えが見つけれたような気がします。
ペアプロによって思い込みによる間違いを回避できる事やナビゲーター役の際に冷静になれる事はコードの質の向上にも繋がり、結果としてはバグによる出戻りが少なくなって時間の短縮にもなるように思いました。また、技術の伝達という点でもチーム全体のレベルが上がって開発スピードが上がるんじゃないかなと。
コードレビューについても今回は全員が同じ課題だったこともあり、同じ問題に対しても様々な考え・解決法があるのを知れてよかったです。どのようなテストを書くのかとかの参考にもなりましたしね。また他の方からの指摘によって気づいてなかった問題に気づけるのも凄くいいなと思いました。

1日目 夜 いろいろ自重しない議論


せっかく技術者が一つの所に集まってるのにそのまま寝ちゃうのは勿体無いよね?ということでとりあえず僕はこちらの研究に協力しに行く id:a-hisame さんと一緒に別室へ。データは多い方がいいらしいという事なのでハッシュタグつけて呼びかけてみたらどんどん集まって1室に13名集まるというカオスな状態となりましたw やってた事は…

とかが行われていました。
そこまで深く「クラス」や「インスタンス」について考えた事なかったので「クラスはインスタンスの集合である」のかどうか議論は面白く勉強になりましたね。

2日目 午前 レガシーコード改善についての講演+デモ


前日に引き続き和田さんによるレガシーコード(テストのないコード)・データベース・テストコードなどの放っておくと変更する際の足枷となるものと戦う際の心得などについての講演とレガシーコード改善のデモが行われました。
講演についてのまとめはこちら↓
TDDBC 2日目の和田さんの講演を聞きながら作成したマインドマップ


デモはStrParserという渡された文字列に区切り文字が含まれていたらそこで分割した配列を返すメソッドのみで構成されたクラスの改善でした。
手順としては現在の動きを正確に仕様化したテストを作成し、その動きが変わらないようにリファクタリングしようというものでした。本当ならこう動かないといけないというものを作成しないのは講演でも説明があったのですが、どこかにそのバグに依存した動作をするクラスがあるかも知れないからです。
今回実際に行われたテスト追加の手順は、忘れてる部分もあるので前後したりするものがあるかも知れませんが大体以下の感じで行われました。

  • インスタンス生成のテスト
  • とりあえず空文字を渡して何が返ってくるか調べる
  • nullを渡してみる
  • 区切り文字の内1つを試してみる
  • 優先順位があるっぽいので試してみる
  • 区切り文字だけを渡してみる

などといった風に思いつく限りにものを試してみて仕様化していくといった感じでした。

2日目 午後 レガシーコード改善の実習


午後からは実際に戦ってみましょうということで言語ごとに別れ、グループによる参加者が提供したレガシーコードの改善です。
僕の選択したJavaは人数が多かった為にさらに2つに別れてちょっとした対決っぽい感じで始まりました。ちなみにこのJava組にはTwiListEditorのソースコードを提供させて頂きました。
始まりはそんな感じだったのですが僕のいたチームはSwingやTwitterを知らない方が多かったので、これは難しいなという事でデモで使用したコードを引継ぎ、改善+仕様変更となりました。
で、その成果がこちら↓です。

2日目 レガシーコード改善 Java組 StrParser

当日はコミット忘れが結構あった為、リンク先の履歴はアップする前に当日行った手順を思い出しながら作成したものです。ので、もしかしたら当日の手順とは違うとこがあるかも知れませんのでその時はごめんなさい。でも支障にはならないと思いますのでよろしかったらご覧ください。
また、他の方の成果物などもこちらに集められています。

Google Code Archive - Long-term storage for Google Code Project Hosting.

その後、成果物の発表会があったのですが言語ごとの問題や対策があって面白いなと思いました。

合間の休憩時間の議論などから学んだ事や感じたことなど


1日目の午後が終わった後に id:Nagise さんによるJavaジェネリクス談義があったのですが、使ってもコレクション的なものにしか使った事なかったのでここまでの事が出来るのかという事が知れてよかったです。


Java組は開発環境が見事にEclipse一色だったのですが意外と機能を使ってない方がいたので勿体無いなーと。特にリファクタリング機能は安全に素早くリファクタリングする事が出来るので、和田さんが講演されていたように黄金の回転をテンポよくする為にも必要だと思います。リファクタリングツールの有用性はバイブルであるリファクタリング―プログラムの体質改善テクニックにも書かれてありますし、リファクタリングが簡単に出来るという事はコードを改善するって事をもっと気軽に出来ていいと思いますので。
IDEIDEの機能を勉強の為にあえて使わないのは別として、楽する為に作られてるんじゃなくて品質のいいものを作る為に作られているんだから使わないと損ですよ!僕も知らない機能がまだいっぱいあって会場で教えて頂いたりもしたのでもっと勉強しなきゃなですがw


レガシーコード改善で思ったのですが、バージョン管理システムを使うというのも実習に入れてしまってもいいんじゃないかなと。というのもレガシーコードはいつどこで壊れるのかがわからないので、後から壊れてる事に気づく事も普通にあると思うんですね。そういう時にちゃんと管理してあれば履歴をたどって調べる事も簡単に出来るので必須に近いんじゃないかなと思いました。
理想的には事前に何らかのバージョン管理システムのインストールと設定を行ってもらっておいて、当日に最低限の説明をするとかそんな感じの事が出来たらいいなーと。というのも僕も一応Mercurialを使って管理しようとしたのですが、ナビゲーターの時にステップごとに奪ってコミットってのは時間のロスが激しいので中々難しくあまりちゃんと管理出来ないってのがありましたので。あと、バージョン管理システムは個人的にはフットワークの軽さからやはり分散型を推したいなと思います。


あと、レガシーコード改善で今回Java組が多くて2つにわかれたのですが、この際に対象コードに関係した知識やプログラミング歴とかを考慮した方がよかったなと。今回で言うと僕らのチームにTwitterを知らない方やSwingを使った事がない方が偏ってしまったように思うので、考えてれば同じコードを対象に競いあうというちょっと楽しい事をやれたんじゃないかと思いました。


個人的に一番楽しかった&よかったのはチーム開発っぽい事が出来たことですね。現在プログラマになろうと転職活動中ではありますが、現職はまだデザイナーでチーム開発とかしたことなかったので、みんなでプログラミングして自分以外の人の生のコードを見れたり考え方に触れたり出来た事はとても勉強になりました。また、TDDBCの内容自体がかなり実践に即したとても濃いイベントでしたので一気にレベルが上がったような感じがしますw


というわけでこのイベントは是非もっといろんな人に体験して頂きたいなと思いますので、僕が大阪で転職するのに成功した場合に限りますが、TDDBC大阪を開催出来たらなと思います。もし大阪以外に転職するって事になった場合はごめんなさいorz


最後に参加して多かった質問でも…
Q.なぜ触手なのですか?
A.http://favotter.net/status.php?id=3836526273

まとめ


STEEL BALL RUNスティール・ボール・ラン)はTDDの教本