Test Driven Development for Embedded C でペアプロの会 第1回をやりました

Test-Driven Development for Embedded C (Pragmatic Programmers)

James W. Grenning

Pragmatic Bookshelf

発売日：2011-05-02

ブクログでレビューを見る»

本日、「Test Driven Development for Embedded C でペアプロの会 第1回」をやりました。

読書会なので普段は書籍の内容について話し合うことが多いのですが、読書会でサンプルの内容全てを理解するのは限界があると思い、スピンアウト企画としてペアプロの会を始めてみました。
ペアプロの会は演習中心です。実際に書籍のサンプルをTDDをやります。おまけにペアプログラミングをやります。

今日は第8章の「Spying on the Production Code」をやりました。詳しい内容は次回の読書会が終わってからブログで紹介したいと思います。

本日のエントリでは、どんな風に演習をしたかをご紹介します。ちょっとポンチ絵を描いてみました。

演習と振り返りという2つの工程をぐるぐる繰り返しつつ、演習の中では3名が以下の3つの役割をテストケースごとに交代しつつぐるぐる繰り返します。名づけて、ぐるぐるTDD（だっせー＞＜）

• コードを書く（＝ドライバ）
• コードを描いている様を横で見てアドバイスを出す（＝ナビゲータ）
• もう一人は本を読んで皆の疑問を解決する（＝オブザーバ？）

2つ目と3つ目の違いは客観性です。ナビゲータは、ドライバがコードを書いているのを見て、すかさずアドバイスしますが、3つ目の役割の人はナビゲータほど絡んでいかず客観的に場を見ています。で、ドライバとナビゲータの手が止まったり、つまづいていたりすると、参考資料を読んだりして二人の疑問を解決することに専念します。

客観的な視点が入ることと、横で調べている人がいることで、ペアよりスムーズに作業が進んだりするようです。ただ、適正人数は3～4人なので大勢でやるのは向いていませんし、作業ペースは落ちると思われます。皆でじっくり理解しながら進めたいときに向いているかもしれません。

P.S.

このぐるぐるTDDを最初からやろうと思っていたわけではなく、参加人数が少なすぎたので結果的にこういう形になったのですが、意外と面白い体験だったので、次回以降のペアプロの会でも取り入れたいと思います。