TDD Boot Campの感想

tddbc

「一番大事なことは最初に言う」とのことなので、大事なことから順に書きます。
反芻してるうちに思い出したら、追記するかもしれません。

  • ペアプロの前半のパートナーである@kozy4324とともにミルズ賞を受賞しました。
    • 「前半のペアでコードが綺麗だった。私はJavaはわからないが、何が書いてあるのか、どう動くのかがわかった。後半にペアを変えても、それぞれのペアで綺麗なコードを書いていた。」とのこと。最大級の栄誉です。
    • 個人的な理由の一つは、「いわゆるJava」っぽくないJavaが好きなので、Javaに慣れていない人向けなコードを書いていたこと。もう一つは、TDD読書会で存分に予習できていたことです。
    • @kozy4324はもちろん、TDD読書会のメンバーにも感謝です。
  • TDD Boot Camp Hokurikuを企画中です。3月予定。コーチ役としてid:t-wadaは欠かせないでしょう。Microsoftの長沢さん、通訳として活躍したアジャイルコーチのミルズさんも乗り気になっていただいてます。期待大。
    • 遠方からのゲストも来ることですので、合宿形式で妄想中です。ペアプロのハンズオンからハッカソンへと流れる感じとかいいですよね。安価でかつネットワークが提供される施設をご存知の方、情報ください。
      • 安いところならあるけど、ネットワークは必須ですよね…。
    • 参加人数は15名から20名くらい？
  • テストコードも、プロダクトコードと同様に無駄なコードは書かないこと。重複を消す。DRY。コピペ禁止。で、見通しがよくなる。
    • 自分たちのテストコードは、後で修正が面倒な段階まで「無駄」を放置してしまった。書いている最中はまったく邪魔にならないけど、振り返ると重荷を背負っていることに気付く。
  • ペアプログラミングについての説明は全くなかったけど、10分で慣れた。
  • ペアプロ後のコードレビューが面白かった。できたペアのコードはもちろん、できなかったペアは「どこで詰まっていたのか、どう方向を修正すべきだったか」を考えさせられる機会になる。晒さなきゃ損。
  • コーチ役は10名に1名くらいは必要か。ミルズさんによれば、10名が、チームがまとまる最大の人数だそうな。11名や12名になると、自然に2つのグループに分かれてしまうとのこと。
  • 「厳密なTDDは、並のプログラマには難しい」という話をよく聞くので、それに対する見解を聞いてみたかったけど、やめた。今のところは、コーチ役がいればそれほど難しい手法ではないように思ってたりします。
    • もしくは「TDDだ、ただし締め切りは変わらない」みたいな条件が課せられるとか？単純にコードの生産性が落ちる（15%から40%程度、時間が増えてしまう）とのことなので、それは難しい。
  • 自分を含め、初心者はテストコードを沢山書いてしまう。
    • 明らかにGREENになるのがわかってるのに書いてしまう。
    • たぶん、これは通過儀礼。
    • Unitテストは重複なく最小限で書く。受け入れテストやシナリオテストに該当するコードを別に持っていてもよい。
      • あらかじめ条件が明確化されているものについては、受け入れテスト的な「しばらくはREDなゴール」を書いてもよい。また、開発を進める中でそのゴールを修正してもよい。
      • TDDのテストはボトムアップ。ゴールはトップダウン。両方あっても良い。
  • 席はど真ん中のど真ん前に確保しろ。
    • 一番良く見える、一番良く聞こえる。周りのヤツらも本気度が高い。