第一回チキチキ 日本ペアプログラミングの会java-ja支部会（仮）に参加しました

TDDだ!ペアプロだ!!と言うのにノート持っていかないし，java-jaだと言うのに飲み会参加しませんでした．でも後悔はしてない．

続きはあとで書くかも書いてる

id:t-wadaさんのデブサミ講演再演

• デブサミに出てなかったので再演があって良かった
• t-wadaさんの環境
  • Eclipse 3.4M4*1
    • Subversive
    • Quick-JUnit
  • JUnit4.4
    • JUnit4.4は色んな意味で熱いらしい．
• TDDルーチン
  • テストを書く
  • Redバーを確認する
  • 実装する
  • Greenバーを確認する
  • リファクタリングをする
  • ひたすら繰り返す
• TDDの基本は「Red→Green→Refactoring」
  • 最近は「Think→Red→Green→Refactoring」
• リファクタリング基本パターン
  • Rename(改名)
  • Extract(抽出)
  • Inline(インライン化)
• リファクタリングのパターンは上記3つを組み合わせたもの
  • パターンを暗記しなくても良い
  • デザインパターンを暗記してもあまり意味がないのと一緒
• 今回のお題はFizzBuzz問題
  • privateメソッドで書いてたけど良いのかな？そこがどのクラスの責務かを考えるのはリファクタリングの範疇？
• 名前はとりあえず適当でもおk
  • あとでリファクタリングするから
  • コードでアウトラインを書く方が重要
• 仮実装はテストが正しいかを確認するために行う．テストが失敗していたらその先に進んでも意味が無い．
  • ただし仮実装など必要ないぐらい分かりきっていれば実装しても良い．
  • そこに不安があるかないかで判断をする
• レッドの状態で機能拡張が難しい場合は，1つ前のグリーンの状態に戻してリファクタリングを行う．
• テスト名は日本語でおｋ
• 帽子の話
  • 帽子により立場が違う
    • 開発者
    • 顧客
    • 品質担保
  • t-wadaさんはTDDは品質保証ではないと言っていたけれどそんなことは無いんじゃないんかなぁ．少なくともテストで書かれている部分の品質は保証されているわけで．そういう意味で品質を作りこんでいると思ってみたり．
• 1イテレーションしか終わらなかった．
• Eclipseの空気嫁は素晴らしい．見習うべき．俺自身にCtrl+1を実装しておきたい．
• Eclipseのショートカットは是非とも覚えておきたい．
• お薦め書籍

テスト駆動開発入門

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法

Working Effectively With Legacy Code

• • • 読書会あるらしい

ペアプロ

Iteration1：id:Kishiさんとペアプロ

• とりあえず計算だけと思ってガリガリ作ってみる
• そして途中で
• ペアプロは1分交代が普通らしい．5分も占領すると長すぎる．

感想

• やり始めるとあっという間に終わった
  • みんな時間が過ぎているのにも気づかないぐらい
• ペアプロって頭の中でマルチスレッドが走ってる感じが良く分かった．確かにこれを1時間もやったらへとへとになる．
  • 自分で考えなきゃいけない
  • 人の言っていることを聞かなきゃいけない
  • 整理しなきゃいけないし．
• t-wadaさんのペアプロ実演を見てみたかった．
  • 自分でやるのはなんちゃってペアプロのような気がしていて・・・

Iteration2：ともさんとペアプロ

• 前回のプログラムをそのまま引き継いでボーリングスコア計算プログラム
• とりあえずスペア、ストライクは実装する
• 10フレーム目で3回投げるパターンのテストコードを書いているところで時間切れ．おしかった．
• でも本当は途中でリファクタリング入れなきゃいけない実装であった．臭いは感じれたが修正は出来なかった．

今回の結論

飲み会に参加すべし

*1:M5が出てた