TDDBC 1.7 行ってきた

と、いうわけで。
先日行われたTDDBC 1.7に参加して参りました。
え、もう先日じゃないって？ぅぅ、すいません……。

内容そのもののお話は、ほかの参加者の方々のblogで語りつくされていると思いますので
私は、自分視点の感想等々を書くことにします。
時系列別に、どういう内容だったか知りたい方は、主催の@shishi4twさんの記事をご覧ください。

■前提
参加時点での私のTDDに関する技術レベル（？）は
興味があってPHPUnit（あるいはJUnit）のサンプルソースを動かしたことはあるけど、業務等の実際の開発で使ったことは無い程度、です。
一応、「車窓からのTDD」をPHPで書き直すという予習は、事前にやってました。
ついでに言うと、勉強会自体、片手で数えられるほどしか参加しておらず、これほど少人数の勉強会は初だったのでガッチガチに緊張してました…。

■TDDそのものについて。
最初に基調講演を聴いて感じたのは、TDDにおけるテストコードは、自然言語の仕様と実際のコードの間をつなぐ中間言語なんだな、ということ。
元々、日本語の仕様があって、それを元にプログラマが頭の中で考えてコードに起こしていくのが、旧来のTDDではない開発手法。
で、その仕様書をいかにプログラマにわかりやすくするか？っていうので、たとえばUMLとかが出てきたように思うんですよ。
（UMLにはそれ以外にも色々な意味合いがあるので、一概にUMLの用途を決める発言じゃないです。念のため）
実際、授業でプログラミングを習った際には、一度アルゴリズムを文字で書くための簡易言語っぽいものが利用されてました。

・iに1を足す
■iが10になるまで繰り返す
  ・iを出力する

こんな感じの。
ただ、自然言語や図などの人間が解釈するための仕様だと、プログラムコードに直す際のギャップが激しい。
なんせ、すっごい曖昧じゃないですか。日本語が曖昧って問題もありますが、そもそも自然言語って時点で、白黒はっきりしないことが多い。
一番大切な土台となる仕様が曖昧な状態で開発をしてたわけですね。今までは。泥の上にいきなり家を建てるような感じ。
そこで、いきなり家を建てるのではなくて、基礎やったりコンクリで固めたりして、土台をしっかりさせる作業が、TDDにおけるテストケースを書くって事。
土台がしっかりしてるから、プログラマも安心して作業できるし、完成するものもちょっとやそっとじゃ倒れない。最高です。
さらに言えば、テストケースを書くためには、問題の粒度を細かくする必要がどうしても出てくる。すると、小さな単位から問題を片付けることが出来るようになって、開発の速度と制度もUPする。
良い事尽くめですね。

ただひとつ、問題としては、どうしてもその利点を他者に伝えるのが難しいということ。
特に、よく知らずに「テスト」という単語だけで否定している人も多いんですよねー…。
こればっかりは、自分がしっかりTDDできるようになって、実際の成果を見てもらうほか無いのかな、って感じたり。

■ペアプロについて。
ペアプロという単語をはじめて聞いたのが、よりによってこのページだったんですよねー！
http://www.eclipsewiki.net/eclipse/index.php?%A5%BD%A5%ED%A5%D7%A5%ED%A5%B0%A5%E9%A5%DF%A5%F3%A5%B0%A5%D7%A5%E9%A5%B0%A5%A4%A5%F3
（Javaメインで使ってたころ、Eclipseのプラグインあさってたら見っけた）
Wikiからのリンクは死んでますが、配布元のページの製品とサービスあたりからたどると見れます。バーディ君…。

と、言う訳で、そこまで凄い物って印象はありませんでした。むしろ、割とキワモノなイメージが無意識のうちに…（苦笑）

実際やってみての感想ですが…。
開発中に出てくる小さな悩みの解決は、本当に早いです。
「正規表現のあの記法ってどんなんだったっけ？」「str_lenだっけstrlenだっけ？」等の文法的な話とか
「ここって別メソッドにしたほうがいいかな？そうでもない？」「この変数名何にしよっか？」等リファクタリング的なところまで。
特に、開発初期はこういうしょうもない部分で時間をとられたりするものですが、そういった事が無くサクサク進むのは凄くよかったです。

開発が熟すまでは定期的にペアプロを行うとイイカンジかな、と思いました。

ただ、私自身がすっごいガッチガチだったため、あんまり突っ込んだ話が出来なかったのが非常に申し訳無いです…。

■コードレビュー
1回目が私のペアでした。ただでさえ緊張してたのに…！
コードレビューをして思い出したのは、学生時代の部活動でした 。コンピュータ部だったんですよ。
ただのゲーム部というわけではなく、ちゃんとしたコンテストに参加することを目的とした部だったので
入部試験として、fizzbuzzでは無いものの、難易度的にはそれに近いコーディングのお題が出されるんです。
で、実装したコードを先輩の方々に見てもらって評価してもらう、と。
当時はコードレビューなんて単語も知りませんでしたが、やってることはまさにコードレビューですね。
（このお題の話については、そのうち書いてみようと思ってます。身元バレが怖いケド）

業務でも、たまにコードレビューが行われることがありますが、業務上のレビューは、上司に採点してもらうって形がほとんどなので、「ひとつのコードを叩き台にみんなで論議する」というタイプのコードレビューは本当に懐かしかったです。
また、何か機会があればやってみたいですね。

■ツール
「道具を大切に」「ひとつのツールをカスタマイズして使い込む」
という話が何度もありました。
が。
私自身、それとは対極に居る人間だったので、今回一番びっくりした事です。

学生時代、誰かにヘルプを頼まれそのまま人の環境で作業することが多かった身としては、自分用のカスタマイズされた環境じゃないと作業が出来ない、っていうのは避けたかったんです。
その経験を今になってもずるずる引きずっているため、開発環境はなるべくデフォルトで、ってやってました。

それも悪くは無いとは思うのですが、色々な人の環境(今回はVimが多かったです)に触れるにあたって、自分用の環境を1個持っておくのも悪くないと思いました。
TDDBC直後、職場の開発環境が吹っ飛んだので、これを期にってことでVim入れたりもしてます。
設定ファイルいじったり、小さいスクリプトを書くのには凄く便利です。
ただ、FW等の大きいソースコードを追う時は、どうしてもEclipseやNetBeansのほうが便利なので、そこは使い分けでやってます。

■お題について
最初のお題は、割と素直に解けるお題だったと思います。
TDDとしては、正規表現の確認のために、いちいちテスト用のコードを作って実行して確かめて、なんて手間がかからないのが楽でしたね。
テストケースを書くことによって、お題の中で言及されていない仕様(=の数が左右違う時、とか)に気づくことが多かったのも良い事でした。

2つ目のお題については、お題自体が複雑なのと、書きたいことも多くもう少し時間がほしいので、別にまとめ…る、予定です。

■その他いろいろ
箇条書きで。

• 緊張しまくりでホントすいませんでした。小規模の勉強会への参加が初だったんですよー！っていう言い訳。
• リストバンドほしかったけど、Mサイズがでかすぎて腕にはまらなかった…orz
• PHP関係のいろんな人と知り合えた！良かった。でもSymfonyノータッチノーチェックですいませ…ん…。最近、Symfony2のチュートリアル触り始めました！
• TDDを実務に組み込めるか？は悩ましい所。コーディング担当が自分のみってプロジェクトでは、やれそうだけど、そもそもオブジェクト指向ﾒﾝﾄﾞｸｾって人が居る環境なので、環境全体に浸透させるには壁が分厚いデス。
• 懇親会は予定があったので行けませんでした。楽しかったようなのですごくうらやましいです。次の機会があれば参加したいですね。
• Objective-cのOpenGL ESプログラミングを、一時期やっていたんだけど、さすがにああいう所だとTDDは難しそうだな、とか。
• TDDは、グラフを描くために式を考えるんじゃなくて、先に重要なポイントの点をたくさん取っておいて、近似値のグラフを描いて、そっから式を逆算するようなイメージ。
• キイロイトリの巨大なぬいぐるみ、家にあります（？）

とりとめも無くなってきたので、以上ということで！