TDDBC大阪2.0/記録

KPTから

• ドライバー/ナビゲーターの入れ替えがなく消耗した
  • 10分で強制的に交代させる
• FizzBuzzについてきっちりした説明がなかった
• デモTDDはしこみでよいと思う
  • スタッフでデモのストーリーを予め決めておく
• リファクタリングにあまり時間を取れなかった
  • 課題に「リファクタリング」を追加
• タイムテーブルを守る
  • TAはタイムボックス厳守に協力
• TA、スタッフの作業で気が散ってしまっていた
  • TAの各種作業は別の場所で行う

スタッフ意見から

• 慣れている人同士、初心者同士+TAでペアを作る
• ロビーとエレベーターホールで誘導係を用意する
• 個別に質問されたことはTAが後から付箋で全体共有
• スタッフは1時間前に集合して朝会
• 希望言語一覧をGoogle Docsで公開

KEEP

• すばらしい講師陣
• 知らない言語に挑戦したこと。Groovy!
• テストも進化しているので勉強して新たなことを仕入れるのは続けない
• ペアプロが思った以上に楽しかった(ただ自分のコードが稚拙ではずかしい)
• 初めてのペアプロ
• ペアプロでテクニック伝承
• ペアプログラミング
• ペアプロを経験できた
• ペアプロ。初めてやったが気づきが多かった。でも次やったときはあきてる気もする。継続してやりたい。
• ペアプログラミング。ベースの知識が違うと得るものが多い!
• Testを書くことによる安心感を実感できた
• テストコードを書いて実装することでリファクタリング時に安心して変更できることを実感できた
• Red/Green/Refactorを"速く"まわす
• 「TDDかくあるべし」みたいなことはあまり考えなくていい。とにかくテスト書けってこと。
• 楽天食堂スバラシイ!!
• テストコードの作成にGroovyとSpockを使ってわかりやすいテスト実施する
• Groovyに触れたこと
• Javaアプリケーションに対してSpockでテストコードを書く。シンプルで読みやすい。
• よりよいテスティングフレームワークSpockに触れたこと
• テストコード、プロダクトコードの書き方の意見交換できた
• ふりかえりでコミュニケーションエラーを指摘してもらえた
• 実際に手を動かしたことでTDDのよさを実感できた
• テストを書くのは楽しい。自分のコードのへたくそさがよくわかる。
• 不安と思う実装に対しテストコードを書く
• 目標をテストで表現するという考え方が気に入った
• 運営準備が入念だった
• スタッフと参加者の人数が丁度良かった
• 楽天カフェテリアがすてき
• 楽天カフェテリアさいこう!
• ペアプロを体験できたこと
• テストフレームワークを使用してテスト/実装のサイクルをまわせた

Problem

• 組み込みの実機への導入は難しそう
• 実践する時間の確保
• TDDがチームに受け入れられるか不安→Testしたい
• 会社・上司の理解
• ペアプロでの気づきがあったが、共有できなかった
• コミュニケーション。もっといろいろな人ととった方が良かったかもしれない。
• ペアとちゃんとコミュニケーションとれてなかった
• パートナーのナビゲーションというよりも、自分の意見の押し付けになっていた時があった
• パートナーの交換がない
• 環境構築のTipsがどこかにまとめられているとなお良い
• 環境構築がむつかしそう
• 環境構築準備不足
• ゼロから環境設定することに慣れてないと、今日のような場ではバタついてしまう
• 演習での開発はもう少し小さなものを。完成させたかった。
• 参加時にもう少し予習しておきたかった
• リファクタリングをする余裕がなかった
• 予想以上に尻が痛かったこと(注意はちゃんと聞くべき)
• 組み込み機器開発へ、どのように導入するかが見えていない
• 業務でテストコードを書く習慣がない
• 体力を消耗する
• スクリーン上の証明。本当は消せると見やすい。
• Rubyユーザが少なかった
• もう少しほかの言語も見たかった
• まだテストファーストではなく実装を考えている
• 仕様を詰める前に着手してしまった
• 自分自身がテストの認知が甘いところもある気がするので、まずは書いて実践したい
• 仕様→テストケースの変換が弱い。精進あるのみ。
• コーディングに熱中しすぎて、パートナーの意見を聞き流すことがあった
• 問題間違えた
• Todoをシンプルに整理
• タイムボックスの切れ目が弱い
• 最初のテーブルの時アイスブレイクがあったが、その後大きく移動したので、ペアにはならなかった
• グループわけ時は言語に加えてエディタの宗派を参考にすると良いかも
• TDDのフレームワークを複数知れたことはありがたい。ただ、どれを使えばよいのか悩ましい。
• 新しいこと(Groovy/IntelliJ)にチャレンジして、うまくテストサイクルをまわせなかった
• 油断するとテストよりアプリコードを先に書いていた。TDDしみついていない。
• テストの粒度が大きい。手が止まってしまう時があった。
• プログラミングを忘れていた
• 全体的に知識が足りない

Try

• 楽天カフェテリアで勉強会+2
• 紹介された書籍購入
• 環境(セットアップ手順、必要なもの)をあらかじめ知らせてもらえるとスムースだったと思う
• 寝る
• ペアプロ相手のチェンジ
• TDDBCのペアプロで途中になっている課題を全部終わらせてみる。TDDやりながら。
• 組み込み機器開発でPCUnit等を使用し実機上で動かせないか検討する
• Objective-Cでやってみる
• Groovy
• Groovyシェルとコンソールを活用する
• テストコードだけでもGroovy(Spock)で書いてみる
• 組み込みの現場でも回してみたい
• Webテストの実装にチャレンジ
• もうちょっと設計してからコード書き始めた方がいいかも。TDDというとつい、設計せずに書き始めてしまう。
• テストもっと書く。粒度も細かくしてみる。
• まずは独自でTDDし実績をあげる
• TDD実践
• TDDの実践
• これからの仕事でTDDを取り入れる
• 不安をテストでスッキリさせる!!
• 次に自分が書くコードではTDDしてやってみる
• TDDで開発をする!
• 実際の開発現場でテストコードを書くこと
• ペアプロを業務でも実践してみようと思った
• テストツールのことをもっと勉強する
• とりあえずCIまわしたい
• 小規模なところからCppUnitを導入する
• パラメタライズテストがかけなかったのでかけるようになる
• テスト後にDBロールバックする仕組み作る
• 授業の中でペアプロ、TDDを取り入れる
• ペアプロの実践
• VCSを交えてペアプロとか
• チーム内にTDDを広める
• 社内でのワークショップ
• ほかの人をTDDに巻き込む
• 業務に導入すること
• 社内にTDDができる空気を!