TDDBC横浜/KPT
Keep
- TDD未経験だけどTAやった
- 細かくテストする
- ペアプロ・レビュー時間がたっぷりあった
- TDDを活用して開発するぞ!TDDならソースの変更しやすいですね
- GroovyとSporkの宣伝ができた
- ペアプログミングとコードレビューの時間がたっぷりあり、よかったです
- 普段やらない人・環境でのペアプログラミング
- 新しいことへの挑戦
- バージョン管理
- Jenkins
- Functional Test
- 問題なし ペアプロができて楽しかった
- 継続して行うようにし 習慣づける
- 常にテストコードを書いてからプロダクションコードを書く
- ビバペアプロ!
- 初TDDの人が多く参加できてよかった
- 課題のレビューがちょうどよかった
- テストのリズムと休けいのタイミングがうまくとれた。
- リファクタリングを適切にまぜて改善できた
- リファクタリングを習慣に
- 座学で学んだことがすぐに試せる形式というのがよかった。
- 変数の名前を分かりやすく変更する
- vimの操作覚えれた。
- RedBull?++
- 違う言語の人達が同じ内容を書くのを比較できるのが面白い。
- それぞれの言語を知れて良かったです
- おやつ差し入れ
- ペアプロでのデザイン Discussion coding
- Refactoring で見やすいコード
- テストを書いてからコードを書く!
- これからもTDDを!
- テストのないコードは書かないようにする!
- 分散型SCM+テスティングフレームワーク+CIを開発環境のデフォルトとする
- いろんな言語でのTDDを見ることができた
- いろいろな言語のテスティング環境をレビューで見ることができた。
- Red*Green*RefactoringのRefactoringの時間をきちんと取った。
- コードレビュー
- おやつ++
- groovyペアがつくれた!!
- テストを書く
- Groovyがかっこよくてツライ
- スケジュールを再設定できた
- 弁当うまい
- 勉強会への参加
- かわいい女子の参加
- 横浜以外からも参加してくれた
- 今何が問題なのかを話し合いながら協力してペアプロできた。
- 色々な言語の実際のコードをみることができた。
- テスト駆動について少し身に付いたカナ...
Problem
- ネット
- 問題を適切な大きさに切り分ける
- 環境の違いに慣れるのに時間がかかった。vim,tmmy,SKK
- NWが切れまくりで、調べ物が並列で出来なかった。
- にわかruby使い 文法につまづいた。
- ソースのリファクタリングに力を入れすぎたかも。力の入れる場所も考える。
- 本を読むことが少ない
- プロジェクターの接続の事前チェック忘れ
- TAとしてどこまで口をはさんでいいのか線引きがむずかしい
- ネットワーク
- ペアになった人に頼りすぎた
- 一気にコミットしない 修正は少しずつ
- Eclipseのショートカットをあまり知らなかった
- 皆さんの話の半分くらい理解できなかった...勉強不足です。
- もっと視野を広く持て
- 電波に見放された
- Vim苦手 クラス名変更できなかった
- テスト自動化ができていない
- ネットワークの接続が弱かったので、調べたいとき、少し大変だった。
- ネットワークがつながらない
- コードレビューの進め方がスムーズにいかなかった。
- ペア交換できなかった。
- 環境準備が不十分で、パートナーにも使いづらい思いをさせてしまった
- パートナーとレベル差がありすぎて、相手に家庭教師をさせてしまった
- サイクルを回す! レッド→グリーン→リファクタリング
- すごい人とのペアプロに日和った。
- JUnitの機能を(ショートカット、メソッドを含む)知らなかった
- レビューの観点がTDDと関係ない点について話されているのが多いように感じました
- 仕事で使う機会がない
- ペアの交代を経験したかった
- WiMAXルータを忘れた
- キーボードの取り合いが少ない(ドライバーが長い)
- 課題のレベル向上
- どうしてもイテレーションが大きくなってしまいがち。
- プロダクトコードから直したくなる。
- インターネット問題
- OSX Lion問題
- 他の人への配慮があまりできなかった
- 休憩とらないときつい。
- JavaDocきつい。
- 時間に追われて最後焦ってしまった(^^;)
- (感覚的に)もう少しペアプロの時間が欲しかった(よいところで終わる)
- ふせん
- コーディング規約レベルでもいいので、少しずつコードを良くするテストを書いていきたい
- 役割分担重要
- 領収書の準備
Try
- 少しずつでもテストをプロジェクトに取り入れていきたい
- 実践でもTDDを実施
- 業務にテストを導入していきたい
- リベンジ
- 継続
- TDDを自動化できる環境を作る
- ネット環境に問題のないところを会場に選ぶ
- 課題は帰ってからよく考えてみる
- Haskell,JavaScriptでTDDで書けるように
- ネットがなくても調べられる書籍を何かしらもってくる
- 実装の速度が遅かったので、スピードを上げたい。
- ツールとくにQuickJunitの使い方を極めたい
- クラス名、メソッド名の変更するリファクタリング
- テスト自動化
- ユーザアクション(フォーム送信)に対するTDDに挑戦したい。どうやるのかなって。
- コードレビューに参加
- ペア替えする。
- コードレビューも見本がほしい。
- ハッシュタグ表示スクリーンあると楽しい
- Gitを使う!
- JOJO第7部を読む
- 適切なテストコードの書き方を身につける。
- Javaで覚えたTDDのリズムをPHPでも活かす
- テストの入れ子構造
- ペアプロする
- 仕事でも取り入れるようにしたい
- 写経してみたい
- もっとペアをいれかえて50%:50%でお互いCodeをdriveする。
- RubyでTDDBCに参加する
- APIレベルでの習熟度を高めて、範囲を広げる
- 自分たちが使うツールをTDDで開発する
- CI的にテストを回す(保存時とか)
- ペアプロをしたいが相手がいないので、とりあえず一人ペアプロ(エアプロ)
- SCMとの連携
- 本を読むようにしたい
- テストコードのメンテナンス/三角測量/小さく分解 意識したい
- デモで 仮実装/三角測量/明白な実装 の説明を入れましょう
- テストサイクルを短くする テストの内容を煮詰める(より詳細に)
- 進行役とそれ以外を分ける
Keyword(s):
References: