今週バタバタしていて、ブログ書けなかったんですけど、先週の土曜日にTDDBCに参加してきたので、そのレポート。今更感ありますが。
TDDBCって？
TDDBCとは、TDD Boot Campの略で、テスト駆動開発(Test Driven Development)について、座学だけでなく、実習形式で手を動かして体得することを目的とするイベントです。
各地のコミュニティの方々が中心となって、全国各地で行われています。
キーノート by @t_wada さん
まずはじめに和田さんにキーノートがありました。
僕はTDDBCに参加したのは今回が初ですが、和田さんが過去のTDDBCで講演したときのスライドはSildeshare等で拝見してましたし、内容自体は聞いたことある内容が多かったですが、やはりスライドだけ見るのと実際にお話を聞くのでは全然違いました。
以下、トピックだけですが内容を。
TDDBCについて
- TDDBC4年目。
- 東京でやるのは久しぶり。
- Boot Campとは米軍の教育プログラムの名前。
- TDDBCも米軍の兵士訓練プログラムと同様、ペアプロやTDDを体験して見つけてもらう。
- 今回で31回目。
TDDBCでは何をやるのか
- ペアプロをやってもらう。
- ペアプロは楽しいということと疲れるということを学んで帰って下さい。
- コードレビューもする。
- TDDBCは同じお題について書いているので普通のコードレビューと違う。
- 実際の現場で同じ要件のプログラムを複数のペアが実装することはない。
- 同じお題について他のペアはどう考えたのか、他の言語ではどうなるのかを考えることは意味がある。
- 振り返りもやる。
- KPTでやります。
ソフトウェアの3本柱
- バージョン管理
- テスティング
- 自動化
バージョン管理
- ソフトウェアの寿命は意外と長い。
- 人間の記憶力ではあっさりと物事を忘れる。
- 現場ではメンテナンスと新機能の開発を同時にしなければいけないことが多い。
- しかし通常それらはまったく違う。
- バージョン管理なしでソフトウェア開発をするのはセーブポイントなしでRPGをクリアしろと言われてるようなもの。
テスティング
- これは本日のメインなのであとで詳しくとのことでしたw
自動化
- 人間がやることを機械にやらせる。
- 人間はクリエイティブなことができるが、飽きっぽくて忘れっぽくて繰り返しが苦手。
- 機械は自分で考えられないけど、淡々とやるのは得意。
- 自動化から自動化へ。
- 人間が機械に働きかけるのでなく、機械が勝手にいろいろやって人間の助けが必要なときに機械のほうから人間に働きかけるようにする。
- Jenkinsとかそうだよね。だからよく使われてるのです。
ソフトウェアの3本柱は三種の神器？
- ソフトウェアの3本柱はよく「三種の神器」に例えられるが、三種の神器だと一つくらいなくても強そうな感じがするのでメタファーとして不適切。
- そういうわけで「三脚椅子」によく例えるほうがよい。
- これだと1本でも脚がないと倒れる。
- しかし先日、仙台で論破された。
- 1本も無ければ安定するよ！(笑)
「テスト」にまつわる混乱
- 「ユニットテスト」をどう訳すか？
- 「単体テスト」と訳すと組織や現場によって指し示すものが全然違う
- テストは「誰が」「何のために」やるかという軸で捉え直すほうがよい
- Developer Testing（開発者が、開発促進のために）
- Customer Testing（顧客が、進捗管理のために）
- QA Testing（品質保証担当者が、品質保証のために）
- Developer Testing
TDDとは？
- ケントベックの「テスト開発駆動入門」を読みましょう
- いい本はいい書き出しで始まる
- 「動作する綺麗なコードは価値がある」
- 動作する綺麗なコードのためには「ちゃんと設計（きれい）して、それを実装（動作する）しかない」と大学などでは教えられる。
- 和田さんも大学でそう習った。
- 中二病のときにいろいろ熱中した。w
- きれいで動作しない間（実装前）は泥沼。
- 「完璧な設計」だと判断できる目安がない。
- 現在のソフトウェアは登場人物が多すぎる。
- フィードバック大事。
- 「動く」ことがフィードバックの源泉。
- 「動く」状態（フィードバック可能）と「動かない」状態（開発中）を何度も往復する必要がある。
- （「きれい」なものを「動く」ようにするだけでなく）動かしてからきれいにするプロセスもあるんだよ！
TDDのステップ
- 次の目標を考える
- その目標を示すテストを書く
- そのテストを実行して失敗させる(Red)
- 目的のコードを書く
- 1で書いたテストを成功させる(Green)
- テストが通るままでリファクタリングを行う(Refactor)
- 1-5を繰り返す
黄金の回転
- Refactorは意思が必要なラインである。
- 意思がないとレッドとグリーンを行ったり来たりすることになる。
- 世の中には「動いているものに触るな」というマントラがあるw
- しかし、それを繰り返していると技術的負債を積み重ね、コードは腐っていくので、強い意志を持ちましょう。
- 不吉な臭いを嗅ぎ分ける
- マーチンファウラーの「リファクタリング」を読みましょう
- きれいなコードに敏感になる
- 「リーダブルコード」を読みましょう
TDDの心得
一つずつ少しずつ段を小さく
- 複数を相手にしない。ひとりずつ対処する。（by 宮本武蔵）
- 1対多ではなく1対1の連続にする
- 仕留めやすい順番で仕留める。弱そうなやつから。
すばやくまわす
- 自分が最初のユーザである。
- コードの使いやすさは使ってみないとわからない。
- 頻繁に使う。作る前に使う。作る前に使えば作ったものに未練がない。
不安をテストに
- テスト駆動開発にテストをどこまでテストするべきかという定量的指標はない。
- TDDにおける「テスト」は開発者のためのものなので、自分たちが何故テストを書いているか考えるべき。
- 「自分たちの手が止まるのはどういうとき？」「不安があるとき。」
- getterやsetterに不安はないよね
- 祈るのではダメ。
- 不安があるならテストを書く。
- テストを書くということは、命綱を編む行為である。
TDDやDeveloper Testingのよいところ
- ソフトウェア工学的なメリットはたくさんあるけれど最大の理由は心理的なもの。
- バグがないとは言い切れないけど、自分の考えた通りには動いていると言える。
- テストは目的ではなく手段です。
TDDの真の目的
- 健康であること。
- 変化に対応するのは健康体のコード。
- 変化に対応するのは健康体のチーム。
開発
いよいよ開発が始まります。 会場を移動して、より広い部屋になりました。
使用言語
一応、Ruby/RSpecかPHP/PHPUnitのどちらかにしようとしていて、直前まで悩んでいたのですが、結局PHP/PHPUnitにしました。 普段、Railsの上でしか開発をしていないので、素のRuby書けるかなぁという不安に負けた感じですかね*1。 ちなみに全体的にはRubyとPHPがそれぞれ3割ずつくらい、Javaが2割、その他（Scala, C#, JavaScript等？）が2割といった感じだったでしょうか。
お題
今回のお題はLTSVでした。 任意のkey-valueをset/getできて、それをdumpするとLTSV形式で吐き出されるような機能をTDDで実装せよという感じです。
開発環境
ペアを組んだ人とお互いの環境を確認しながら、どっちのマシン使うか考えたりしました。
結構、運が良かったと思ったのは
- どっちもMac-er（まあ、これは想定通り）
- どっちもUSキーボード配列（まあ、プログラマだし）
- どっちもVim-er（まあ、これもだいたい想定通り。Emacs怖い。）
- どっちもtmux-er（まあ、Screen使ってる人もそれなりにいると思うのでラッキー）
- どっちもprefixキーがCtrl+t（ええ、まあ）
- PHPUnitはどっちも3.7系（最新）
- PHPの自分5.3系、相手5.4系
という結構近い環境でした。
.vimrcや.tmux.confの細かい設定まで一致することはないと思うのでそこまで確認はしませんでしたが、はじめてペアを組むにしてはだいぶやりやすかったかと。
結局、PHPのバージョンの関係で相手のマシンを使うことになりました。
開発！！！
開発についてはあんまり書くことないですw 黙々と作業していました。
まあ、意識していたこと/気づいたことだけ箇条書きでまとめると
- テストのリファクタリングもした。
- 「このテストってもうたぶんいらないですよね？」とペアで確認しながらうまく進めることができた。
- 実装前に書くテストはただRedになればいいんじゃなくて、期待通りのRedになるか大事。
- assertメソッド呼んで失敗するのが正しいはずなのに、何らかのエラーでそもそもassertまで到達してなかったりするんですよね、たまに。
- それに気づかずに実装してしまうと、実装終わってもGreenにならない。
- ちゃんとしたペアプロは初めてやったけど、やっぱりナビゲータのほうがいろいろ気づくことが多い
- 正常系動いてないのに異常系のこと考えない
- 弱そうなやつから仕留める
などですね。
なお、開発中はTAのかっちゃん ( @katzchang ) に大変お世話になりました。ありがとうございました。
発表/コードレビュー
開発が終わった後には何組かからどういう風に進めたかという発表と、実際にコードを見ながらのレビューがありました。 僭越ながら、我がペアはPHP組を代表して「PHPらしいコードを書いていた」という誇っていいのかどうかわからない理由(笑)により発表させていただきました。
ちなみに我がペアの成果物は以下にあげています。 https://github.com/a-suenami/tddbc2013-ltsv-phpunit
- Fork元がペアだった人ですね。
- TDDBC終わった1週間経ちますが、それ以降手を入れてないです。これが純粋に成果物。
まあ、それなりにしゃべれた気がします。 会場から質問やまさかりが飛んでくることはなかった*2けど、それはみんなPHPに興味ないんじゃなくてコードが良かったからだと信じてます！(笑)
ビアバッシュ
その後、ビアバッシュ。 野良LTが始まって、それに対してまさかりが投げられたりして、とてもおもしろかったです。
そして、憧れだったグリーンバンドを手に入れました！
これで僕も堂々とTDDerと名乗っていいですかね。
振り返り
初参加ながら振り返りにも参加させていただきました！
いろいろなよかったところ/改善すべきところがあるのはどんなイベントでもそうだと思いますが、実際にこの場に参加させていただくと、運営側のみなさんがどれだけ参加者のことを考えて開催をしてくれているのかを実感することができました。 本当にありがとうございます。
今後
今年はTDDBCラッシュらしく、この後、長岡/福岡でも開催されるとのことです。 長岡はまだどういう関わり方をしようか考えていませんが、九州人としては福岡にはぜひ参加したいと考えています。
今回PHPで参加したので次回はRubyで再度参加でもいいのですが、スタッフ（TA）というのも捨てがたいと思っています。悩み中。
