このエントリは TDD Advent Calendar 2011 の15日目です。

先月11月は26日と27日に、TDDBC 福岡 2に参加してきました。
私にとって、初めてのTDDBC参加になります。

今まで仕事でもTDDを導入する余地がなくて(今年は開発じゃないことをやっていることが多かった) 、個人作業だけぼっちTDDしてました。
なので、こういう場でTDDをちゃんとやれて、しかももう一つ念願だったペアプロまでできて、 本当に得るものが多い2日間でした。

で、このTDDBC 福岡 2に参加して、あるいはそれ以前から思っていたことがいくつかありました。
それを雑記の形でつらつらと綴っていこうと思います。

関数型言語とTDDの相性は？

TDDBCの1日目にこんなツイートをしました。
これは、1日目にあったディスカッションの中で、 id:t-wada さんが発言されたことを自分なりに整理したものです。
ここから私が感じたことは、

• 動的型付けの関数型言語はボトムアップに作っていくため 、閉じた小さな機能から作っていくのでユニットテストしやすい
• 静的型付けの関数型言語は トップダウンに設計していくので、各関数のインターフェイス(シグネチャ)を先に決めることができる

ということでした。

感覚的に、動的型付けの方は従来のTDDを進めていくやり方が適用できそうな気がします。
一方、静的型付けの方はあらかじめ「箱」を作り終えるまでは机上の設計が続きそうですが、それが終わると必要な関数のインターフェイスだけが出来上がっている状態になります。その「箱」の中に処理を作っていくところはTDDで行けますかね。

ただ、関数型言語とTDDの相性が良いのか、または悪いのか、私の中でも答えが出ていません。
やれるんですよ、テスティング・フレームワークもありますし。
Red → Green → Refactoring → ... の黄金の三角形を回して、関数をどんどん洗練させていくこともできます。
しかし、それを以て「関数型言語もOOPと同程度にTDDは効果的である」と言っていいのか。
私個人は F# + NUnit または F# + NaturalSpec でそこそこプログラミングしているので、無理だとか全くイケてないとかは思っていません。 

私が引っかかってるのは、"Refactoring"のところなんじゃないかなぁと感じています。
OOPにあるGoFの23 + αデザインパターンのような、コードが目指す理想の(とは言い過ぎかもしれませんが…)形がないので、重複を除く以外のリファクタリング、つまりより良いコードの形を見つけることが難しいんじゃないかと。
Redにすること、Greenにすること、Refctoringすること。全て揃ってTDDですからね。

おそらく、OOPのような比較的統一されたパターンは作りにくいんじゃないかなぁと思ってます。
モナドもパターンと見ることは可能ですが、Refactoringの段階で導入するには手直しが大きすぎるというか。
難しいですね(´・ω・`)

TDDを練習するのに良い課題とは

私はTDD初心者であり、仕事でもTDDをまだ持ち込めずにいる(そもそもコードを書かせてもらえていない)ので、もっぱら独りで練習しています。
言うなれば、スタメンを貰えない野球少年が、夕暮れの神社でもくもくと素振りをしているようなものです。
試合に出られないし、練習も球拾いばかりなので、人知れず特訓するしかありません。

そんな背景もあって、個人練習に向いたTDD練習用の課題があればいいなぁと思っています。
例えばTDDBC 福岡 2では、デモは初日にFizzBuzz、2日目にTDDBC名古屋のネタを使っていました。
そして2日通しての課題はTDDBC福岡でも使ったお題。
私も入門にはFizzBuzzから入りましたし、その後はTDDBC 福岡のお題、TDDBC 東京 1.6のお題とやってみましたが、TDDBCのお題は(途中の仕様変更も含めて)レベル感などよく考えられているなぁと思います。

TDDに適したお題を用意するというのは、難しいことだと思います。
TDD初心者の人が取り組む課題、少し慣れた初級者の人、ある程度できる中級者の人と、それぞれ求められるレベルは違うでしょう。
現状、すぐに思いつくお勧めの練習問題は、やはり過去のTDDBCのお題なんですよね。

その他だと、TDD関連書籍のサンプルコードにあるお題でしょうか。
書籍ならある程度以上の品質が期待できると思いますが、まず買わないといけないのはハードルになるかもしれません。

どういうネタがTDDの練習に向いているのでしょうか？
今まで見たことがある課題を思い出してみます。

• 文字列解析
• データ構造
• 数値計算

…何の変哲もない課題にしか見えませんね。
強いて言えば、DB接続や通信など、外の世界とやりとりする箇所が少ないことが上げられそうです。
Mockを準備するのは、手間がかかるからでしょうか。

あと、id:imagawa_yakata さんの「『Pythonでデザインパターン』という本が欲しい->わたしが書く」というエントリを見て、中級レベルの課題にTDDからのデザパタによるリファクタリングは良いなぁと思いました。

そろそろTDDの各レベル向けお題集とか作ると、他の人が捗るのかなぁと思ったりしています。(少なくとも俺得)
私も考えてはいるのですが、簡単すぎるか難しすぎるネタしか思い至らなくて、エントリ投下するにも至っていません。
TDDBCの次は、TDDEC (TDD Excercise Creation) を独りでやってみる流れですかね！

タスク分割について

TDDBCなどで課題を解いていて、時に手が止まることがあります。
原因は様々ありますが、「一度に解くにはちょっと難しすぎる問題にぶつかった」ということがよくあります。

TDDBC 福岡 2の課題では、チケット6の「ネットワークから取ってくる」がそんな問題だったのではないかと思います。
参考：TDDプロセスデータ収集 - Saga University CS 3rd Lab PMS
この課題に立ち向かうために、我々Pythonペアは次のように進めました。

• 改行で連結されたツイートを分割してリストに格納する
• 分割したツイートを、map関数とcategorizeメソッドですべて分類する
• ネットワークからツイートを取得する 

実際はネットワーク取得時にBOM付きUTF-8との戦いもあり、一筋縄ではいきませんでした。
それでも、チケットそのものにいきなり取り組むよりも、着実に課題を進めることが出来たと思います。

「TDDのこころ」にもありますね。

• 一つずつ、少しずつ
• ひとりずつ仕留める

難しそうなタスクは、実のところいくつかのタスクが集まっているものだということはよくあります。
それを一度に相手にするから難しいのだと。
一つひとつのタスクに集中すれば、さほど困難ではないはずです。

TDDに限った話ではありませんが、大きな問題をいきなり解くのではなく、それを小さな問題に分解して解いていく、というのは非常に効果的です。
このタスク分割は、しかしある程度慣れが必要なものかもしれません。
特にTDDBCのような、あまり時間がない中で課題を進めていく際には、目先の難問に囚われやすいと思います。

TDDのサイクルはRed → Green → Refactoring …なんですが、実はThink → Red → Green → Refactoring → … のように「考える」というステージがあるのだという話もあります。
(最初のTDDBCで『Test Driven』著者のLasse Koskela氏が言っていたのではないかと思われますが、私の勘違いかもしれません)

目の前の問題にどう立ち向かうか。考えなしに立ち向かっては敵の思うつぼです。
小さな問題は、テストしやすいサイズ。
小さな問題は、スピーディに開発を進められる単位。
まずはTo Doリストなどを使って、取り組みやすいサイズにまで問題を小さく分割できないか考えましょう。

さいごに

まとまりなく書いてしまったので、「まとめ」なんて章を作ることはできませんでした(´・ω・`)
TDDをやってみて感じたこと、TDDBC 福岡 2に参加して思ったこと、それを書き出してみました。
ご意見あれば頂いて、議論したり教えていただいたりしながら勉強したいです。

TDDは、開発者のための「ツール」です。
上手く進めている時の「楽しさ」「スピード感」「自信」は快感さえ覚えます。マジパネェ。
TDDは誰もが、一人でも始められます。
TDD Boot Campに参加することで、講演とハンズオンの両輪で学びを加速させることもできます。
決して銀の弾丸ではありません。でも、現実の開発に立ち向かうあなたをきっと支えてくれる「同士」になってくれます。

始めませんか、TDD。私たちと一緒に。