『TDD Boot Camp 札幌』に行ってきましたヨ
土日は『TDD Boot Camp 札幌』に参加させて頂きました。
http://atnd.org/events/11270
http://atnd.org/events/11271
ざっくりな流れとしては
一日目
二日目
- @t_wadaさんのセッション。レガシーコードと戦うために
- 『Emergent Design』
- 『レガシーコード改善ガイド』…現実と戦う
- 『データベースリファクタリング』…データと戦う
- 『XUnit Test Patterns 』
と言った感じ。
TDDBCの感想
今回の参加により「テストコードの作成に自信が付いた」というのが非常に大きな収穫だったように思います。
というのも、いままでテストコードの作成は出来る限りやってきてはいたのですが、
- 何が正しいか？どうあるべきなのか？
- よりよいテストコードを書くためにはどうすればいいのか？
- 深みにハマらないためには？
といったテストコード作成そのものへの不安というのがあったからです。
周りにテスト好きな人間があまりおらず、また自分自信のテストケース作成の理解不足からいつも「これでいいのか？」という思いがあったので、TDDのいう「開発のためのテスト」という目的が理解しづらい状態でした。
TDDの話をネットでみたりすると「TDDは品質を上げるためのものではない」という話がよくでてくるのですが、私のそれまでの理解は「テストをすれば必ず品質が上げるわけではない」と言った話と同系列のように理解していたように思います。
つまり全然間違っていたのですが。
これは@t_wadaさんのいう「TDDは開発のためのもの」「テストは目的ではなく手段→最大の理由は工学的なものでなく心理的な物」という話で理解が進んだような気がします。
また、やっぱり単純に「テスト」というと「品質」というイメージがあって（これが@t_wadaさんの言う「テストという言葉の混乱」の話そのものなのでしょうが）、仕事でTDDを実践しようとする際の説明で非常に困っていたところなのです。
品質を上げるためのテストとしてTDDを理解していると、「品質を上げるために過度な網羅性が要求されたりすると、Mockだらけになって、テストが極端に肥大化して、結局ソースやテストケースを修正する気が起きなくなるのでは？」という疑問から離れらない。
これが「TDDは開発のためのもの」という話で方向性とその範囲が見えたような気がしました。
あとペアプロはいろんな発見があっていいものですね。
人のペアプロを見学するのだけでもかなり勉強になりますし、実践するともっと得られるモノがあります。
職場でも取り入れていこうと思いました。
あと、例のJavaの認定のソースは香しいです。芳醇の時です。
また、ジャンケン大会で『プログラマが知るべき97のこと』を頂きました。（ありがとうございます！）
これも読んで感想をブログにでも書いていきたいです。
最後に
@t_wadaさん、体調が優れない中、二日間に渡りありがとうございました。今後は「act_as_professional」の精神でコードと向きあっていきたいと思います！
また@shuji_w6eさん並びに運営の皆様、参加者の皆様、お疲れ様でした。
得難い良い体験ができ、非常に充実したイベントでした。次回もまたぜひ宜しくお願いいたします。
