勉強会デビューを果たしました 〜TDDBC名古屋参加記録〜

2010.08.10 火 19:14:11

いま、テスト駆動開発(TDD)がアツい!!

というわけで、7月10日、11日に、名古屋アジャイル勉強会のbleis-tiftさんの企画・主催で講師に和田卓人さんを招いて開催された「TDDBC名古屋」に参加して参りました。
TDDBC名古屋の何たるかは、上のリンクと、名古屋アジャイル勉強会さんのブログ(TDDBC参加者のブログからトラックバックが送られています)を見ていただくこととして、ここでは自身初の勉強会で思ったこと、そして学んだことのメモを書いていこうと思います。

TDDの何たるかをよく知らない人の参考になれば幸いですし、
既に慣れ親しんでる方も、素人がどこで躓いてどう勘違いするか、などを見出す鍵となればと思って、詳しく書きました。

あと、長くなるので実演は別記事に分けました。
別記事を書き上げたら追記します。

 

なんで今さら?

もう1ヶ月も前じゃねーか!

…というツッコミは無しでお願いします><

記憶は色あせておりません!ということで許して><

 

なんで参加しようと思ったの?

建前は…
  • 行き当たりばったりなコーディング
  • 生まれゆくレガシーコード
  • 生まれゆくバグ
  • 生まれゆくストレス
  • 失われる時間
  • 失われる信頼

こんなの懲り懲りだ!
→お、TDDなんてのが! お、TDDBCなんてのが!!
→参加登録余裕でした^^

もう一つの建前は…
  • そろそろ就職近いなあ…プロの感覚知っときたいよなあ…
  • あれ?学生のうちにこのあたりできるようになればかなり差がつくんじゃね?

良い意味での下心です。

本音は…
  • 愛知に来て3ヶ月、まだ何も勉強会行ってない!(焦
  • bleis-tiftさんと会えるよね!
  • プロの人と交流すると絶対プラスになるよね!
  • ペアプロとか絶対プラスになるよね!

 

TDD講義編 〜TDDとは何で、何がおいしい!?〜

一日目の朝はTDDとは何たるか、の講義からスタート。
自分の場合そもそも基礎知識がなくて、何をどう改善したいのかという対象からして明確じゃなかったので、これを見出すつもりで臨みました。
ということで、以下講義メモ(独自解釈含む)

最初のトリビアは、TDDの目指すものとその過程。

  • コードを4分類する。{きれいなコード, 汚いコード}×{動くコード、(今は)動かないコード}
  • 最初は、汚いくて動かないコード
  • 目的は、動くきれいなコード
  • 「きれいにして動くようにするルート」と、「動くようにしてきれいにするルート」がある
  • TDDでは後者!
  • 動く汚いコードってものには存在価値はないと思っていた!
    が、TDDの過程としては意味がある!

次のトリビアは、テストとは何か、でした。

  1. 開発促進のために行うテスト ←TDD!
  2. 進捗管理のために行うテスト
  3. 品質管理のために行うテスト

僕の知るテストは2、3でした!
だって、ソフトウェア開発技術者試験とかほとんど3しか扱わないじゃないですか…><
TDDは、テスト技法ではなく設計技法です!

では、開発促進のためっていうと、具体的に開発における何を目的にしてるの?という疑問。

  • プログラマの不安を取り除く
  • コードが健康になる
  • 開発者が(精神的に)健康になる
不安ってなんぞ!
  • 仕様を決めたがその通りに動くか? (基本)
  • こんな入力きたらどうだろう
  • このライブラリ関数はどんな挙動を…

これらの小さな疑問を小さな粒度で一つ一つテストしながら不安を解消し、インクリメンタルにコードを記述していく、それがTDDだとわかりました。
※決してコードをドバッと書いて疑問点を洗い出してテストしてなおすのではないのが重要!!

そして、テストは不安をなくすことによる健康体を得るための手段です(テストが目的ではありません!)。

  • 書いたコードに自信を持つ!
  • 次のコード記述に自信をもって臨む!

 

結局のところTDDは何をどうすればいいの?という話。

基本サイクルは、次の通り。ごくシンプルです。

  1. 仕様を決めるor疑問点を発掘する
  2. テストを書く
  3. テストを実行する
    まだコード書いてないんだから通るわけない! → Red
  4. テストを通る最低限の(ホントに最低限)コードを書く → Green
  5. コードをリファクタリングする → Refactoring

Red・Green・Refactoring、これを黄金のサイクルと呼んでいます。

このときに重要なこと。

  • 一つずつ!小さい粒度で!一気にやらない!
  • 素早くサイクルを廻す!
  • 自分が自分のプログラムの最初のユーザとなる!

 

テスタビリティの話
  • テストしやすいコードにするには!
  • じゃあ、テストを先に書けばいいじゃない!
  • テストを考えることが設計(仕様)を考えることになる!
  • (゚Д゚)ウマー

 

結局TDDは何がおいしいのか

効果が明らかに出ないとイヤン、て人のために。

  • Microsoftで(゚Д゚)ウマー
  • IBMで(゚Д゚)ウマー
  • Ericssonで(゚Д゚)ウマー
  • まとめると、「2割開発時間が増えてバグが半分になる」 (これはかなり控えめかも!)

 

TDD実践編 〜ペアプロでTDD体験をしてみよう!〜

ここでお昼休憩を挟んで、午後はペアプロTDD体験です。
40人強の参加者がいくつかの言語に分かれて、それぞれの中でペアプロ→発表→ペア替え、と数回繰り返します。

 

ところで、なぜペアプロ?

TDDBCのキモはペアプロによるTDD体験ですが、なんで組み合わせてやるのか?という話。
そもそもペアプロ自体のメリットはいろいろあるわけですが…

  • スキルトランスファー
  • 監視されてる感があって、がんばってコーディングする
  • コードに関する知識が共有される
  • etc... (Wikipediaに勘弁してくれってほど書いてある)

実は、これらに加えて次の理由により、ペアプロとTDDはすさまじく相性が良いようです。

  • 「不安」を探す目が増える!

TDDでは、「不安を見出したら勝利」です。

もっとも私の場合はTDD自体を知らなかったので、ペアプロのメリットとして一番大きかった要素はやはりスキルトランスファーでした。

 

実践テーマ

簡単に言うと、キーバリューストアの実装でした。

  • Setでキーと値を設定
  • Getでキーから値を取得
  • Dumpで現在の内容を全て出力
  • 何もSetせずGetするとnull
  • あるキーに対して二重にSetすると上書きされる
  • 上書きすると内部順序が最後になる

その他いくつかの細かい仕様が与えられます。
仕様は当然テスト項目となるわけですが、未定義の仕様については自身で決定する必要があり、これについてもテストすることとなります。

これを書き終えたら、次は仕様変更が発生しました。

  • 複数のキー・バリューのペアを一気に設定できると便利だよね!
  • 複数のキーに対する値を一気に取得できると便利だよね!

…顧客の要求は絶対です! やらざるを得ません。
しかし、ここまでで既に基本部分は動くことに確信が持てているので、基本部分が正常に動く状態を維持したまま新たに機能を追加していきます。

これを書き終えると、さらなる仕様変更です。

  • 値を設定するときに"${now}"という文字列があったら現在時刻の文字列に置換してほしい!

これはなかなか素敵なテーマです。
というのも、システムの時刻を直接使用することはテスタビリティの観点でよろしくなく、あらゆる時刻の可能性をチェックするためにシステム時刻(.NETでのDateTime構造体)をラップした時刻管理クラスを新たに作成することがミソでした。

もっと細かい流れまでは、長くなりますので、また別の記事で扱おうと思います(NUnitの使い方も含めて)。
この演習課題の仕様書はメモって無かったので、題材は別のところから引っ張ってくることにします(後述)。

 

ペアプロはどうだった?

ざっと、感想としてはこんなところでした。

  • 人生初ペアプロ
  • 相手はプロのプログラマ
  • すさまじく緊張して手が震えた
  • TDDの流れやNUnitの使い方を手取り足取りしていただいた
    予習がほとんどできてなくてすみません><
  • コード記述については、意外と問題なくついて行けた
  • だんだん慣れてきて、いろいろ口出しをするようになった
    それはすごい良いこと!と褒められてホクホク
  • コードで語るというのがどういうことかよくわかった

TDD+ペアプロを実践しての重要な気づきです。

  • 仕様が明確になる
  • 行き当たりばったりコーディングじゃ絶対気づかないような仕様の甘さとか疑問点(=不安)がゴロゴロ出てきた
    ※何度も言うように、不安を見つけたら勝利
  • しかも動いた部分はテストで自信をもってるから、TDDで見逃したバグがあってもバグ取りが遙かにしやすいに違いない
  • コーディング時間が2割増えてバグが半分? いやいや、コーディングが5割増えてバグが2割になる、そんぐらいの印象。
  • 誰でもできる
  • おバカでもできる
  • おバカほど効果がある (俺!)

TDDはスキルであって、練習すればできるようになります。

なぜなら、TDDは完璧を目指すためのものではなく、
平凡なプログラマが平凡なプログラマのために考えた現実的な回答だからです。

 

熱い夜!

さて、ここまでで一日目。
夜は懇親会、そして宿での熱い議論が待っています…!

懇親会!

皆さんテンションがすごく高くて、大変おもしろかったです。
 酒を飲む(顔が赤くなる;レッド) → ゲロる(顔面真っ青;グリーン) → 復活(リファクタリング)
とか、笑いこらえきれないですから…!

和田さんはじめ何人もの方といろいろ話をしました。

 

夜!

僕はなんとbleis-tiftさんと相部屋という名誉にあずかりました。

  • LINQいいよLINQ!
  • ScalaいいよScala!
  • 情報教育ねえ…

いろいろとお話をしました。
他の部屋では明け方までいろいろしていたようですが、僕らは二日目に響くと本末転倒なので…ということで、早めに就寝しました。

 

朝!

朝は相当早く起きて朝食。
食堂ががら空きだったので、そこでもいろいろしゃべっていました。

Visual Studioが21ライセンスで700万円だって…!?

部屋に戻ってからは一日目の復習をしていましたが、ついでにテストのリファクタリングの話、CI(Continuous Integration)の話をしていただきました。

 

二日目の講義 〜対レガシーコード戦の心得〜

二日目のテーマはレガシーコード改善体験。

レガシーコードとは、

  • テストを通っていないコード
  • 仕様が不明なコード

など、要するに、よくわかんないけど動くらしいようなコードを意味します。

そもそも我々の目指すものは
  • コードの質
  • 英知・原則・スキル・病理学
  • ユニットテスト・リファクタリング・パターン
  • テスト駆動開発・パターン駆動開発

これらが順に積み重なった上での、創発的設計である!
しかし現実は厳しい…!

  • テストされてないコードが既に大量に存在する(レガシーコード)
  • 正規化されてないデータの入ったDBが大量に存在する(システムに手出しができない)
    データもリファクタリング対象!
  • テストコード自体が増えてきた!
     テストコードとの戦いとなってしまう → リファクタリングしたくなくなってくるorz
     用済みなテストは消す! ← 機械的な方法が確立されてない!
     テスト自体の時間がバカにならない ← mockの導入 ← mockのテスト ← なんだこの循環
     毎日がMockやテストコードのメンテになる! → TDDの失敗例

ということで、ここでは一つ目・レガシーコードにどう対応するか、という話です。

 

仕様化テスト

対レガシーコード戦の最初のステップは仕様化テストです。

  • レガシーコード=テストが無い
  • レガシーコード=仕様書があるかもしれないしないかもしれない。
  • 動くには動く。
  • どう動くべきか! ではなく 今どう動いているか、を明確化しなければならない!

ある入力に対しどのような出力が得られるかを調べ、テスト対象がどのような仕様であるかを決定するのが仕様化テストです。

 

継ぎ目〜テストできる地点〜
  • テストするためには、テストする切り口がなければ → 継ぎ目
  • どこでプログラムを区切るか?
  • うまく区切れそうな場所が無い例も
    →無いなら作ってしまえ!

継ぎ目の例は、たとえば時刻に依存した動作をするプログラムにおいて、システム時刻をラップしたものを導入してテスト可能にする(先ほどの例まんま)、などがあります。

テスト容易性が第一!

テストのためには、カプセル化を破ってしまっても構いません!

 

ということでやってみよう!

二日目の午後は、実際のレガシーコードを使った体験。
題材が多くなかったので、ペアプロというわけにはいかず、言語単位での作業となりました。

C#班での題材は、あるGUIプログラムでした。
わんくま勉強会のTDD道場で使われたものだとのことです。

  • 乱数を使ってて、このままじゃテストできない
  • そもそもGUIがどう動いてるかこのままじゃNUnitで確かめられない!(本当に不可能という訳ではないけども)
  • つまり、レガシーコードの中でも、かなり厄介!

じゃあどうするんだ!

  • テスト容易性の観点でダメダメ!
  • とにかく、テスト可能にするための変更を施す
  • ここでは、ロジックとユーザインタフェースの分離をする
  • しかし、命綱がない(テストによりどこまでは動いたかというのを確認せずに作業する)
  • 逐次書き換えながら「見た目ちゃんと変わらず動いてるぽいね」というだけで次へ進む
  • TDDを知ってしまった身としてはハラハラドキドキ!
  • テストが可能になったら、やっと仕様化テストに入る
  • 後は普通の対レガシーコード戦に同じ

実際のプログラムでは、こんな風にUIとロジックが癒着してテスト容易性が著しく低いケースが山ほどあるのではないでしょうか。

折しも活きの良いレガシーコードを絶賛放出中でしたので、

  • 対レガシーコード戦を学ぶ
  • テスト容易性がどれだけ大事か身にしみてわかる
  • 常にテスト容易性を意識した設計を考えるようになる
  • 傷口を広げないようになる!
  • (゚Д゚)ウマー

こういう意味で、レガシーコード戦の練習をするのは、「これまでのをどうするか」というのはもちろん「これからどうするか」を考える上でとても重要だとわかりました。

 

もう一つ、対レガシーコード戦でわかったこと。

  • テストをして仕様を調べる
  • その結果が変わらないようにリファクタリングする

なんと、TDDの手順を逆順になぞっているではないですか!

最初TDDBCに参加するときから頭の片隅にあった疑問「なんでTDDと併せてやるんだ?」というのが解決しました。

 

これで、最後に成果を発表して、TDDBCの全日程が終了しました。

 

初勉強会は最高でした

懇親会で、実はこれ初めて参加する勉強会なんですよー! と言うと、みなさん「初めてがこんなに濃いとはwww」という風に言っておられましたが、その通りだと思います。

しかも、講師の和田さんが何度も繰り返し言っておられたのですが、「名古屋の勉強会コミュニティは本当にすごい」のだそうです。
とにかく"改善"の精神があちこちに見られ、一日目に見えた問題点などが二日目には解決される、など、しかもそれを当然のようにやってのけてしまう…!

こういう仕事のできる人間になりたいですね!

 

acts as professional グリーンバンド

講義スライドの中で紹介されたゴム製リストバンドですが、「これほしい!」という声が集まり、まとめ買いで希望者(参加者の大半)が購入する運びとなりました。
私も購入しまして、ちょうどTDDBC開催から一ヶ月経った今日8月10日、届きました。

acts_as_professional.jpg

この色、実はNUnitのグリーンバーと同じ色なんですね、実は!
写真の撮り方がヘクソタなのですが、acts_as_professionalという文字列が刻まれています!

先日開催されたOSC名古屋でbleis-tiftさんがつけていたのも印象的でした。

 

さて、次のTDDBCは?

TDDBC名古屋が終わるか終わらないかのうちに、自分の場所でもやりたいな!という声がいくつかありました。大阪や九州など。

大阪ならあまり遠くないし、九州(福岡近辺)であれば私は地元が山口なので、無理に都合つければ行けそう。

今回だけでは吸収しきれなかった部分もありますし、TDDBC北陸や東京にも参加していた方が各言語班の中心的位置にあってTDDBCの運営を助けておられたようなので、是非もう一度参加したいと思います。

 

謝辞

  • 講師の和田さん
  • 運営の名古屋アジャイル勉強会さん、特にbleis-tiftさん
  • 参加のきっかけ(最後の一押し)となった、bleis-tiftさん、大学の先輩のa_hisameさん
  • 事実上の私の専任教育担当だったbiacさん
  • アフォな私につきあってくださったC#組のみなさん
  • グリーンバンド購入を発案し、発送までの世話をしていただいたmzpさん
  • そして全ての参加者・スタッフの皆さん!

本当にありがとうございました!
また何かの機会で会えるといいな!


さて、なんだかまとまりのない記事となってしまいました!
だらだらと講義メモを書く必要があったんだろうか。最後の方とかテキトーだし…。

次の記事では、NUnitとC#の組合せで実際のTDDをやってみます。
自分の理解の範囲で。勘違いがあったらガンガン指摘してほしいと思います。

題材は、TDDBC参加者の中山裕貴さんからいただくことにします。

 

  1. 2010年08月10日(火) 19時14分11秒|
  2. カテゴリ: イベント|
  3. コメント:0

コメント


コメントの投稿

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


画像の文字を半角数字で下記ボックスに記入ください。
文字が読みにくい場合はブラウザの更新をすると新しい文字列が表示されます。

プロフィール

xptn
Author:xptn
例外人生まっしぐらの高専卒大学生。平成生まれの21歳。
twitter

最近のエントリー

カテゴリー

最近のコメント

月別アーカイブ

リンク

RSSリンク

お小遣い稼ぎ!
スマホでお小遣い稼ぎ!
DTIブログポータルへ
このブログを通報
Report Abuse

利用規約