#tddbc Tyokyo 2013-03に参加してきました

3/16(土)に開催されたTDD Boot Camp Tokyo 2013-03 – TDDBCに参加してきましたので、レポートです。

 

ランチミーティング

今回のTDDBCは今年開催予定の福岡、長岡の主催者のサポートという意味合いがありました。そこで、イベント開始前にランチミーティングという形で、TDDBC開催に向けての相談をしてきました。

出席者は今回の主催者である@katzchangをはじめ、@t_wada、横浜の@grimerose、福岡を開催予定の@Spring_MT、そして私といった感じ。内容についてはまたTDDBC-MLTDDBC Wikiで共有しますので、そちらをご覧下さい。

 

キーノート

そして参加者が集まったところで、TDDBC開始です。すっかりおなじみとなったt_wadaのキーノートセッションです。

t_wadaのキーノートはスライドは何度も読んでいましたが、実際に観るのは初めてでした。もちろんスライドには乗っていないことが実際には多く、これはやはりセッションを観ないとわからないことが多いなと感じました。

メモから起こしてみます。

  • TDDBCのメインは、実はTDDではなく「ペアプロ」
    • ペアプロは楽しい、そして疲れるw
  • コードレビューもポイント
    • 普段の仕事では同じ問題を複数人で同時に解くことはまずない。
    • 他の人、言語のコードと比較することができる。
  • ふりかえりもポイント
    • KPT(Keep、Probrem、Try)でふりかえる
  • ソフトウェア開発の三本柱
    • バージョン管理(一番大事!)
    • テスティング
    • 自動化
  • バージョン管理
    • 人間は忘れる
      • いかに記憶を専用ツールに任せるか
    • メンテナンスと新機能の並行開発
      • VCSなしでは困難
        • セーブなしでRPGをやるようなもの
    • Before DVCS時代
      • CVSの貧弱なマージ機能を補完するため、人間が工夫していた
        • 手でブランチ図を描いて、マージポイントなどを管理していた
        • ただ、開発が進むと管理しきれなくなる
  • テスティング(Test-“ing”)
    • 名詞ではなく進行形
      • 書き”ながら”開発を進める
  • 自動化
    • 人間は
      • 飽きる
      • 疲れる
      • 繰り返しが苦手
      • 創造性がある
    • 機械は人間の逆
      • 飽きない
      • 疲れない
      • 繰り返しが得意
      • 指示したことしかできない
    • 機械と人間でコラボレーション
      • お互いの得意なところで、不得意なところを補完する
      • たとえば
        • コミット:人間
        • ビルド:機械
        • レポート:機械
        • 判断:人間
    • 人間→機械より、機械→人間の通知の割合を大きく
      • 人間は非同期に作業するのが得意
      • Jenkinsなどを活用し、機械の割合を増やす
  • 三本柱以外のメタファー
    • 三種の神器
      • レベルを上げて物理で殴れば、なくても何とかなりそう感あり
      • メタファーとしてはやはりどうかと
    • 三脚椅子
      • 今のところ一番しっくり
      • 先日論破された
        • 「足が一本もなければ安定するじゃん」
        • もっとも
  • テスト
    • コンテキストを合わせる
    • だれが何のために行うか
      • 開発者(TDDはこれ)
      • 顧客(ユーザー)
      • 品証(QA)
  • TDDとは
    • 原典(TDD入門)の書き出しがすべて
      • 「動作するきれいなコードを書き続ける」
  • 2つの道
    • きれいだけど動かないコードから動くコードへ
    • 汚いけど動くコードからきれいなコードへ
  • 動かないコード→動くコードに移るときに「気付き」がある
    • TDDは汚いコードでもまず動くようにする
    • この段階を小さく早く繰り返すことで、「気付き」のタイミングが多い
  • Red→Green→Refactoring
    • 黄金の回転
      • JoJo第7部 Steel Ball Runより
  • 汚いコード→きれいなコード
    • 実現するには「強い意志の力」が必要
    • 「汚さ」に敏感になる
    • 「リーダブルコード」がその助けとなる
    • 汚いコードはいずれ自分が嫌いになる
  • TDDのこころ
    • 一つずつ、少しずつ、段を小さく
      • 問題をBreakDownする
    • 複数を相手にしない、一人ずつ対処する
      • 1対1の連続にする
        • 思ったこと:ただ、疲れはする
      • TODOを先にリストアップ
        • やりやすいところから片付ける
    • 素早く回す
      • 回転が遅い、ということは何か問題がある証拠
    • 自分が最初のユーザー
      • 作る→使ってもらう→フィードバックでは遅いし漏れる
      • 作りやすい<->使いやすいのバランスを見極める
        • トレードオフになるものも多い
        • TDDが導く
    • 不安をテストに
    • 祈るのではだめ
      • テスト、VCS、自動化に守られた状態なら、祈る必要はない
    • 命綱を編む
      • 必要になってから編んでも、もう遅い
      • 日々の習慣に組み込むのがTDD
        • 編んだ命綱を自動化で回す
  • TDDの最大のメリット
    • 心理的なもの
  • TDD=バグ0ではない
    • バグをテストで保護して対処
    • バグのたびに強くなる
  • TDDのテストは目的でなく手段
  • TDDの目的は「健康」
    • コードの健康
    • チームの健康
  • TDD導入事例
    • IBM、MSの論文
      • バグは6割から最大9割削減
      • 実装時間は3から3割増
    • エリクソンの論文(アンケート結果の分析)
      • デバッグ時間の減少
      • コードの品質(外部/内部)の上昇
      • 実装時間は増えるが、トータルコストはむしろ減る
        • デバッグ時間の減少が大きい
  • デバッグ時間現象の意味
    • デバッグ→想定外の作業
    • デバッグを減らす→想定外の時間が減る
    • 計画した時間とのブレが少なくなる

 

TDDのペアプロデモ

キーノートセッション後は、@grimrose、@yattomによるペアプロデモです。FizzBuzzを題材にこんな感じでTDDを進めていました。

  1. TODOリストの作成
    インターフェースの検討もここで行っていました。たとえば、引数、戻り値の型、など。また、例外パターンの考慮も行い、「具体的な例外の型」については後回しにすることも決めていました。
    2以降でも途中で出てきた問題、課題は都度TODOリストに追加して忘れないようにする。
  2. 最初のテスト
    数字を入れたら数字を返すテストを作成し、コンパイルが通るようにしてテストが失敗することを確認するまで行いました。
  3. 仮実装
    テストを通す最短のコードを書くことを「仮実装」といい、「テストコードのテスト」の代わりとなるため、省かずに行ったほうがよい。
  4. 三角測量
    最初のテストに加えてもう一つテストケースを追加し、仮実装から本来あるべき実相を導きます。
  5. リファクタリング
    テストが通ったままの状態を維持しつつ、コードを整理します。
  6. 次のテスト
    Buzzを返すケースのテストなどを書いていきます。
  7. 明白な実装
    Buzzを返すケースができていればFizzを返すケースの実装も明白なので、三角測量はせずに一気に加速して実装してしまう。ただし、最小限のテストは書く。

個人的には、テストコードのリファクタリングのところも見たかったなぁ。

また、デモの途中で次のような質問が出ました。

Q:TDDはどのタイミングでコミットすればよいのか?

A:基本はGreenのタイミングで。ただ、GitなどのDVCSならば、Red、Green、Refactoringのそれぞれでコミットすることもある。ただ、この時もPushはGreenのタイミングで。

 

ペアプロ実習

デモが終わったところで部屋を移動し、ペアプロ実習タイムです。ペアの割合はPHP、Ruby、Javaの3強+他言語(C#含む)といった感じでした。

私は@aetos382と組み、VS2012、C#、MSTest with Chaining Assertionで臨みました。

 

お題

少し前にはやった「LTSV」ライブラリを少し改変したもので、@sue445さんがsue445/tddbc_tokyo_20130316 · GitHubにまとめてくれました。オリジナルのLTSVライブラリとの違いは、setterが変更前の値を返すこと、setした順番で中身をダンプすること、あたりです。

 

ペアプロの様子

まずTODOを2人で洗い出し、例外パターンなどの抜けがないかクロスチェックしました。ちょっとここで全部をやろうとしてしまったことは失敗だったかなと思っています。

そして実装開始です。我々はSet→Get→Dumpと進めていくことにしました。途中Setの値置き換えのテストを、Getを作成する前に行おうとしたところ、Getがないとテストできず、道を誤ったので一度戻り、今度はGetを実装する、といった進め方になりました。

また、最初はDictionary<string, string>をデータストアとしていたのですが、setした順序を保持するといった要件を実現するのに、うまくいかず途中でList<Tuple<string, string>>に切り替えることになってしまいました。

 

結果

LINQを活用したり、Chaining-Assertionを活用したりと、C#らしいコードになったこともあり、最後のコードレビューで採り上げられてしまいました。

 

クロージングセッション

最後にt_wadaによるクロージングセッションで、TDDの応用について話がありました。一言でまとめると、レガシーコード改善ガイドなどの本から他の本、他の本とたどり、スキルを高めていってほしい、といった内容でした。

 

まとめ

私の初めてのTDDBC参加は、こんな感じでした。今回の打合せ結果、イベント参加結果をもとに、5/18(土)に予定しているTDDBC長岡1.0に活かしていくつもりです。

あと、「お題」はまた改めてやり直してGitHubにあげてみようと思います。若干不本意な実装で終わってしまったので。

広告

#tddbc Tyokyo 2013-03に参加してきました」への1件のフィードバック

  1. ピンバック: 2013年振り返り by @masaru_b_cl | be free

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中