日々常々

ふつうのプログラマがあたりまえにしたいこと。

TDDBC 福岡 2日目 午後のメモ

TDDとペアプロで"MotsunabeZombieProject"と戦うお話です*1。お題がKanonで提供されるなど、TiDD成分も交えた感じでよかったです。
ITSとTDDも相性いいんですよね。どちらも「何をする」が明確になってから手をつける点で同じですし、何を達成したら良いかが先に判るのでテストが書きやすくなります。また、ITSとGitの相性の良さも感じました。特にブランチの作りやすさと切り替えの早さは異常。ローカルファイルって言うこともあるしね。

お題とやり方

会場で用意されたサーバで稼動しているKanonに接続し、チケットの形で提示されているお題をやっていく形式でした。

1.普通のつぶやきを判定
2.ハッシュタグを含むつぶやきを判定
3.リプライを含むつぶやきを判定
4.メンションを含むつぶやきを判定
5.複数の種別を含むつぶやきを判定
6.ネットワークからつぶやきを取得して判定
7.非公式 RT を含む判定
8.現在時刻の前後 30 分のつぶやきを最大 20 件判定
9.URL を含むつぶやきを判定
10.短縮 URL の展開

TDD Boot Camp のお題を C# と Git でやってみた - ぐるぐる~

これらが 1-4(1日目), 5-8, 9-10 の3回に分けて順番に出てきました。お題の確認はチケット見ればいいし、追加もタイミング見て出来るし、素晴らしいやり方だと思います。参加者はチケット見ながらペアと相談しつつTDDを実践する形になります。また、講師の方々が巡回することで、逐一アドバイスを頂ける形になっていました。

実践と感想

ペアは tan_go238(id:tan_go238,@)さん と組ませてやらせてもらいました。1日目と2日目で別端末で行ったため、お互いキー配置やタッチパッドに戸惑いながらのプログラミングとなりました。キー配置程度なら何とかなる自信はあったのですけど、Macは流石に簡単には慣れられませんでした。
最初に4つのチケットを見た感じ、実装の難易度はそれほど高くありません。けれどそれを考えちゃうと何しに来たのか判らなくなってしまうので、各チケットに対して「どうテストするか」を意識して取り組みました。序盤はチケットごとにドライバーとナビゲーターを交代。番号の大きいチケットは簡単なテストで終わらなくなってきたので、テストごと*2に交代するようになりました。特に取り決めはせずに自然とそうなった形だったと思います。チケットごとにブランチを作り、大き目のチケットは小さいテストで切り崩していく。チケットを処理する中で、内部構造に無理が出てきたら適当に変えたりしていました。
ややもすれば「明白な実装」で突っ走ってしまいそうな難易度で、頭の中で組みあがってしまった実装をどうテストするかーなんて考えちゃったりするんですけど、そこはペアプログラミングなんで相手に伝えないといけません。勝手に先走った実装なんて伝わるわけがなく、この辺は課題だなーと思いました。ケント・ベックも「テスト駆動開発入門」の第9章とかで言ってることです。

通貨を実装するにはどうしたいのか。また間違えた。定規で叩かれる前に言い換えることにしよう。通貨に対してどんなテストを行いたいのだろうか。これでとりあえずげんこつパンチは免れた。

TDDは設計技法だから、設計時にテストをしなければなりません。設計のない実装はありません。小さな機能であれば実装しつつ設計を行う事もあるかもしれませんが、それは頭の中で設計が済んでしまうから出来るだけです。テストで設計を行い、設計どおりに実装されていないことを確認し、実装を行い、テストを行って設計が満たされていることを確認し、リファクタリングを行い、テストを行って設計が崩されていないことを確認する。この手順を守ることに必要な能力は高くありませんが、地味に難易度は高いです。このハードルは、そのテストをペアに説明して納得して貰えるかを意識すれば乗り越えられる気がしました。

テスト駆動開発入門

テスト駆動開発入門

  • 作者: ケントベック,Kent Beck,長瀬嘉秀,テクノロジックアート
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2003/09
  • メディア: 単行本
  • 購入: 45人 クリック: 1,058回
  • この商品を含むブログ (161件) を見る

Gitのメモ

  • 区切りごとにとにかくコミットする
    • Redでもコミットしてしまって良い。
    • Red, Green, Refactoring それぞれでコミットする感じ。
    • DVCSだからコミットが他の人に迷惑かけないので。
    • Subversionでこれをやろうとすると開発者単位のブランチになる。
  • チケットごとにブランチ作る
    • ブランチが軽くマージも手軽なので出来る。
    • ちょっと置いといて、とかもある程度気楽に出来る。
  • git now
    • なう!
    • コマンド一発でコミットが出来るのは大きい。
    • そしてまとめられるのが良い。
    • せっかくのDVCSなんだから追跡できるように。
  • ブランチを気楽に作る
    • どうせ自分用だし。
    • 思い切った変更するときはブランチでやるのが良い。
  • 色つける
    • git config --global color.ui auto

*1:同テーマだったので1日目の一部も混じってます。

*2:テストごとよりもコミットごとと言ったほうが適切かもしれません。2日目はテストが通ったタイミングでgit-nowするようになって、それが良い区切りになった感じです。