ゆるふわ.rb　in 大洲　〜刺身とお寿司とTDD〜 を開催しました

勉強会 ゆるふわ

GW後半戦のまっただ中の 5/4(日) にゆるふわ.rbを開催しました。
今回はお寿司を頂きながらTDDを実践する場としました。
ゆるふわ.rb in 大洲 〜刺身とお寿司とTDD〜 - ゆるふわ.rb | Doorkeeper

チェックイン＆TDDライブコーディング

はじめに参加者のみなさんに自己紹介・・・の予定だったんですが、自己紹介が必要ないくらい集まったのは顔見知りの方ばかりだったので、そこはサクッと済ませてTDDライブコーディングに入りました。
ライブコーディングでは以下の３点をポイントとして ゆるふわ.rb in 大洲 〜刺身とお寿司とTDD〜 - ゆるふわ.rb | Doorkeeper に載せている「図書APIを作成せよ」という架空の問題に取り組みました。

１点目は、TDDの根幹はテスト技法ではなく設計技法なので、設計出来る部分はさっさと設計＆実装してからテストケースを書く方が効果が高いという観点に因るものです。
プログラマとして経験を積んでいけば「似た感じのコードを以前書いたことがあるな。たぶんこんな感じでイケるはず！」というショートカットが出来るようになってくると思いますが、テストファーストを原理主義的に守ろうとするとこの行動が抑制されてしまうことが多いと経験上感じているので、そんなことしなくていいよ、ということをポイントとして挙げました。

２点目は、テストコードとプロダクションコードを同時に書いていった場合、どちらにもバグを埋め込んでしまう危険性が高まるため、まず実際に動作させながらプロダクションコードがおおよそ自分の想定通りに動くことを確認してからテストコードを書く方が効果が高いという観点に因るものです。
もちろん単純明快なテストだったらテストコードにもミスは少ないかと思いますが、複雑になればなるほどその実装の難易度は高くなるので、それだけに縛られず、色んなツールを利用して自分の脇を固める方が良いと思っています。
今回はAPIの作成だったので、プロダクションコードを書きながら Advanced REST client - Chrome Web Store を利用してAPIの挙動を確認、おおよそ思い通りの実装が出来たと思った段階で spec を書いていくというような手順で実施しました。

３点目は、（１点目と少し似ていますが）TDDの根幹は設計技法であり、設計していくためには「フィーチャーテスト =>ユニットテスト」という outside-in なアプローチでテストケースを書いていった方が効果が高いという観点に因るものです。
ほとんどの方が設計をする場合は「外部設計 =>詳細設計」と outside-in のアプローチを取るものと思いますが、これに合わせてTDDでも同様のアプローチをとる方が良いと思っています。

刺身とお寿司とTDD

次にゆるふわ.rb 恒例のビアバッシュ、という名の自由時間でした（笑）
今回は刺身とふぐの湯引きとお寿司と酒という、なかなか豪華な感じでした。
私は前日に飲んでたのもあってあまり飲めなかったんですが、TDDについて語り合ったり、仕事観について語り合ったり、いつも通りの楽しい場となりました。

前日に仕込んだ鯛の昆布締めも好評でしたよ〜^^

チェックアウト

最後にみんなで洗い物してゴミを片付けて会場を後にしました。

今回は初めてライブコーディングをやってみましたが、その効果がとても高いことに気付かされました。

色んなものがオープンなこの時代、世の中のいたるところにコードが存在していて、それらを拝見することで色んなことを学ぶことができますが、そこにはコードの完成系しかありません。
どういう思考回路でそのコードに辿り着いたかはなかなか推測しづらいものです。

一方でライブコーディングでは、コーディングしていって、エラーになって、直して、コードが安定してきたらリファクタリングして・・・というようにコードが育っていく様を目にすることができ、（少しオーバーですが）プログラマ自身の思考回路をそこに見ることが出来るように思います。
その中には完成系のコードを見るよりも気付きや学びが多いように感じました。

ゆるふわ.rbでも、もっとこのような機会を増やしていければと思った今日この頃でした。