終電23時11分って早くね?

都内のIT企業で働くカラオケ大好きエンジニアの雑記

Agile Samurai Base Camp Re:TDD に行ってきた!

Agile Samurai Base Camp Re:TDD に行ってきました!
http://agilesamurai-basecamp.doorkeeper.jp/events/9333

前回(http://agilesamurai-basecamp.doorkeeper.jp/events/5844)はインセプションデッキトラックで参加させていただき、
「後ろでやってるTDDトラックも見たいなー」
「体が二つほしいなー」
と思っていたので待望でした 笑

印象に残ったところをさっくりまとめます。

基調講演

TDDのこころ/@t_wadaさん

TDDは下記の平鍋さんの記事でいうところの、

アジャイルの「ライトウィング」と「レフトウィング」
http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html

「レフトウィング」に含まれる。

アジャイル開発が語られるときには割と、
「ライトウィング」のほうがフォーカスされがちだという。

が、右サイドだけ強くても点が取れない。
と日本代表の内田と長友を引き合いに出したスライドは、
サッカー経験者としてはすごい納得感があった。

キャプテン翼でいえば・・・
って考えたけど、石崎と早田・・・?
だめだ、これはしっくりこない。

アジャイルサムライのP235ページにも書かれている

最後に残った4つの章では、私が「問答無用で実践すべき」だと考えているアジャイルなソフトウェアエンジリアニングのプラクティスを紹介していきたい。

と紹介される中にも、
ユニットテストリファクタリングテスト駆動開発(TDD)があげられている。

ということで、「開発環境」による支えも、
アジャイル開発の一翼を担っているのだと、
改めて意識させられた。

ペアプログラミング

FizzBuzzをお題としたペアプログラミングを、
デモとしてやっていただいた。

色々と端折られた箇所はあったようですが、
ペアプロにより
・TODOリストを作成
・RED→GREEN→リファクタリングのサイクル
・役割チェンジのタイミング
・新たなTODOの追加
の流れがすごく見ていて分かりやすく、
実践で実際やる場合の想像がついた気がします。

工数見合いの部分とか色々と社内で実施しようとすると調整が難しそうだが、
・その場で2人でコードを見ている分バグが入りにくそう
・互いの知識や書き方のナレッジ共有
・仕様を(ちゃんと)把握する人が2人になる
といったあたりはかなり有効なのかもと思いました。

質問コーナー

@t_wada さんに直接質問できるという貴重な場で、
テストコードがなくプロダクションコードだけしかない場合、どのあたりから手をつけるのがよいのか・・・?
という質問があり、

・依存の少ない部分を狙い撃ちにする
・仕様化テストで今動いている仕様をテストに落とし込む

の部分が非常に腑に落ちました。
仕様化テストについては、

レガシーコード改善ガイドでも紹介されているようなのでぜひ読んでみたい。
テストがないコードはそもそもテストが書きにくいという場合が多いが、それを泥臭くステップバイステップで解消してく・・というような流れで分かるそうなので、
0からテスト駆動始めるよ!じゃない人にはお勧めっぽいです。

アジャイルサムライの次に読む本

これは読みたい!と思ったものをメモ。

JUnit実践入門

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

JUnitの本だけど、Unitテストとは何か?的なところから書かれている。CIとかCucumberとか欲張り。JUnitはこれ1冊でOK!


リーダブルコード

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

いまさら説明不要のリファクタリングを知るための良本


レガシーコード改善ガイド

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

先ほどもあげましたが、レガシーコード(テストがないコード)からはじめるTDD本ぽい。
現場に一番必要とされている本かもしれない・・とのことだった。


ソフトウェアテスト技法ドリル

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

TDDをやっているてバグが生まれてしまう場合、
それは自分の考えが及んでいない部分になることが多い。
そういう部分を拾いより品質を上げるためのステップアップの1冊。


達人プログラマ

達人プログラマー―システム開発の職人から名匠への道

達人プログラマー―システム開発の職人から名匠への道

  • 作者: アンドリューハント,デビッドトーマス,Andrew Hunt,David Thomas,村上雅章
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/11
  • メディア: 単行本
  • 購入: 42人 クリック: 1,099回
  • この商品を含むブログ (347件) を見る
新人が入ったときに1冊目これを渡す会社も多いそう。
積まれているので早く読む。


データベース・リファクタリング

データベース・リファクタリング

データベース・リファクタリング

  • 作者: スコット W アンブラー,ピラモド・サダラージ,梅澤真史,越智典子,小黒直樹
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2008/03/26
  • メディア: 単行本
  • 購入: 10人 クリック: 211回
  • この商品を含むブログ (53件) を見る
データベースの体質改善テクニック。
データベースのよくない設計にどう対応するのか?ということが書かれているらしく大変興味がある。
が、絶滅危惧種なので見つけたら保護してください 笑

そのほかにあげられていた本も読みたいが、
特に気になったのが上記な感じ。

他の現場を知ってみよう

皆さん口をそろえておっしゃっていたのが、
自分にもチームにも根付かせていくためには、
“無理をしない”ということをあげてらっしゃった。

テストを書くことで、モチベーションが下がったり、変更が怖くなってしまったりすることの無いようにしないといけない。
プログラミングが嫌いになってしまったら本末転倒。

中でも、@PoohSunnyさんのお話しの中にあった、

× レガシーコードをTDDで改善する

のではなく、

○ レガシーコードで自分のTDD力を高めよう

というお話は、明日から実際に始めるための勇気をもらったような気がして、とてもうれしかったです!

私的まとめ

実は以前に@t_wadaさんの発表を聞く機会があって、

DevLOVE現場甲子園2013で拝見したときも「TDDやらねば・・」と思いつつも
今まで実践できていなかった自分がいたのですが、
本日改めて、「やらねば!」という気持ちとともに「なんかできそう!」という気持ちになっています。

この気持ちを切らさぬよう、頑張りたいです。



いつも自分が「キツいなー」とか「つらいなー」とか思ったときに思い出す言葉があります。

「適度に適当に。好い加減で。」by 嫁

「適当」も「好い加減」も言葉で聞くと、
すごくネガティブな表現というか雑な感じがするのですが、

「適当」
http://dictionary.goo.ne.jp/leaf/jn2/151064/m0u/%E9%81%A9%E5%BD%93/
→程度などが、ほどよいこと。また、そのさま。

「好い加減」
http://dictionary.goo.ne.jp/leaf/jn2/9323/m0u/%E5%A5%BD%E3%81%84%E5%8A%A0%E6%B8%9B/
→程よい程度。手ごろ。適当。

という風に考えるといつも「あ、そっか」と思えて気持ちが楽になります。


そんな感じで、
TDDも「適度に適当に。好い加減で。
という気持ちで1つずつ、少しずつ進めていければなと思います。