2011-12-19
きっと方眼の理から逃れられないお前たちにも告げる！テストコードを手に入れるのだ！ #TddAdventJP
タイトルは思いつきで意味は無いです。
本来ならこのネタタイトルだけで終わらせたい…
TDD Advent Calendar jp: 2011 : ATNDの19日目のエントリーです。
前日の18日目は@megascusさんのアジャイルにTDDしようとしてペアプロして失敗した話、
翌日の20日目は@haru01さんのTesting と 私と 苦い出来事になります。
内容
諸々の事情で今年から社内SEに転職しました。
そんなこんなで元システム屋の同業者として他社の社内システム担当さんと話をする機会もありました。
その中で、Excelのマクロが出来ますと面接で言って入社したら、
システム担当にさせられた上に、
今までプログラミング経験がないのにVBAまで書くことになってしまったという、
よくありそうな経歴をお持ちの方とお会いすることとなり、
TDDをいろいろ教えてみたら喜んでもらえたよ。
という内容をgdgdっと書いてみます。
テスト？そんなもんはどうでもいい！
目の前の事を片づけるので精一杯！
って人にTDD(ぽい？)ことをオススメすることがあるときに
何か参考になればいいんですが…
社内システム担当さんの背景
地方の中小企業で社内システム担当と言っても本業の業務もしつつ
システムからインフラまでの世話をしてるような人です。
兼業社内SEさん的な仕事されています。
割り込みは当たり前で本業の繁忙期だと帳票1枚を作るだけで
複雑なものだと完成は1ヶ月後になったりということもある状況…
周囲も理解はあるのでその辺りは見越してお願いしてくれるけど、
緊急時はサビ残通り越してサビ徹になることも…
そういう状態がなんとかならないかと思ってる。
こんな前提です。
めんどくさい…もう確認駆動開発でいいや…
TDDを説明するときにテスト駆動開発という言葉を出すと途端に説明の難易度が上がることがよくあります。
このときも、テスト駆動開発という言葉と出したら
- いや、テスト仕様書とか納品の書類に沢山くっついてきてるけど、出来てきたもんてこんなもんだよ？
- まぁ仮にきちんとテストする方法があっても自分の状況じゃできないよ…
というような内容に対しての説明をしないといけなくなってしまいました。
現時点で品質の向上以前の段階の人にテストって言葉を一々説明するのは面倒臭いと思い、
「テストとは言ったけど、確認駆動開発って言ったほうがいいかな…」
などと口からでまかせをいいつつ、
「ここは後々ヤバいよな、とか、ここは難しいな、とかってところを確認しながら作っていくやり方です。」
と説明するといい具合に話を進められました。
まずは始めてもらうという意味ではハードルを下げられていいかなと思っています。
小さく、すばやく、段取りよく
当然ながら、Red、Green、Refactoringの黄金の三角形は意識してもらうのですが
TDDのリズムとか割り込み上等の職場では無理な上、緊急の場合はRedの状態で放置なんてことも起るわけで…
ということで、まずはTodoメモを作って、仕掛り、完了が把握できるようにしてもらった。
その上でペアプロぽく、実際に溜ってるモノを作業しながら説明入れながらなどと小一時間やってみたらなかなか好評でした。
TDDを意識すると、関数やプロシージャの大きさは小さくなります。
そうなると全体の見通しがよくなるので、割り込みから開放されたときに作業への復帰はすばやくなります。
その上、事前にTodoメモを作ること事前の段取りとなって作業自体の停滞が発生しにくくなります。
職場で体感してもらうと、テストコードを書くことについても、
コストが高いとは思わないで受け入れてもらえてよかったです。
で、何をどこまで確認すればいいの？
何を=テストコードが書けるすべて
どこまで=最低、関数レベルで重複が除去されてGreenな状態
と提示してみたら、
何を→コピペで使い廻してるコードはテストがいらないんじゃない？等
どこまで→コピペ云々…+Greenはともかく、急いでるときは重複あってもいいんじゃない？等
テストコードの有用性は理解してても全範囲でテストコードを書くのは面倒臭いようです…
一応、
ライブラリを整備しててコピペしてるのは修正が必要なコードだからでしょ？
→修正があるということはテストコードでの確認が必要
忙しいときの重複放置は修正が必要なときに重複全部を修正するコストや
修正の確認漏れがある場合のハマリどころを作るリスクが高くなりますよ。
→コストやリスクは早めに回収したほうがいいので重複までは除去しておきましょう。
と伝えはしましたが、楽天的にスルーしていたので…
テストコードがないところは"NoTest"
重複除去までしてないところは"NoRef"
とコメント入れて注意はするようにしてもらいました。
後日、御機嫌伺いした時に、「例のコメント入れたところが特にハマってるんですが…」と
絵に描いたような発言をいただけたので「wwwざwwwまwwwぁwww」と生温かいエールを送ったことを追記しておきます。
確認駆動開発からテスト駆動開発へ…
といきたいところなんですが…
ちゃんと残業代が貰える時間内での残業で作業ができているようです。
フォーム周りのテストとかも独学でやって頑張っているみたいで…
これで、Excel-DNAに移行して.NETやって佐賀の勉強会の戦力に…とか思ってたら、
「ひとまず会社からなんか言われてるわけじゃないんでこれでいいかなと…
あと、俺、会社以外でパソコンとかいじらないし、
本当のプログラマさんとか相手できないですよ…すいません」
…だってさ…(´・ω・｀)
職業として頑張っているという、
いい意味での職業プログラマさんはこれ以上望まれていないようです…
まあ、いろいろ思うところは多々あるのですが、
今も普通にいろいろと聞かれることもあるので、
次のステップを望んだときに応えられるように私も精進しようかと…
まとめ
- 結局TDD教えられたのかはわかんないです…
- どんな人でもプログラミングで困ってるならTDDを試す価値はあるのでは…
- テスト駆動開発の"テスト"で引く人がよくいる、確認駆動開発ってのもどうかと思ってますが、preTDD的なものが名前だけでも公式であるといいなと…"いやいやテストっていってもね"的な説明面倒臭い…
- TDDって実際に人に教えてもらったほうが理解しやすいと思う。
- TDDBCはオススメ
- TDDBCに参加できそうにないorTDD知ってそうな人がいないならtwitterの#TddAdventJpで近くの人を探して教えてくれないか交渉してみる。
- 教えてくれた人が勉強会の開催を希望してるならできる限りはサポートしようね…
- いっそのこと、"俺様にTDDを教える勉強会"を主催してみる。(普通の勉強会だと主催者は勉強できないらしいので…)
- 佐賀は3月末までに何かやるかもしれません。
- AdventCalendarをGoogleChromeで書くのはやめたほうがいい。
ということでgdgdと書いてみました。
それではみなさんよいクリスマスを！
