実践型XP一日体験ワークショップ！

勉強会に参加してきました。

［実践型XP一日体験ワークショップ！］
こんなプログラムで開催されました。
１．ペアプログラミングとは
講師：西　丈善氏(XPJUG関西代表)

２．テスト駆動開発について
講師：irof氏

３．ペアプログラミング＆テスト駆動開発＆継続的インテグレーション体験ワークショップ
参加者同士のペアプログラミング＆テスト駆動開発による課題演習を行っていただきます。コミットしたソースコードは自動的に受け入れテストが実行され、スクリーンで結果を見ることが出来ます。
サポーター：Developer's Test勉強会メンバー

■ペアプログラミングとは
●ソロドロー
●ペアドロー
●振り返り

最初のプログラムでは似顔絵作成をそれぞれ一人と二人ペアで実施し、
ペアプログラミングを疑似体験しました
似顔絵作成の準備として、目的とパーツを書く順番を最初に決めてから作業に入りました。

皆で行った振り返りをシェアします。

自分は考えこんでしまう
- そこでナビゲートしてくれる
- 止まらずにアウトプットが進む
- アウトプットすればまたフィードバックがある
- よいサイクルが生まれる
- 全体的にテンポ良い
安心感が持てる
単純に楽しい
気を付けないと
- 盛り上がりすぎて脱線
自分にない視点

■テスト駆動開発について
TDDの基本的な解説をいただき、要所要所で質疑応答をしてゆきました。

●綺麗なコード
　驚きの少ないコードと定義する
　変更できるコード（壊さずに）

●基本的な進め方
　RED・GREEN・REFACTOR３つの帽子をかぶり分けて作業してゆきます。

RED
1. 前提として十分に綺麗なコードであること
2. テストコードだけを編集する
3. NGになるとわかっているテストコードを書く
GREEN
1. プロダクトコードだけを編集する
2. １つのテストコードがGREENになるようコーディングする
3. ５分以上かかるようならやめる（複雑すぎる、問題領域が広すぎる）
REFACTOR
1. プロダクトコードだけを編集する

自分が考えていたものとは全く違ってて驚きました。
過去にC++でTDDをやったことがあります（因みにMinUnitを改造して利用しました）
その時には、まずはUMLでクラス図とシーケンスを作って大筋を設計。さらにクラス／メソッド単位に詳細な処理記述を行った仕様書を作成し、それにそったテスツコードを作って、PG担当の方へテストがクリアするようにしてと投げというやり方です。

しかし今回感じたのは、「テストコードは期待する振る舞いを表現したもの」であるということ。なので「RED・GREEN・REFACTOR」というのは、設計→実装→検証→リファクタリングを繰り返しながら創り上げてゆくことになります。これをきっちりやっていければ、「綺麗なコード」になるはずよねです。勉強になりました。

大抵のプログラムは少しずつ仕様が変わっていき、が少しずつ壊れ、歪んでいって、すっかり見づらいプログラムになってしまいます。しかしテストコードがあれば後からでもリファクタリングできます。製造工程にはパートナーさんが関わることが多く、リリース後の変更で苦労します。そんな状況では取り組む価値のあるものだと強く思います。また「コストに見合わないテストは書かない」という割り切りも意外でした。勝手なイメージですが、全てについてテストコードを書くようなものと思っていたのですが、今はもう少し軽く始めてもいいんだという気持ちです。

●質疑応答からいくつかポイントを

RED以前の綺麗でないコードはどうするのか
- 「レガシーコード改善ガイド」を参考に、信頼出来るツールを使って機械的に綺麗にしてゆく。人手でやると動作しなくなることがあり得る。
問題領域を狭める
- JavaScriptやデジカメでのTDDについて相談されていましたが、問題領域が広すぎるではないかということでした。「やりずらい」と感じたら対象領域を見なおしたが方よさそうです。
モックの適用範囲は？
- 切り離したいものがある場合。ただモックは空じゃないので、作りすぎるとコストもかかるし、モック自体の品質やメンテなど問題がありますね。
標準プロセスに沿わないため受け入れられないことがある
- TDDを行うと障害密度が０になる。これは手法が違うのだからメトリクスも変える必要がある

■ペアプログラミング＆テスト駆動開発＆継続的インテグレーション体験ワークショップ
●ペアづくり
●環境構築
●第一イテレーション
●第二イテレーション
●振り返り（KPT）
●第三イテレーション

これは面白い取り組みです。
Github上に用意されたテーマプロジェクトを各チームがクローンして開発を進めてゆきます。ローカルでコーディング＆テスティングが終了すると、オリジナルのMasterリポジトリへPushします。するとクラウド上でビルドおよび受入テストが実施されるというものです。これらの状況および結果はWEB上で確認できるようになっており、他チームの進捗がとても気になります（笑）

因みに最初の課題「意気込み」は、我がネズミさんチームが最初にクリア！
そうそう書き忘れましたが、今回は「JUnitの経験のある方＆ない方」でペアを作りました。私とペアになった方は先に挙げたTDDの経験がある方で、一つ一つ丁寧に「こうやるんだよ」と指導してくださり、とてもスムースに理解できました。

●西さんからのアドバイス

楽しいすぎると
- 「技術者が楽しいもの」になり、本来のゴールから外れてしまう
気が合いすぎると
- 盛り上がりすぎて脱線してしまう
休憩を取ろう
- ペアプロ中は自分のペースで休憩が取れない。また常に速いテンポで進んでゆくので非常に疲る。生産性高く作業するためには休憩をキチンと取るということが大切！因みに「お菓子の消費量」をメトリクスに観察すると、第三イテレーションでは急激に消費が進んでいました。やはり疲れてくるんですよね。

■懇親会からメモ