Agile Samurai Base Camp
2013/12/8に行われた「Agile Samurai Base Camp」の参加レポートです。
http://www.agilesamuraibasecamp.org/
※2014/4に同イベントが開催されると更新されてます！！
会場は渋谷のサイバーエージェント。
扱う内容は、「インセプションデッキ」「テスト駆動開発」の2つで、参加者はどちらに参加するか選択できます。
このイベントに参加するにあたって、事前準備として次の2つを行いました。
①アジャイルサムライの購入(約2600円)＆目を通しておく(10hぐらい?)
⇒ この本の内容を踏まえた内容なので、目を通しておくに越した事はありません。
個人的には前半はペース遅め、後半はサクサクと読めました。
参加登録時点では「インセプションデッキ」にしていましたが、当日は「テスト駆動開発」に参加しました。
②一緒に参加する人の募集
⇒ これは前回参加した「DevLOVE甲子園」の反省を踏まえてです。
結論として、自分含めた3人で参加しました。
9時前に会場となるビルに到着し、案の定迷ったので警備員さんを捕まえて道を尋ねます。
本当に、東京の駅やらビルやらはどういう構造になっているか良くわかりません。
なんとか会場前に到着したのが9時10分ぐらい。
入れるのが9時15分とのことでしたが、すぐに入れました。
どうやら運営側を除くと1番乗りだったようです。
受付でQRコードを見せると、ネームプレートを渡されました。
「呼んで欲しい名前」「どっちに参加する」「理解度を☆3段階で」の3つを書くように依頼されます。
他にはtwitterアカウントや意気込みを書いている人も居ました。
一番前の席＠スクリーン正面からパシャリ
当初の予定から1時間遅れで始まります。
何やら会場トラブルとのことで、会場が他のイベントとダブルブッキングしたという...
テンション下がり気味での開幕となりました。
が、アジャイルサムライの著者Jonathan Rasmussonのメッセージ映像が流されるや否や、テンション元通りです。
よし、楽しもう。
■基調講演(10:30-11:20)＠角谷信太郎氏
講師はアジャイルサムライ監訳者の方です。
・実際に使う人が使える状態(=動くソフトウェア)を定期的に届ける。
・手元(自分のローカル環境)でしか動かない、ではダメ。
・アジャイルチームは大きく2つの人から成る
顧客…何を作るか決める
開発チーム…どうやって作るか決める
・Jonathanがこの本を書いた理由
アジャイル本沢山あるから書く必要なかったのでは？
→ バラバラのものが沢山あって、色々読まないと分からない
→ 1冊にまとめたらどうだろう？
→ 7冊の良書をまとめて、オリジナル要素(インセプションデッキ)を付け足してアジャイルサムライ書いた
・ソフトウェア開発がアジャイルであるとは？
"開発がアジャイルである"ということは、協調性を重んじる環境で、フィードバックに基づいた調整を行い続けることである。
■TDDどう始めるの？(11:30～12:10)＠和田卓人氏
講師はDevLOVE甲子園でも話を聞かせていただいた方です。
・システムを作る ×
システムを作り続ける ○
・テスト駆動開発入門
→ 「動作するキレイなコード」を書き続ける
良い設計→ロス無くコードに落とす
完璧主義の呪い
→もっと良い設計があるのでは？と思い、なかなか先に進めない
コードを書くときに
→綺麗だけどスピードが遅い(パフォーマンス悪いよね)
→綺麗だけど漏れがある(必要な処理が抜けてた)
※コードを書かないと分からない事は沢山ある!!
動く汚いコード→綺麗にブラッシュアップ
動くから良いよね
→堕落する
独活句コードを綺麗に出来れば…
→そこでテスト駆動開発
・TDDのサイクル
1. 次の目標を考える
2. その目標を示すテストを書く
3. そのテストを実行して失敗させる(Red)
4. 目的のコードを書く
5. 2で書いたテストを成功させる(Green)
6. テストが通るまでリファクタリングを行う(Refactor)
7. 1～6を繰り返す
・TDDと黄金の回転
失敗パターン
TDDの回転が回らなくなる時は、大抵の場合「時間が無い」という理由でRefactorが疎かになる。
・リファクタリングは溜めれば溜めるほど大変になる
→ 直近で価値の薄い(リファクタリング)ものに時間をかけられない
→ TDDではリファクタリングをサイクルに組み込む事で毎日行う
・TDDをやる上での心得
・1つずつ少しずつ段を小さく行う。
→ 大きいものを小さく割る。
・複数を相手にしない。一人ずつ対処する。
→ 1対多では勝てない。1対1の連続にすれば勝ち続けられる。
・すばやくまわす。
→ TDDサイクルを早くまわせるようになる。
・自分が最初のユーザになる。
→ 作り易いコードと、使い易いコードは異なる。
TDDはテスト(=使う側)から書くので、自然に使い易いコードを書くようになる。
※コードは書く時間よりも、使われる時間の方が圧倒的に長い。
・不安をテストに。
→ テストする場所は不安のある場所。
自分達の範囲で品質を上げる。
→ TDDやっているから品質に不安はない ×
人間の書くテストには漏れがあって当然
・命綱を編む
→ 急な変更に備えておく。
一つ一つのテストコードが網目となる。
・TDDやDeveloper Testのメリット
ソフトウェア工学上の理由もあるが、何よりも心理面が大きい。
・即座にフィードバックが得られる
・書いたコードに自信が持てる
・これから書くコードに自信が持てる
・テストは目的ではなく手段
目的は？
→ TDDの真の目的は「健康」
・変化に対応するのは健康体のコード
重複がない、分かり易い名前、分かり易い構造
・変化に対応するのは健康体のチーム
リファクタリングのスキルUP→定時に帰って健康に
・不安の克服健康の維持
QA
Q. テストを書くと仕変のメンテの手間が増えてしまう。
A. テストのメンテに時間がかかるのはテストに問題がある可能性あり。
仕様が大きく変われば、テストも大きく変わるのは当然ではあるが、無駄な書き換えが発生しないようにテストを書きましょう。
■Javaによるライブコーディングデモ(13:15～13:45)
TDDが実際にどのように行われるか、ペアプログラミング形式によるデモ。
■アンカンファレンス(13:55～14:45)
・初心者向けコーナー
・Javascript版ライブコーディング
・実践者向け質問コーナー
TDDの用語
・仮実装
・三角測量
・明白な実装
Note
テストを書く時は、Assertから書いたほうが何をするかが明確になる。
テストクラスのメソッド名は日本語にすると、eclipseの左側見たとき分かり易い。
QA
Q. 仮実装(return true; だけのメソッド)する意味は？
A. 仮実装でこけたら、テストコードの側に誤りがあることが分かる
Q. プロダクションコードとテストコード両方リファクタリングする？
A. テストコードも分かり易くしておくべきなので、両方行う。
■TDD事例
TDDメリット
・テストコードが増える
・テストが壊れにくくなる
・プロダクトコードが読みやすくなる
レガシーコード
・一部の変更が全てに影響
・ジェンガ / スパゲッティ
・動いているコードに触るな
普通の開発経験豊富な人(プロダクト書いてからテストする)はTDDを受け入れない。
→ これまでのやり方で出来てたんだから良いじゃないか
QA
Q. どうアプローチすれば良い？
A. TDDを経験して貰うしか無い。
体験型ワークショップをする。
トップダウンで社長にTDDやってもらって「これ良いよー」アピールしてもらう。
Q. TDD導入で生産性どのぐらい下がるものなの？
A. 体感で3割。下がった分は他でカバーする必要あり。
レガシーコードに導入したら工数が5倍以上になった経験あり。
5倍以上に膨れても、その後のデバッグを考えると、総工数がトントンか寧ろお得なぐらい。
Q. テスト書くときのコードレビューは何を見るの？
A. テストケースのレビューが必要になる。
何をしたいテストか分かるか、とか、Assertは一つに絞られているか、とかを見る。
■基調講演＠市谷聡啓氏
講師はDevLOVE創始者。
"リーン開発の現場"という本を出した。
P109にこんなことが書いている。
"理想とは辿り着くべき場所のところではなく、ありたい姿に向かい続けることなんだ！"
ソフトウェアを創り上げるもの
・プロジェクト
・ユーザ
・顧客
・チーム
1日1個何か学べ→1年で365個学べる
