TDD Boot Camp 東京 1.6( #tddbc )参加メモ

TDD Boot Camp 東京 1.6へ参加した際のメモです.

今まで,なにかとTDDは話に聞いていて,興味を持っていたのですが,
私自身が楽に書ける言語がC言語位で参加できずにいました.
しかし,今回はC言語でもTDD Boot Campに参加可能となったので,参加してきました.

C言語チームおよびTAの@tosikawaさん,主催者の方々,講師の和田さんありがとうございました.


■全体感想

  • 講演を聴いたすぐ後に体験で腑に落とすのは良い.
  • 他言語の話を聞くのは別の観点が生まれて興味深い
    • ただし,時間は足りなくなりやすい.
  • 多言語で同じお題とするのは,言語標準ライブラリなどのサポート差によって,大変さが異なる.
    • お題をこなすことが目標ではないので,大きな問題ではないが.

■和田さん講演

  • TDDBCは教わるだけでなく,体験して欲しい
    • ペアプロが自分にどんな効果をもたらすか感じて欲しい
  • 11/5横浜
  • ソフトウェア開発の三本柱
    • バージョン管理
    • テスティング
    • 自動化
      • 最も大切なモノはバージョン管理
  • バージョン管理
    • ソフトの歴史を管理する
  • 自動化
    • 大事なことは機械ができることと人間ができることを分けて考え,機械ができることは機械にやらせる.
      • すこしずつでいいから機械ができることを増やしていく.
    • すすむと,だめなときだけ機械が人に働きかける.自働化
  • 三本柱というより,三脚
    • 一本でもかけるとたちゆかない
  • テストという言葉は範囲が曖昧.
    • 誰が何のためにやるのかという視点で再分類する
      • 開発者テスト:開発促進
      • 顧客テスト:進捗管理
      • 品証テスト:品質保証
    • 単体テストなどの,大きさや対象ではない,別のテスト分類
  • 開発者テストを追求していったものがTDD
    • KentBeckのTDD本が参考になる
      • 訳は色々言われるがコードはうそつかない
    • フィードバックの速さと回数が開発/TDDの鍵
    • 最初のテストがある意味動く仕様書になる
    • コードをきれいにするのはリファクタリングのみ
    • リファクタリングを強く意識しないと,テストは通るけどコードが汚いままになる.
    • リファクタリングが一番大事
      • 【疑問】どこまできれいにするのか?
        • 【TAの@tosikawaさん曰く】後で,手を入れることがわかっているならば手を入れられるようにする位.もしくは時間内でできるところまで.
    • 黄金の回転モデルが一番大事な図
  • TDDの心持ち
    • 1つずつ,少しずつ
      • 分割するのはスキル.練習が必要.
    • ひとりずつ仕留める
      • 1対多ではなく,1対1の連続にする
    • すばやくまわす
    • 自分が最初のユーザ
      • 使いやすさなどがわかる
      • ドッグフード
      • 使い手になることで,動けばいいじゃんから脱する
    • 道具にこだわる
      • ツールの改造や調べていくことを貪欲に.
    • 不安をテストに
      • 品証や顧客用のテストはテスト技法からつくっていく
      • TDDのどこの,どこまでテストを書くか,に対しての解
      • TDDのテストは開発者の不安を解決ためにおこなう.
    • 祈るのでは駄目だ
    • テストが命綱
      • 命綱は常に編みこんでおかないとダメ
  • なぜTDDをするのか
    • 完璧ではないから
    • すばやくフィードバックを得たい
    • TDDは目的ではなく手段
      • 最大のメリットは心理的側面
        • 即時にフィードバックを得るため
        • 書いたコードに自信を持つため
        • これから書くコードに自信を持つため
  • TDDの目的
    • 健康
      • コード
        • ムダのない,引き締まったコード
        • 変化に対応しやすくなる
      • チーム
  • TDDは個人スキルなので,自分だけで始めることができる


■事例

  • 調査論文がいくつかでている
    • バグ密度低下
      • IBM-Driver:4割,MS-Windows:6割,MS-MSN:7.5割,MS-VS:9割
    • 実装時間
      • 総じて,2割,3割増
  • ざっくりというときは,「バグは半分,実装時間は2割増」
  • エリクソンの事例の開発者アンケート
    • 96%の開発者がデバッグ工数を減らすと感じた
    • 50%の開発者が開発工数が減らすと感じた
      • 軽微なデバッグがなくなる.複雑な場合でも問題分割でき,修正が容易となる.
      • 実装時間は増えるがデバッグ時間が減るので,開発工数が少ないと感じられる

バックログヌーラボ紹介

■デモ

  • TDDの主眼
  • ペアプロの感じを見て欲しい
  • ゴールから書いていく
    • 利用者の視点
    • ゴールから書いていくのでコンパイルエラーはほおっておく.
  • テストコードの中にメソッドをつくってしまっても良い.
    • t-wadaさんは,育ってきたら,それをプロダクトコードへ移すやり方をしている.
  • 仮実装:fake it
    • グリーンにする最小のサイクル
    • 複雑な問題なときほど,仮実装の価値はある.
      • テストのバグが明確になる.
      • テストコードのバグをチェックする
    • テストコードとプロダクトコードは交互にチェックする
  • 仮実装の段階では,テストコードのリファクタリングなどが考えられる.
  • triangulation:三角測量
    • 仮実装を再び設計のラインに載せ直す
  • バージョン管理
    • 中央型と分散型で異なる
    • 基本はレッドの状態でコミットしない
      • グリーンのタイミングでコミットする
    • ただし,分散型の場合,手元は開発者のものなので,好きなときにコミット
      • テスト書いたらコミット,コード書いたらコミットなど.
  • 最小サイクルの2択: 仮実装と三角測量 or 明白な実装
    • 仮実装と三角測量でTDDをまわすのが小さいサイクル
      • 不安が大きい場合
    • テスト書いてすぐ実装する場合もある
      • 明白な実装
      • 不安が小さい場合

■演習時のメモ(13:30-15:00,レビュー&休憩,15:30-17:00,レビュー&休憩)

  • C言語チームは環境自体をどうするかから議論開始
    • 結局,仮想環境上のgccチームと,まさかのHEWチームに.
      • WEB系の開発者にはマイナーですが,HEWはルネサスマイコンSH/H8シリーズ向けの開発環境です.
  • 第1ペア:@mayonezudaiouさん
  • 間違って実装を先に行ってしまった場合には,テストまでつくって,実装をバックさせてテスト実行させる.その後実装を戻し,グリーンになるか確認する.
  • CUnit/CPPUnitだとメッセージだせる
  • 第2ペア:@twilight_breezeさん
  • CUnitだとオプションで,メモリ解放していないものを表示することができる.
  • 不安が一杯出てきたときは,とりあえず全部メモするなり,テストコードにしておくなりして,だしておく.
    • ただし,やるかどうかは別.
  • テスト書いても,テスト登録すること忘れがち
  • テスティングフレームワークとして,Cutterを使ってもみたかった.

■bleisさんのF#(MSのMVP)実装

■和田さんの応用についての話

  • テストコードのないコードがいっぱい
    • レガシーコード改善ガイド
      • コードのないコードに対,してどうしたらいいかが書かれている
  • 既にデータの入ったデータベースがある
  • テストが脆い
    • 仕様が変わるたびに,コードを変更しなければならないテストを,脆いテストと呼ぶ
  • テストが遅い
    • xUnit Test Pattern
    • 元ネタはwikiにある.本のほうが詳しいが.
  • Growing Object-Oriented software guided by tests
    • モックの概念を作った人たち
    • #goos_jp
  • プロとしてテストコードを書く嗜み