Agile Samurai Base Camp 2013/12/8 議事録
Agile Samurai Base Camp
2013/12/8に行われた、Agile Samurai Base Campの個人的なメモです。
誤字や間違った見解のメモなどあるかもしれません。。
TDDで開発の効率が上がるかはやってみないと分からないが、
品質向上と、不安を減らすという意味では間違いなく正しいやり方だと思います。
セミナーの前から、頭では分かっていても、なかなか実践できていなかったので、
この機会に少しずつテスト駆動で実装してみたいです。
■ 基調講演（角谷さん）
・Whole One Team
顧客が何を作るかを決める。開発チームがどうやって作るかを決める
・テストやリファクタリングを行いながら開発する
書いたコードはいつでも動くような状態にしておく
テスト駆動開発をすれば、テストしやすい設計になる。
参考本
・エクストリームプログラミング入門にジョナサンは一番影響を受けた
・リファクタリング〜プログラミングの体質改善テクニック〜
・エクストリームプログラミング実行計画
・テスト駆動開発入門
・アジャイルな見積もりと計画づくり
＋インセプションデッキ
＝アジャイルサムライ
ソフトウェア開発がアジャイルであるとは？
・開発がアジャイルであるということは、協調性を重んじる環境で、フィードバックに基づいた調整を行い続けること
ベロシティとかどうとか、こだわりすぎるのに意味はそんなにない。ゴールを達成するためにどうすれば良いかを考えて改善していくことが大事。
1. 学んだことを他の人に共有すること
2. 常により良い方法を探し続けること
3. 楽しんでください
--------------------------
TDD(和田卓人さん)
アジャイルプロセス
・協働でゴールに向かう「チーム環境」
・高速に石橋を叩いて渡る「開発環境」
TDDとは
・ユニットテスト、リファクタリング、テスト駆動開発、継続的インテグレーション
・動作するきれいなコード
この完結な言葉はTDDの目標で、あらゆる理由で価値がある
・設計→実装は難しい。正解となる設計は何か、誰も言えない
・いざ作ってみたら、漏れやこっちの方が良いなどが出てくる
TDDサイクル
1. 次の目標を考える
2. その目標を示すテストを書く
3. そのテストを実行して失敗させる(Red)
4. 目的のコードを書く
5. 2.で書いたテストを成功させる(Green)
6. テストが通るままでリファクタリングを行う(Refactor)
7. 1〜6を繰り返す
リファクタリングが行えなくなると、黄金の回転が回らず、負債となっていく
リファクタリングはテスト駆動開発のステップの１つ。リファクタリングをします、だけは通らない
参考本：リーダブルコード
TDDのこころ
1. １つずつ、少しずつ、段を小さく
2. 大きいタスクを小さいTODOに落とし込み、それぞれをテストする
複数を相手にしない。ひとりずつ対処する！→ TODOリストから持ってきてerrorを消していく
3. 素早くまわす（フィードバックサイクル）
4. 自分が最初のユーザ（自分で書いたコードを最初に使うのは自分）
テストから書き始めるということは、使う側からこういうのを使いたい、という立場からコード実装に入れるということ。
使いやすいコードを自分で判別して実装する仕組み
5. 不安をテストに
自分の手を止めている（不安）ことに対して、テストコードを書きましょう
getter, setterにテストは書く必要（不安）はない。メインコードだけテストすればいい
テスト駆動開発をしておけば完璧ってことじゃなく、自分たちの中で質の高いコードを作り、他の人が参画した時に入りやすいようにする
・命綱を編む（書いてきたテストコードが自分たちを助けてくれる）
急激な市場や設計の変更に対して柔軟な対応を行えるように。
TDD、Developper Testingのメリットの最大の理由は心理的なもの
・即座にフィードバックを得るため
・書いたコードに自信を持つため
・これから書くコードに自信を持つため
テストは目的ではなく手段
・TDDの真の目的とは、健康
変化に対応するのは健康体のコード
変化に対応するのは健康体のチーム
不安の克服、健康の維持
テストのメンテナンスがめんどくさい→ 不吉な前兆
たくさん直さないといけない時は、実装のテストになる
テストの変更が多い時は、テストの書き方がよくない
仕様変更に対してのテストがめんどくさい、というのはTDDにとっては言語道断
カスタマイズしたテストフレームワークを独自に作っていく
------------------------
javascript TDD
・qunit, jasmine, mocha, sinon, phantomjs
-------------------------
和田さんQ&A
・テストを先に書くことでストレスは感じるが、結局テストしないといけない。
人間が出来ることを機械にさせないと。
・テストを書くことで実装をきれいにすることが出来る。設計を一部簡素化したり。
気づいていなかった例外に気づけたりする
先に書くことが駆動するということじゃない。テスト書くことでフィードバックされることが大事
・テストを作る設計に時間がかかってしまう
C開発はテスト駆動開発において、ハンデをかかえている
しかし、現在、進化が著しいのもC。仕方がない部分も大きいのでノウハウをためていくしかない
C++はGoogleTestとかがxUnit系かな？
・テストが汚い
共通化しているところとかは関数化してしまう
テストコードのテストは実装にやらせる
テストと実装の差が少ないうちにリファクタリングしちゃう
・TDDはデバッグ時間を、ほぼゼロにすることが出来る方法
・テストのカバレッジレベル
カバレッジ率100を求めることではない：仕様を100%カバーしてるというわけではないため
カバレッジ上げる作業は設計をよくしていく良い方法だが、やり過ぎるとおいしくない作業になる
eclemmaでカバレッジテスト
・テストデータつくるところ
テストデータの違いだけがかけるようにして、後はFactory作ったり、パラメータ化したり、関数化することでリファクタリングする
・テストをリピータブルにするためには、データを統一化させておかなければいけない
・テストで一番大事なことは繰り返し使えること。その事前データを作ることは何よりも大事なので、DBのデータなどは必ず統一できるデータを作れるようにしておくこと。
１人１人のコードが全体のコードを作るような設計になる。
そのほうが、１つ１つのクオリティが高いため、結果的にうまくいく。体感するとわかる
テスト単体で完結しているかどうか、で独立性の高いプログラミング実装タイプになる
・リリース終わったもので、リファクタリングが甘いもので、なおしたいとこ見つけた場合
Green To Greenなので、Redは考えなくてもいい
必ずしもリファクタリングすべきでない部分は、リファクタリングしないほうがいいかも
・テスト名が仕様書になるので、TODOメソッドを羅列して、全部Ignoreにして、随時作っていく
テスト駆動開発は、はじめはみんな遅い。慣れれば早くなる。
・テストをどこまで書けば良いか分からない
全てのテストを自動化する必要はない
クラス単位の動作確認は、自由にやるが、画面として組み立てた場合はブラウザからって方法などパターンはいくつかある
どのレベルを自動化するかっていう網のレベルを決めて、どこまでjunitでやるかの決めはない
テスト書いても安心できないっていう不安は良いこと。テスト技法を学ぶ段階。
テスト駆動開発の先に、どこまで書けば良いのか、漏れを知る必要あるのか、っていうのがある
そういう研究が日本で盛ん。書籍で6つくらいをテストしたら全パターン網羅するというようなテスト技法がある。（参考本：ソフトウェアテスト技法ドリル）
---------------------------------
MTI（中川さん）
・テスト駆動開発導入前
リリース時に大量のマンパワーを使ってテストを実施するか、デグレで障害ということも。。
・テストコードは品質保証のために書いていた
プロダクトコードからテストすると、書きにくいという時も。仕様変更でテスト壊れる。。
・メリット
テストコードが増えた。
テストが壊れにくくなった
プロダクトコードが読みやすくなった
コードの再利用がしやすくなった
安心して他の人が書いたコードを修正できるようになった
・難しいところ
従来開発スタイルからの頭の切り替え
時間的な制約
レガシーコードとの戦い
---------------------------------
レガシーコードでTDD力を高めよう（@PoohSunny）
・レガシーコード改善ガイド（本）
・一部の変更が全てに影響（＝レガシーコード）
テストが書きにくい構造（実践しようにも…）
・レガシーコードの改善じゃなく、自分のTDD力を高めよう、っていう考え方
TDDから：が最適解とは限らないため、TDDで改善は考えない
・変更は小さいところからやる
・スプラウトメソッド
---------------------------------
濃霧と地雷原（アルティメット 有野さん）
・不安解消、見える化、少しずつ
・Cucumberによる仕様の見える化とテストの先行実装
HTMLレポート見るとなんとなくわかる
---------------------------------
質問
・従来型の開発で切り替えれない人に対してTDDしてもらう方法は？
経験してもらうことが大事
体験型のワークショップを社内でやったり、実際にテストコードを入れていくとかしかない
やってもらって、やりにくいと思われたら、こういう風だからやりづらいんですよっていうことを伝えてあげる。品質向上のためじゃなく安心のためにやることを伝える。
テストコードを書くのに懸念する人に対しては、トップダウン形式で落としている
・テスト駆動開発を始めた時の生産性を下げない工夫は？
最初は3割くらいは生産性が下がる。下がった分は後でカバーする。マネジメント層の理解が大事
ただ、それがやれていくと、効率は上がって、開発者の不安は取り除かれる
レガシーコードを分けてテストしたら逆にデバッグ工数減らせる。が、全体的には落ちるので説得も大事
・TDDになった場合にコードレビューする際の観点
テストケース単体のレビューは必要。
何がしたいテストなのか不明確な場合は明確にする
テスト対象がどこまでの操作をするのかを見る
小さい単位でテストができているかどうかに注目する
テストコードが1メソッドで大量にあると、何やってるのか分からないので色々やってるところは指摘する
・全員がテスト駆動しているのか？
全員やってるわけではないが、テストコードを書くようになった
・テスト駆動が会社に広まった時、日常的にそういう会話になったか？
部署によって違うが、自分のところは、環境作るところからTDDでやろうみたいになった
・TDDで内部設計など、テスト駆動されるようになったか？
大きいとこを全部テスト駆動は出来ない
合わないとこは、設計で決めて、フレームワーク選定などした上で、TDD開発をしていく
内部設計に合わせてシステムテストするなど、内容に合わせてやり方を変えていく
ある程度出来てからTDDで入る
Cucumberで外部仕様を決めて、その中身を実装していく
---------------------------------
境界なき現場を、行け（市谷さん）パパンダさん(http://about.me/papanda0806)
明日からやるのは実際には難しいという人のための昔話
日常のしごとをこなす技術だけあればいいんだっけ？
本「達人プログラマー」
常にあなたの知識ポートフォリオに投資すること
毎年少なくとも一つの言語を学習する
誰もが失敗するとわかっていて、それでもなお律儀に進み続けていくプロジェクト
理想とはたどり着くべき場所のことではなく、ありたい姿に向かい続けることなんだ！
理想：正しいものを正しく作る
ソフトウェアを創りあげるもの
・プロジェクト、ユーザ、チーム、顧客
どういうルールで、誰のために、誰が、誰と、「何を」作るか
