makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

「TDD Boot Camp Tokyo 2013-07」に参加しました

2013/7/27(土) 「TDD Boot Camp Tokyo 2013-07」に参加してきました。

DoorKeeper
http://tddbc.doorkeeper.jp/events/4663

Togetter
http://togetter.com/li/539759

場所は品川シーサイド楽天タワーです。
私、自宅から自転車で行きました。お財布に優しい距離なのです

参加者は40名くらいでしょうか。
申し込み開始初日でMAXまで達したような。。。毎度恐るべしTDDBC!

しかし素晴らしいイベントだった!
地球防衛軍4で連日忙しく 日が空いてしまいましたが、今更ながら復習のためブログ書く。


■基調講演 by 和田さん

今回のTDDBCのスライドは公開していないとのことなので、手元の個人メモから書き起こしてみる。
復習の際は、TDDBC福岡のスライドを参考にさせていただきました。
http://www.slideshare.net/t_wada/tddbc-fukuoka-day1

■和田卓人のTDD講座
・gihyo.jpで連載していた。 http://gihyo.jp/dev/serial/01/tdd
・ニコニコ動画でも全20回、解説付きで見れる。 http://www.nicovideo.jp/mylist/4805036

■Boot Campとは
・アメリカ海兵隊の新兵の短期間修練

■TDD
・不安を克服する術が、TDD。
・ケント・ベックの「テスト駆動開発入門」からTDDは始まった。

テスト駆動開発入門テスト駆動開発入門
(2003/09)
ケント ベック

商品詳細を見る


・偉大な本は偉大な書き出しから始まる。「動作する綺麗なコードは、あらゆる理由で価値がある」

■動作する、きれいなコードへ
20130727_tddbc_1.png
(出典: http://www.slideshare.net/t_wada/tddbc-fukuoka-day1

●上側のオレンジ線
・これまでは、「良い設計をして、次に実装をすることで、きれないシステムが出来上がる」と言われてきた。
・図で言うと、上側のオレンジの道。でも、上側の道には罠がある。
・上側の線は、「きれいで動かない」という状態から抜けられない。
 → つまり、「きれいな設計にしたい」という欲求から抜けられない。まさに沼地状態。
・システム開発にはスケジュールがある。コードを書き始めると、いろいろ分かり始める。
 → 「ここまで設計する必要は無かった」とか「きれいな設計だけど遅すぎて使えない」とかが分かり始める。
・なぜか?それは、ソフトウェア開発の歴史が未熟だから。
・ソフトウェア開発は登場人物が多すぎるので、予測が立ちにくい。
 → 手を動かしてみて初めてわかる。

●下側の青線
・設計はいいから早くコード書こうぜ、というのが下側の青線の方。
・動くけど汚いシステムが出来上がる。

●両者の比較
・上は、完璧心の呪い。
・下は、堕落沼。
・下にハマっていてもいけない。
・動くものでも、きれいにする意志を忘れてはいけない。
・上と下はそれぞれ難しさがある。
・でも、縦線を超える(動かない→動く)ことが大事。それを教えてくれたのがTDD。

■TDDのサイクル
・TDDでは、テストコードとプロダクトコードを交互に書きながら進めていく。
・TDDとは、サイクル。
・まず、「やることリスト」を作る。
・そこから1つだけ、やりたいことをピックアップする。
・そのテストコードを書く。
・テストコードを動かすと、プロダクトコードを実装してないので絶対に失敗する。(赤色になる)
・目的のコードを書く。テストを通すことを第一に考える。
・さっき書いたテストが成功する。(緑色になる)
・目標を満たす状態になったので、今度はコードの方をきれいに直すフェーズになる。それがリファクタリング。
・テスト駆動開発のサイクル自身は非常に単純

■TDDと黄金の回転
20130727_tddbc_2.png
(出典: http://www.slideshare.net/t_wada/tddbc-fukuoka-day1

1.テストを書く
2.リファクタリング
3.次のテストを書く

・回転にはチカラが宿る(by ジョジョの奇妙な冒険)
・どれも矢印で示せるのが大事。矢印は分岐しない。ひとつのアクティビティとして扱える。
・アジャイルの「帽子をかぶり分ける」と一緒。
・一番大事なのは、堕落沼(4象限の下側の青い線)から抜け出すため、リファクタリングを行うこと。
・リファクタリングには「意思」が必要。
・1個1個のアクティビティの中に「片付けフェーズ」を設けている。それが上手くリファクタリングをやるコツ。

■TDDをどうやるか?
・良い書籍がある。
・1冊目は、マーチン・ファウラーの「リファクタリング」

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)リファクタリング―プログラムの体質改善テクニック (Object Technology Series)
(2000/05)
マーチン ファウラー

商品詳細を見る


・2冊目は、「リーダブルコード。少ないページで読みやすく書いてある。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
(2012/06/23)
Dustin Boswell、Trevor Foucher 他

商品詳細を見る


■TDDの精神
・テスト駆動開発は「回転」である。回転には力が宿る。(ジョジョ)

■TDDのこころ
以下の●印。

●1つずつ、少しずつ。段を小さく
・噛み砕いてテストに書ける段階まで分解していくのが大事。
・そこが難しいところでもあり、慣れが必要になる。
・タスクに分解するスキルがまず最初に大事になる。

●ひとりずつ仕留める
・複数を相手にせず、ひとりずつ対処する。
・宮本武蔵の「五輪書」にも、複数の敵に囲まれたときにどうすればよいかが書いてある。
 → 「1対多」を、「1対1の連続」にする。

●すばやくまわす
・テスト駆動開発における回転は、「フィードバックサイクル」。
・速く回れば回るほど、テスト駆動開発はうまく機能する。
・レッド→グリーン→リファクタリングを早く回す。

●自分が最初のユーザ
・テストから書く、ということは、自分がこれから実装するコードの最初のユーザは、自分が書くテストコードになる。
・自分が書いたコードが使いやすいかどうかは、自分が使ってみないとわからない。
・実装を考える前に、必ず自分が使う側に回る。
・そうすると、「作るのが楽なもの」と「使うのが楽なもの」が違うことがわかる。
・「ドックフードを食う」という表現があるが、つまり、自分が作るものを自分で使い始める。

●不安をテストに
・テスト駆動開発をやってると、どのくらいテストを書けばいいか、何をテストに書けばいいか、という疑問が出てくる。
・答えは、「不安をテストにしよう」。
・テスト駆動開発の目的は、自分たちの不安を解消しながら前に進んでいくこと。
・回転を妨げるのは、不安。
・裏を返すと、不安じゃないところはテストしなくてよい。
・getterやsetterには不安はないはず。なので、そこはテストしなくていいはず。
・自分のコードにはムラがある。そこをテスト書いていきましょう。
・テストがセーフティーネットになり、命綱になる。バンジージャンプする直前に綱を編み始めるのでは遅すぎる。

■なぜTDDをするのか
・TDDには数値的なメリットはあるが、最大の理由は心理的なもの。
・即座にフィードバックを得るため。自分が今書いたコードが、動くか動かないか、すぐわかる。
・その積み重ねが膨大なテストケースになる。
・TDDをやってれば、見落としがない部分に関しては自信を持てる。

■TDDの真の目的
・テストは「目的」ではなく「手段」。
・真の目的とは、「健康であること」。
・なんの健康か、というと、コード。無駄の無いコード。
・変化に対応するのは健康体のコード。
・テストを書いて、リファクタリングを続けて、無駄が無く、重複が無く、良い名前がついたコードにすることができる。
・変更に対応するのは健康体のチーム。TDDで爆弾処理のようなことはしなくて済む。
・TDDで大きなトラブルは置きにくくなる。 → 定時で帰る。
・不安を克服し、健康を維持する。
・これがTDDの真の目的。

■事例
・TDDの効果に関する研究論文から2つ紹介する。

●MS/IBMの事例
20130727_tddbc_3.png
(出典: http://www.slideshare.net/t_wada/tddbc-fukuoka-day1

・MSではWindow Vistaの開発でTDDが一部導入されたらしい。あとMSNの開発にも。
・上の図から傾向が読み取れる。
 ①不具合は軽減する方向に効果が出た。
 ②コードの実装時間は増えている。
・実装時間は2割増えて、欠陥が7割くらい減る。
・お客様へTDDの効果を説明するのに使える図。

●エリクソンの事例
20130727_tddbc_4.png
(出典: http://www.slideshare.net/t_wada/tddbc-fukuoka-day1

・TDD被験者にアンケートを取っている。
・「TDDはテストから先に書くので、矛盾点とかに気づきやすい。」
 → つまり、要求が洗練された。
・「実装工数が増えたのに、工数は減った」と5割の人が答えた。
 → 実装が増えたのに工数が減ったなら、何かが減ってるはず。
 → 減ったのは「デバッグの時間」。TDDで「デバッグ時間」が減る。
・デバッグの時間は読めないし時間がかかる。TDDをやると、ここの時間を減らせる。

■応用
●テストの無いコードが既にたくさんある。どうすればいいか。
 → レガシーコード改善ガイドを読む。

レガシーコード改善ガイド (Object Oriented SELECTION)レガシーコード改善ガイド (Object Oriented SELECTION)
(2009/07/14)
マイケル・C・フェザーズ

商品詳細を見る

・言語が何でかかれていようが、テストがないコードはレガシーコード。
・現場に1冊おいておくべき本。

●既にデータの入ったデータベースがある。どうすればいいか。
 → データベースリファクタリングを読む。

データベース・リファクタリングデータベース・リファクタリング
(2008/03/26)
スコット W アンブラー、ピラモド・サダラージ 他

商品詳細を見る

・DBのリファクタリングは、コードのリファクタリングよりも時間と慎重さが必要になる。

●テストが脆い
・Fragile Testsとは、壊れやすいテスト、内部に深く立ち入りすぎたテストのこと。
 → 開発の足手まといになる。
・Slow Testsは、黄金の回転が遅くなる。つまり、フィードバックサイクルが回らなくなる。
 → スローテスト問題。
・これらの問題をどう改善していけばいいか。
 → 「xUnit Test Patterns」を読む。

xUnit Test Patterns: Refactoring Test CodexUnit Test Patterns: Refactoring Test Code
(2007/05/21)
Gerard Meszaros

商品詳細を見る

・この書籍は翻訳されていない。
・副題に「Refactoring Test Code」とある。
・壊れやすいテストコードをどうメンテしていくかについて言及している。
・900ページもある、鈍器。膨大な本。
・ほぼWikiの内容を書籍化した本なので、インターネット上で読める。


●どこまでテストすればよいのか。
 → テスト技法の分野から1冊を選ぶとすれば、「ソフトウェアテスト技法ドリル」
ソフトウェアテスト技法ドリル―テスト設計の考え方と実際ソフトウェアテスト技法ドリル―テスト設計の考え方と実際
(2010/10)
秋山 浩一

商品詳細を見る

・テスト設計について初歩から応用まで教えてくれる本。

●現実のシステムはもっと複雑だが、どうすればいいか。
 → 「実践テスト駆動開発」を読む。

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)
(2012/09/14)
Steve Freeman、Nat Pryce 他

商品詳細を見る

・テスト駆動開発の2冊目のバイブル。
・テストを書きながらシステムを育てていくという思想。

■まとめ
・応用編として5冊の本を上げた。
・今日は「黄金の回転」を覚えて帰って欲しい。
・本を辿ること。
・TDDはスキルです。才能の世界ではない。練習すれば覚えられるし上手くなる。
・迷ったら写経をする。やり方は以下。


・TDDの出会いは、「リファクタリング」の原著のレビューを読んだこと。そこで写経した。
・グリーンバンドを考えたのは、ボブ・マーティン。通称:ボブおじさん。
 → 左手を見るとグリーンバンドがある。それで「プロなんだからテストかかなきゃ」と思う。一種の戒め。


■Steve Freeman氏による講演

この日のスーパー飛び入りゲスト、Steve Freeman氏による講演!
ちなみに和田さんの講演の中に出てきた書籍「実践テスト駆動開発」(通称:GOOS本)の著者です。
20130727_tddbc_5.jpg

私の英語力が無いのが悔やまれる。。。
んでも、 @yattom さんがTwitterでリアルタイム翻訳を流してくださいました。
冒頭のTogetterから追えます。

あと、Steveが来る事をTwitterで事前情報をキャッチしてたので、私もGOOS本を持参しました。
もちろん狙うは、書籍への直筆サイン!休憩時間に無事いただくことができました。


■ペアプロ大会
午後からペアプロ大会です。お題「飲み物自動販売機 Ver 2.0」の詳細はこちら。



私は @megascus さんとペアで、Javaにて取り組みました。
確かステップ4かステップ5まで行けてたハズ。
コードはGithubに上げておきます。
https://github.com/makopi23/TDDBC_Tokyo_201307

@megascus さんからの有意義なアドバイスを戴きながらのTDDペアプロ、大変勉強になりました。

あと、Steveもペアプロに挑戦&生コードを交えた解説タイムがありました。凄すぎてワロタw




★感想:
ホント素晴らしいイベントでした!
基調講演も、飛び入りSteveも、ペアプロも、質疑応答も、TAも、何もかもが素晴らしい。
過去のTDDBCの参加者もおっしゃっていたんですが、今回は神回では無かろうか。。。
TDDBCに参加したことがない人は、是非参加をおススメしたいですね。TDDの真髄が1日に詰まっている。

ちょっとブログ書くまで日が空いてしまいましたが、これは書かざるを得ない、と思って今更ながら、復習の意味も兼ねて書きました。

関係者の皆様、ホント有意義なお時間ありがとうございました。
関連記事
スポンサーサイト

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバック URL
http://makopi23.blog.fc2.com/tb.php/96-a48b775b
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。