Readingagilesamuraiinchiba20120818
参加者は、自由に編集してください。
- 3名
- 第5部
- 実施範囲について、解釈を加える
- ユニットテスト
- リファクタリング
- テスト駆動開発（TDD）
- 継続的インテグレーション
- xUnitテストツールは、広く一般的に知られるようになってきた
- ただ、適用していないプロジェクトはまだまだ多そう（参加者の参画しているプロジェクトでは、適用していないケースもあるとのこと）
- ウォーターフォールを採用しているプロジェクトでは、使っていないことが多いのかも（あくまでも参加者の感覚的な統計からの推測）
ただテストコードを書けばいいってもんじゃない
- テストする観点を考えて、もれなくテストすることが大切
ユニットテストすると、なにがいいの？？？
- 素早くフィードバックが得られる（当初想定の設計では実現できねんじゃね？とか）
- リグレッションテストにも使える
- デバッグ時間の短縮
- 自信を持ってデプロイできる
「小さな改修に、テストコードはいるのか？」
- いらないと思う理由
- テストコードを書く時間がもったいない
- 後続のテスト（IT、ST、QA）でリグレッションテストが可能であれば、ここでのテスト未実施は大目に見る
- 品質を保持し続けられる裏付けや確証があるなら（または品質に影響しないことがあらかじめわかっている）、あえてテストコードを書かなくてもいい
- めんどくさい・・・
- めんどくさがらずに書こう！
- 顧客がテストを望んでいない（納期だとか予算だとか不具合の軽視だとか理由は様々）
- 不具合が発生する可能性のあることを承知してもらいましょう
- ビジネス上の損失にかかわるであろう不具合が発生するかもしれないのであれば、そのことを説明しテストすることを認めてもらう
- テストコードを書く時間がもったいない
- いると思う理由
- 不具合は常に発生するものとして考えている
- なので、テストしないと品質を保証できない
- 結果的にコストを抑えている
- 不具合発生 ＞ 修正というサイクルが多発することを抑制できる
- もしかしたら損害賠償問題に発展するかもしれない問題を未然に防げる可能性がある
- 継続的小改修による影響範囲の拡大を抑止できる
- 小改修が積み重なることにより、新たな不具合が組み込まれ、これが継続的に続くと次第に影響範囲が拡大する恐れがある
- 小改修も積み重なると大改修。あとから不具合を見つけた時には、すでに手を付けられない状態になっている可能性も・・・
- 細かくテストすることによって改修の影響範囲を狭め、結果的にコストダウンにつながる
- リファクタリングしやすくなる
- テストコードがあれば、安心してリファクタリングできる
- リファクタリングできないと、いずれ手におえないコードになる
- 不具合は常に発生するものとして考えている
「実践！テストケース作成」
本に書いてある、「カードデッキを作成する」についてのテストケース作成を、我々も考えてみる。
- 考えたテストケース
- 52枚のカードがあること
- 52枚が、クラブ/ハート/スペード/ダイアの各13枚で構成されていること
- 同じ絵柄のカードが含まれていないこと
- コードは常に「移ろい行く」ものである・・・
- 最初にコーディングした人が、未来永劫面倒を見てくれるとは限らない
- 修正にかかるコストがかさむ
時間がたってもコードを理解しやすくするために、リファクタリングを行う
- リファクタリングの特典
- 別の人（または半年後の自分）が改修することになっても、コードの理解がしやすい
- コスト低減につながる（コードの内容を理解するだけで時間がかかるとかよくある）
- 積極的にリファクタリングしよう！
- 毎分リファクタリングしてもいいぐらい
ただし！テストコードは書いておくこと
または、リファクタリングとともに、新たなテストコードを書く
「さて、そろそろリファクタリングでもすっかなー」
/＼＿＿／ヽ ヽ
／ ::::::::::::::::＼ つ
. | ,,-‐‐ ‐‐-､ .:::| わ
| ､(o)_,: (o), :::|ぁぁ
. | ::< .::|あぁ
＼ /( [三] )ヽ ::／ああ
／｀ー‐--‐‐―´＼ぁあ
- ということで、気づいた時にはもう手が付けられない
- そもそも手を付けてもいいものかわからない・・・
- リファクタリングする！ただし、デグレしないようにテストコードは書いておきましょう
- リファクタリングよりも実装を優先させられる
- 実装が終わったら、一度立ち止まってリファクタリングしてみる
どうやってリファクタリングの導入をするか？
- チームのルールにしてしまう（こまめにリファクタリングしましょうとか）
- 常に意識しておく
- コードレビューで指摘してあげる
- レビュー観点にリファクタリングをいれないとダメ
- リファクタリングすべき個所を見つけたら、TODOにしておく
- ケント・ベックさんの「テスト駆動開発入門」が、TDD導入としてはオススメ
- TDDは慣れるまでに時間がかかる
- いきなり全部をTDDで開発するよりかは、一部だけTDDにしてみて慣れさせる
- 継続的に、システム全体を結合する作業
- 以下の4点について準備をする
- リポジトリ（CVS、SVN、Git、Mercurial（マーキュリアル）などなど）
- チェックイン手順
- ビルド自動化（Ant、Mavenなどなど）
- 作業単位を小さくする心構え
- リポジトリ
まあ、いまさら語る必要もないので割愛。 - チェックイン手順
- プロジェクトでルールを決める
- ビルドエラーのまま帰らないとか
- テストしたもの以外はチェックインしちゃダメとか
- これらを手順化して、メンバーに浸透させる
- プロジェクトでルールを決める
- ビルド自動化
- 現在は、ほとんどの言語で自動化できるツールがあるので、積極的に取り入れる
- 自動化のメリット
- 開発者がビルドに時間を割かなくて済む
- エラーが早期に発見できる（大きな手戻りが減る、ゆえにコストも下がる）
- 作業単位を小さくする
- こまめにチェックインする
- 早めに結合して、不具合を早期に発見する
全5回に渡って「アジャイルサムライ読書会」を行ってきました。自分も含め、参加者はアジャイル開発ということについて、知識を深めることができたと思います。ほんとは、実際の開発現場の体験談などを、LTを通して発表できる場を設けたかったのですが、なかなかそこまで準備を進めるに至りませんでした。
さて、この読書会の当初の目的である「アジャイルってほんとのとこどうなの？いいの？」という懐疑的な疑問に向けた解決について、明確な答えがでてきて目的が達成できたかというと、実のところあまり達成できていないかもしれません。というのも、私自身、学んでいくうちにアジャイルが楽しいなーと思って、当初の懐疑的な疑問を忘れてしまったからです。アジャイルサムライさん、ぱねえっす。
これからアジャイルについて学んでみようとか、自分みたいに懐疑的に思っている方のために、読書会を通して学んだ知識をもとにひとつだけアドバイスしておくと、アジャイルだからといってドキュメント作成がなくなるわけではないです。従来と異なる点といえば、ジャスト・イン・タイムで必要な時に必要な量のドキュメント作成になる、というぐらいです。なので、ドキュメント作成もテストもなくなるわけじゃないですよーということを、理解しておいていただければと思います。
私自身、いまだ自分のプロジェクトを持ったことがないのですが、いつかプロジェクトを持つ立場になったときに備えて、アジャイル含めいろいろな開発手法を学んでおきたいなあと思っています。そのときにはまた、読書会なりなんなりを企画したいと思いますので、ご興味のある方は、ご参加くだされば幸いです。
以上