TDD Boot Camp 横浜に参加してきた #tddbc

勉強会 TDD


(写真：ペアプロ＆レビュー時の1枚。)

関東圏では2011/10/08『TDDBC 東京 for c++』以来となるのTDD Boot Camp。しかも開催地が横浜(且つ家から超近い!!)という事で募集には即申込み。晴れて抽選に当たる事が出来たので、参加して来ました。


開催地はあーすぷらざ（神奈川県立地球市民かながわプラザ） ＠本郷台。京浜東北線/東海道線等の『大船駅』から程近い場所に位置するところになりますね。私からすると馴染み深い『ホーム』でしたが、多くの参加者の方からすると『アウェー』な地でもあったようです。(^.^;)

家からは距離にして約7km程、時間にしても20分程で到着する場所。高台からも開催地の建物を臨む事が出来ます。何というスケール感...(笑) 近辺を良く通ったりもするのですが、ここまで規模のデカい建物があったという事は認識してませんでした。

はじめに

開始予定時刻となり、主催者の@setoazusaさんからの会場及び全体に関する諸説明。2009年12月から始まったTDDBCも次第に全国展開されてきており、関東圏での人気の高さ(告知即定員達成)、札幌の開催頻度の多さ等に言及。

前回私が参加した『TDDBC東京1.6』以降今回の『TDDBC横浜』開催前までに行われた全国のTDDBC関連イベントは以下。

また、今回はレビューの時間を多めに取るという事もコメント。実際レビュータイムはかなり濃厚な時間となっておりました。

基調講演

講演の詳細は前回参戦した『TDDBC東京1.6』のレポートに詳細をまとめてありますのでそちらをご覧ください。

…と普段皆様から使われているメソッドをセルフで使ってみる(笑) 内容的には『基調講演』＋『講演(続き)』＝今回の『基調講演』となる形ですね。今回参加された場合の振り返りもある程度カバー出来るかと思います。


なのでここでは『差分』的に印象に残ったトピック等を幾つか挙げるに留めておく事に。

  • 自己紹介のくだりにて：『ネットデビューされる方は、ハイフンを使わない方が良いですよ。』
  • 『黄金の回転』紹介後：各地で"黄金の回転"のフレーズを広めているのだが、(元ネタとなっている『ジョジョの奇妙な冒険』で扱っている範囲が)第7章なのであまり通じていない感がある。
  • なぜTDDをするのか→私たちは完璧なプログラマではない。という流れで『でもNodeフェスにはいました。』
  • 『変化に対応出来るのは健康体のチームである』のくだりで『健康』の文字。『レッドブル3本目だ…などという光景は、人生として健康では無い。…言ってて辛くなってきた。』。
    • 参加者がこぞって写真に収めようとする様に対し『写真を撮らないでください!』→と言いつつもひと息ついたタイミングで"験を担ぐ"とRedBullを飲む和田さん。
      • はい、私も今回のTDDBCではバッチリ3本飲みました。(一応5本は用意してあった。※185ml缶×5) 全日掛かるようなイベント・勉強会では私は開催の度に健康では無い日を送っております…(´・ω・｀　)(笑)


  • TDD導入効果の簡単な説明として『実装時間が2割増え、バグが半分減る』というフレーズ
    • 最近は『半分減る』というのは過少評価では？という声を聞くことがある→『6〜7割減ります』と少し増やした形でいう事も最近はある。
  • TDD導入効果による『開発工数を50%減らすと感じた』：軽微なバグの入り込む隙が格段に減った事による効果。
  • テストの無いコードが既に沢山ある事に対する書籍紹介『レガシーコード改善ガイド』
    • 書籍オビの『テストがないコードはレガシーコードだ!』の文章は、実は@setoazusaさんご提案によるものだった。(TDDBCトリビア)
(追記)@setoazusaさんからコメントを頂きましたので転記。帯文に上記の文章が掲載された経緯には以下の様な経緯があったそうです。
-----
「レガシーコード改善ガイド」の『テストがないコードはレガシーコードだ!』の下りのところなんですが、
原著の"To me,legacy code is simply code without tests"を使ったらどうかと提案したのは確かに私なんですが、
それを『テストがないコードはレガシーコードだ!』と訳した人となると、それは訳者の方か翔泳社の編集さんだと思うので、申し添えておきます。

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

Working Effectively With Legacy Code

Working Effectively With Legacy Code

上記の引用文はこちらでも確認出来ますね。

TDD&ペアプログラミング デモ

『神速さん×隣の人×ペアプロ』という、夢のような組み合わせでの実演デモが今回実現。Java環境(JUnit/Git)及びRuby環境(RSpec/Git)におけるペアプロを2人で続けて実演されました。

  • 『とりあえずどうしましょうか？』(@tosikawaさん) 『先にソースフォルダを作りましょう』(@sinsoku_listyさん)
  • 『ペアプロの最中、ショートカット操作等で「早過ぎる！」と思ったらそこでツッコミ入れておいた方が良いですよ」(@sinsoku_listyさん)
  • 『あの、胸を押さえないでください』(@tosikawaさん) 『いや、緊張して…』(@sinsoku_listyさん)
  • 若干ぎこちないやり取りに『いつもこんな感じで、日本語コミュニケ−ション成り立たない状態でやり取りしております』(@tosikawaさん)

と言った感じで、当人達が緊張の面持ちで作業を進める様を温かい目で見守る参加者、という和やかな雰囲気でペアプロデモは続きます。時折参加者からの質問が入る一面も。

また、とある操作時に見かねた和田さんが2人に近寄り指導・解説を加える一幕も。

昼食＆昼食LT

お昼の時間内ではLT発表も行われました。皆さん昼食を摂りながらのLT拝聴。

LT：Quick JUnitのご紹介


  • Javaの皆さん
    • EclipseでJunit実行時どうしてますか？
    • Macの時はショートカットめんどい→TDDBCスタッフ担当時は聴かれても『知らん！』と返すのが常。
  • (Quick JUnit実演デモ)
LT：私とTDDと研究と


  • 自己紹介
    • TDDBC2福岡やります（焼き肉！）
  • TDD研究の区分
  • 書籍『Making Software』

Making Software ―エビデンスが変えるソフトウェア開発

Making Software ―エビデンスが変えるソフトウェア開発

  • TDDは学ぶのが難しい
  • TDDは一人でも始められる？
    • 現状厳しい：TDDBC需要が暗に語っている
  • ところでGitどうやってTDDプロセスを記録する？
    • git-nowの紹介
  • 通常コミットとTDD
    • コメント考えるノ面倒
    • リズムが崩れる
    • とりあえずgit-nowで良いじゃん
  • 手順詳細紹介
    • TDDxGit練習編（TDD重視）
    • TDDxGit練習編（Git重視）
    • TDDxGit実践編
  • 詳しくは入門書籍等を参照してください。

Gitによるバージョン管理

Gitによるバージョン管理

入門Git

入門Git

入門git

入門git

  • いつコミットする？
    • 手動ならgreen時
    • gitnowを使うなら対話的rebase必須

エビデンス（証拠）

    • 定量的な方が大事(経験的な方より)
  • 定量的効果測定
    • プロジェクトに導入した効果を計る
    • ここでは相対値が主流
    • 善し悪しを分析する
      • TDDが有効化どうか
      • 印象
      • 外部品質、内部品質
  • エビデンスを求める理由
    • その手法が有用か
    • 導入のための説得材料
    • 導入するかの判断材料
  • ちなみに
    • 日本の学術期間や個人で効果測定を行う事は難しい。
    • というわけで誰かやってみませんか？
  • TDDの応用
    • 詳しくはテストウェア総集編を参照。

ソフトウェア・テスト PRESS 総集編

ソフトウェア・テスト PRESS 総集編

  • まとめ
    • TDDの研究はいろいろある
    • データ欲しい
    • gitかわいいよgit
LT：テストリストの探し方

前日の最終便の飛行機で札幌から遥々参加された渡辺さんでしたが、到着時の羽田空港で大変だったようで…

これらを受けての、スライド資料一発目がこちら。要チェックですね。

  • 札幌は6回のTDDBC開催。
  • 自己紹介
  • TDDのサイクル
    • 設計
      • Q.どのくらい事前設計すべき？→A.何を構築すべきか分かるまでです。
        • 正論だが、解決していない...
    • 何を構築すべきか？
      • 1.設計
      • 2.テストを書く
      • 3.コードを書く
      • 4.動くようにコードを書く
      • 5.整理する
  • テストリストが作りづらい理由
    • 細かすぎる着目点
      • 少しずつ、1歩ずつ、TDDのこころ
        • TDDを実践するには小さく細かく
        • →そのまえに全体を把握しているか？
      • 利用者視点で考える。
        • エンドユーザ
        • 開発者
        • 利用者の興味あること/無いこと
      • 利用シーンに着目する
      • 外部境界に着目する
      • お題：野球のスコアブック
        • ＊＊＊出来る
        • 選手の打率ランキングを表示する
    • 曖昧な仕様
      • 入出力弐着目する
      • 具体的に考える
        • どんな入力でどうなるか？
        • テストで入力値と期待値となる
      • 選手の打率計算：
    • 複雑な仕様
    • 大きすぎる仕様
      • 小さく分割しよう。
      • 大きいものを分割する
        • フローやシーケンスで分割
        • 役割や責務で分割
        • 結びつきの強い属性を分割して独立
      • 足りない機能を追加する
        • addメソッドで商品を追加出来る
    • 不慣れな分野/パターン
      • プロトタイピング
        • とりあえず作ってみる
          • コードは後で捨てる
        • 必要なテストを見つける
        • テストファーストは原則
  • まとめ
    • 最初に具体的なUCをイメージ
    • 小さく分割
    • イメージがわかないならプロトタイプ作成

TDD&ペアプログラミング 実習 / コードレビュー

TDD&ペアプロ実習に先立ち、和田さんと神速さんペアで再度ペアプロデモの実践が行われました。神速さん曰く相当緊張されておられたようです。まぁ確かに気持ちは分かります…(^_^;) あの和田さんとのペアプロですし。


そして言語別に席替えを行い…いよいよTDD&ペアプロ実習開始。

今回のお題は『野球の打率計算』に関するもの。主催者である@setoazusaさんの趣味的な部分(審判資格保有)も反映してのお題となっておりました。(※ちなみに以下にベースとなる課題内容が事前にUPされていました。若干の変更があるものの、ほぼ同じ内容となっています。)

私は前回同様Javaを選択。ペアとなった方はTDD自体はそこまで経験されていなかった様でしたので(と言いながらも自分もそこまで経験は多くは無いのですがね…(^^;)(笑))、課題をこなすスピードを求めるよりも、より『黄金の回転』をしっかり回す(レッド→グリーン→リファクタリング)方向に意識を置いて進めて行きました。

後半(終盤)課題を進めて行くに当たり私の方がキーボードを占有してしまう状態もあったのですが(ちょっと反省)、それを除けば概ねお互い満足の行く進め方が出来たのではと思います。意識のズレがあったところを会話を重ねて意識合せしていき、お互い気が付いたところがあれば立ち止まって対応策・方向性を検討して行く。レッドからグリーンにした段階で『この時点で振り返る、リファクタリングする要素はあるか』と考える(必要があれば対応する)などなど。

個人的にはやはりテスティングのスキル(JUnit等のライブラリに関するもの、テスト手法等)であったり、そもそものJavaライブラリやAPIのスキル(現場だと意外と共通ユーティリティ等を多用しがちな部分はあるので、プログラミングの定番的な処理についてスラスラと出てこなかったりする)が咄嗟に出て来ず時間をその辺りの把握に費やしてしまうなどあったのでその辺が反省点というか今後の課題ではありますね。ホントはテスト関連の書籍等を十分写経してから臨みたかったんだけど時間取れなかった...(^^;)改めてこれから精進していかねば。

JUnit in Action

JUnit in Action

Effective Java 第2版 (The Java Series)

Effective Java 第2版 (The Java Series)


コードレビューについては計2回、2時間近くの時間を費やして全ての卓(グループ)が発表を行い、レビュー・指摘を受けるという形に。言語も多岐に亘り内容を全て把握し書き留める事も出来なかったので、詳しくは今後UPされるであろう各参加レポートに期待。:-) 個人的には以下のポイントが印象に残りました。

  • 現実に有り得ないデータの検証をどこまで対応するべきか(例:5打数8安打とか)。時間が無くて対処せずで進めてしまったが、本来ならきちんと対処すべき箇所なのだろうな〜。
  • Javaペアのうちの1つ(@shuji_w6eさんの組)ではソースコード管理にBitBuckectを利用していた。また、Exercise/Verify、入れ子構造のテスト構成など勉強になる要素満載。ゆくゆくはこういうテストコードが書ける(ようなスキルを身に付ける)ようになりたいものです。(以下はソース管理ページ)
  • Groovyのテストコード、分かり易くて超綺麗!!(Spockによる部分の恩恵だそうです) ※Groovyチームは当初無かったのですが、イベント内で急遽誕生致しました。
  • 『パラレルチェンジ(parallel change)』について。単語でググっても出てこなかったけど詳しく紹介している記事・書籍等はあるのかしら？
  • なかやんさん(@pocketberserker)によるF#でのレビューも実施。後半の課題(記録の並べ替え)に関する実

装をわずか1行のソースコードで実現していた事に一同驚嘆!!

  • パラメタライズドテスト(Parameterized Test)について。
    • 上記Groovyの写真はこの処理に関する部分を表形式で実現可能としていた箇所の一幕。
    • Javaペア(@shuji_w6eさんの組)でも同様にJavaで実現させていた。
    • この件に関しては『パラメタライズドテストどこで失敗したか分からなくなりがちなのが難点。しかしgroovyはそこも対応している。ずるい言語』とコメント。

お知らせ

TDDBCのイベントの中で1つの告知というかお知らせがされていたのでここでご紹介。

Developer Testtingに関する話題を提供するWebマガジン、「ぺけま」(xUTPマガジン)がこの度創刊(Webマガジン)。

2009年3月から2011年3月まで行われたGerard Meszarosの xUnit Test Patterns(xUTP)の読書会のコミュニティを母体におり、xutp読書会で得られた知見を紹介する場所として今後継続的に発行を行っていくようです。

xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))

xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))

内容もボリュームが多く、充実したものとなっています。皆様も今後御覧になってみて／チェックしてみてはいかがでしょうか？

また、ほぼ同じ母体で活動を行っている通称『goos本』の読書会も現在活動進行中です。次回予定は現時点では未定ですが、開催の際は是非足を運んでみてはいかがでしょうか。

ふりかえり

各自思いついた内容を付箋に記載し、会場内のホワイトボードに貼り付け。@setoazusaさんがそれらを読み上げるという『ふりかえり』のお時間。

非常に多岐に亘った内容の振り返りでした。概ね好評であり、良い改善のアイデアが多く出ていましたが、唯一残念だったのは『ネットワーク回線』の問題でしょうか。地理的に(地下階？)電波の届き辛い状況であったために、つぶやきやその他ネット活動に支障が出てしまっていた部分は否めませんでした。Tryの中には『ジョジョの奇妙な冒険:第7部を読む』といったユニークなものも(笑)

懇親会

トータルで2次会まで開催されたのですが、私は1次会(於:会場内レストラン)のみ参加。参加人数も総勢30名以上は居たでしょうか。結構多かったような気がします。

会の中では、

  • 『Windows対応』って、対応することで不幸になる人を増やしている部分はあるよね〜
  • 神速さんに『GitとWindowsの相性の問題』を伺った。
    • Windows上でインストールやら何やら細かい作業をする位なら、Windows上にVMなり仮想でUbuntuとか入れて作業した方が早い。
      • (こういうお話を聞くと、やはりMac端末は今後用意して扱えるようになるべきなのかな〜と強く実感。)
  • @shuji_w6eさん
    • 最近のカオスなお話：言語がアレなのにアレ過ぎる環境に一同驚愕＆戦慄...(笑)
    • テストライブラリに関する造詣の深さには心底敬服致しました。
    • そいえばSlim3/Scenic3/PirkaEngine辺りについてもお話伺おうかなと思ってたけどこちらの準備不足もあり聞けなかった。まずはSlim3/Scenic3/PirkaEngine周りの写経始めないとな。
  • IEとの戦いに挑む和田さんのお話。こちらも内容を伺うとあんまりな(→InternetExplorerが)内容ではありました。

と言った感じでそれぞれに内容の濃いお話を聞くことが出来ました。

一日を通じて有意義な体験をする事が出来、@t_wadaさん、主催者の@setoazusaさん、TAスタッフの皆さん、参加者の皆さんにはお礼を申し上げたいと思います。ありがとうございました!!


懇親会会場ではTDDBCではお馴染みとなった『グリーンバンド』の販売も行われました。(1個￥500) 今回も2個購入。(当日ぶら下げていた『アジャイルサムライ』名札等と共に1枚。)


TDDについては東京1.6、そして今回の横浜で通算2回となったのですが、やはり現場や個人ベースでの継続的な研鑽は必要であるな〜と痛感。まぁTDDを含め、Agile/Scrum/CI/TDDと言った開発サイクル全般のスキル底上げと言った方が良いのかも知れませんが...。まずはTDDスキルの底上げを行うべく課題/TODOを洗い出し、実践していこうと思います。(TDD東京1.6に続き、2度目の決意)


その他関連ブログ等：