TDDBC仙台01 KPT

TDDBC仙台01について、参加された方々、講師、運営スタッフ、様々に感じたことがあるかと思われます。

そこで、皆様の感じたことをKPTとしてここに集めたいと考えました。

TDDBCの更なる発展のため、ご協力いただければ幸いです。

• 細かい単位でテストをする*3
• ペアプロ*4
• 第二回も参加したい*2
• Groovy!Spock
• TDDの実践
• 小さく細かく一歩ずつができた
• テストを地道に出来る大きさで積み上げることを体感できた
• 積極的に参加できたこと
• 3人で乱取り形式ははまらなくて良かった
• TDDに触れることが出来て良かった。楽しかった。
• 疑問に思ったことをちゃんと聞いて解決する。メンバー間で共有する
• おやつ付き
• 短時間で交代すること
• Red->Green->Refactoring
• 事前にチーム分けしておいたのは良かった(運営)
• 撤収作業が順調に終わった(運営)

• NUnitにやられた。道具は大事
• 他の人のコードの意味が分からないことが分かった
• サポートなのに実装しすぎた
• タイムマネジメント
• タスクの分割がうまくいかない
• コードの細分化が難しい
• 仕様を読み違えた*2
• 開発環境ちゃんとつくっておかなかった
• バージョン管理が出来なかった
• 実装にものすごく時間がかかった
• レッドが出ない
• 途中で大きな仕様を考えない
• ScalaのAPIを使いこなせていない
• ペアプロ時に他人のコーディングを冷静に評価できなくなった
• 道具にこだわりがないこと
• 他の人のコードレビューがうまくできなかったこと
• どのタイミングで本格的な実装を始めるか
• リファクタリングが十分に出来なかった*4
• テストケースの粒度が大きすぎるものがあった
• テストの粒度が大きかった*2
• 向き合わせのテーブル配置で乱取りすると交代しづらい？
• PHPチームのサポートが十分に出来なかった
• TAはTAに集中できるようなチーム編成が良かったかも
• 用意したお菓子が多すぎた(運営)
• ポジションペーパーを有効活用できなかった(運営)

• ソース管理にTFS使ってみたい
• jMockかMockitoを使いたい
• バージョン管理*4
• スピードアップ
• データベースがからむテスト
• 状況駆動のテストってなんぞ！？やってみたい*2
• 発表
• 文脈ベースのテスト
• テストの自動化
• レガシーコードのリファクタリング
• Jenkins使いたい
• 他の言語でのTDD実践(Scala,Groovy)*3
• TDDでの開発
• リファクタリング
• 受け入れテストの自動化
• Ustの「やる/やらない/できたらやる」は告知サイトに明示する。当日になって「あるのかな？」となるとモヤモヤするし、「（できれば）講演のみやります」とアナウンスすれば、朝起きて見たい人もいるかもしれません。
• 午後の演習は「雰囲気をしりたい！」って人は少なからずいるようなのでUstではなく、写真を多めにとっておき、（ぼかして）公開してみる
• テーブルの配置を縦並びにするなど人が回転しやすいように考える
• GroovyチームとJavaScriptチームを作りたい
• 事前にキーボード情報(物理、論理)を集めておく(運営)
• 事前に写真などの顔出しOKか聞いておく(運営)