6月15日,16日に開催されました,TDD Boot Camp Fukuoka 2013に行ってきました! 2日間の濃密なBoot Campだった+ぺーぺーの学生だったので,それはまあ学ぶことが多かった週末となりました.全てをまとめると大変な量になってしまうので,学生なりの視点で参加したいきさつやこれからの決心に焦点をあてます.
ということで,後先考えずに模造紙に描きながら考えてみました.
そもそもTDDについては,学部3年の頃にかじっただけで,ほとんど経験がありません.最近ようやくテストを書くようにはなったのですが,なかなか思う通りに書けず悩んでいました.そんな時に開かれるTDDBC,ということで,熟練者のノウハウを盗みに,また昔わからなかったTDDのことも知れるなら一石二鳥だと思い,参加した所存です.
TDDBCは基調講演+ペアプロ+コードレビューの3つのプログラムで組まれていましたが,今回は印象に残った部分について注目しました.
黄金の回転を素早く回すことで,安心して開発を行うことができるのだと感じました.また素早く回すために,粒度を細かくしたり,順番をつけて開発していくので,消化するテンポもよくなり,気持ちよく開発できる環境になるのではないでしょうか.どことなくTiDDを彷彿とさせます.ペアプロでは,はじめにお題をTodoにおとしてから作業を行うのでまさしくTiDDでした.
1回目のお題ではこのTodoがうまくまとめることができなかったので,なかなか黄金の回転を回すことはできませんでした.そもそもペアプロ(Objective-C組はトリプロでしたが)自体が初めてで,どう進めればいいのかが手探り状態でいっぱいいっぱい.
2回目のお題ではペアの方やTAの方にたくさんサポートしていただきながら,Todoをまとめ黄金の回転を踏まえてコーディングすることができました.
どうしてTodoがまとまらないのかというと,お題から設計を組み立てることができないからだそうです.どうやって実現するかがみえていないと,もちろん不安を解消する適当なテストを書くこともできず,不安がつもる悪循環…….これまで大規模な開発は経験したことがなく(小さな規模のアプリばかり作ってます),設計を軽視してしまっていたのですが,今回のペアプロで設計の大切さを痛く実感しました.UMLの基礎をせっかく勉強したので,もう少し深く勉強してみようかな.
また,プログラムを書いてからテストを書くとき,いつも書きにくいと思っていたのですが,それはつまり実装したプログラムが使いづらいことだと気付いて,とてもぐらぐらしてます.テストを先に書くと,使う側の気持ちになるので,設計ができるできないに関わらずいい心がけになる気がします.
そんなわけで,TDDをぺーぺーの技術者が行いますと,設計の大切さが痛く実感できますので,むしろいいのじゃないかと思います.テストが書けるところはテストを先に,書けそうにないところはテストを後に,と臨機応変に開発へ取り入れ振り返ることで,徐々にテストファーストの比率をあげていこうと思いました.
まとめますと,TDDの前にもっと技術をみがけ!写経をしろ! というひとことに尽きてしまいますが,もっともなので意義なしです.写経頑張ります.
最後になりましたが,主催者の春山さん,講演してくださった和田さん,TAの方々、参加者の皆さん,AIPさん,ありがとうございました.
二日間お世話になりました!
返信削除USキーボードが怖いですw
模造紙まとめ、バッチリですね!
わかりやすいので、TDDのことを忘れかけたら、また見に来ます!
勉強会後に強く思ったんですけど・・・
前勉強して、できれば、TDDを実践した後で臨めたら、経験豊富な講師の方々から、実務に沿った的確なアドバイスがいただけたんだろうなぁって。
ってことで、写経はやるべきですね、やっぱり!
お互い、がんばりましょう!
こちらこそ2日間お世話になりました! Objective-Cでトリプロなんてとても貴重な体験になりました!
削除私は逆にJISキーボードが怖いです……w
学生らしさを全開に出してまとめてみました.わかりやすかったようで何よりです.
見直した時にはぜひツッコミお願いします!
TDDを実際に行っているとまた別の,もっといいお土産を持ち帰ることができたでしょう……が,TDDなんぞや状態でも十分お土産を持ち帰れたと思います.次回のブートキャンプではTDDを実践して経験を積んだ上で参加できるように頑張らないとですね!
まずは写経,がんばりましょう!