読者です 読者をやめる 読者になる 読者になる

冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

TDDBC岡山開催に向けた自主練習所感

5月のオープンラボ開催宣言以来、久々に真面目にソースを書く生活を続けていて、いろいろと気づくことがあったので所感とともに恥ずかしいソースをさらしてみます。
なにぶん、まともにソースを書いたのが約3年ぶりということでこれだけのものを書くのにだいぶ手間がかかってます。
(ソースを書くのがメインの仕事から少し離れているので…)
やっぱりちゃんと自分の仕事道具は手入れしないとだめですね。良い反省材料になりました。

TDDBCについて

詳しくは公式wikiをご覧いただきたいのですが、一言で言うと「テスト駆動開発(Test Driven Development=TDD)を丸一日くらい時間をかけて身体で覚えていこう、という趣旨で全国で開催されているイベントです。

自主練について

開催宣言をしたものの、以下の理由からイベントの準備の他に私自身の準備も必要だという考えにいたり、自主練を敢行することにしました。

  • そもそもコーディング能力が怪しい
  • 宣言した本人がTDDに慣れていない

じゃあ、なんで開催宣言したんだという突っ込みどころが満載な理由なのですが、そこはまあ勢いということで。

自主練に使った教材

札幌で開催されたPreTDDBCの資料が公開されていたので、それを参考にさせていただきました。

所感

週末に2〜3時間の練習時間を取るペースで1ヶ月近く練習してきましたが、この短い期間でもいくつか気づいたことがあります。

テストフレームワークに対する考え方の変化

JUnitがはやり始めた頃、私はまだコードを積極的に書く立場にいたので、導入を検討しては何か使いづらさを感じてやめる、ということを何度か繰り返しました。
それが、TDD自主練をしている間は、過去に感じたJUnitの使いづらさを感じなかったのです。そこでふと感じたことは、「JUnitが使いづらいのではなくて、今までの自分がやってきたクラスやメソッドの設計が悪かったのではないか?」ということです。つまり、自分の設計やコードがテストしづらいものになっていたのではないか、ということですね。
TDDでテストを先に書いて、それを通す最小のコードを実装するということを繰り返していく中で、クラスやメソッドは自然とテストしやすい形に落ち着いてきました。
今までのやり方とTDDを比較してみます。

before 機能のコードを全部書いてから、まとめて一気にテストのコードを書く。
after 一つのテストケースのコードを書いてから機能のコードを書く。少しずつテストと機能が成長していく。

まるっきり違いますね。
後者の少しずつテストと機能が成長していくというのは、機能を複雑にしすぎない為に非常に重要なことだと思いました。常にコードを自分が制御できる状態でおいておくということですね。
こういうやり方でコーディングを行う上で、JUnitはむしろ非常に使いやすいツールでした。
ツールはそれぞれ想定された使い方に沿って初めて使いやすさを享受できるというのは頭ではわかっていたんですが、改めてそれを思い知らされました。
教訓:ツールを導入するときは自身のやり方も見直しましょう

コードを書き換えることへの感覚の変化

次に、コードを書き換えることに対して、抵抗感も恐怖感もなくなりました。
TDDだと、最小の機能でテストを通した後にリファクタリングをしてコードを積極的に書き換えていくんですが、今までの機能の保証がテストコードですぐにできるという安心感が非常に大きいんですね。レグレッションテストの影響度の範囲にぞっとしない、というのは精神衛生上非常に良いものです。
ちなみに私は、仕事を始めた頃に先輩から「動いているものは(なるべく)触るな」と教わりました。そのため、その頃は自分のソースですら一度書いて動き始めたもののリファクタリングは実施しませんでした。
テストフレームワークも普及しておらず、あったとしても自分が使っている環境にはまだなかったので、そういう中でコードの品質を保つには仕方がなかったことかもしれません。
でも、リファクタリングできないソースって、後々気持ち悪くなるんですよね。不健康で不衛生です。
TDDの自主練を始めて、コードに対する健康と衛生観念が真っ当になってきたような気がします。

テストコードへの考え方の変化

これは一番大きな変化かもしれません。
テストコードを書かないと怖い、と感じるようになってきました。
これは、単純に自分の作業のパターンが変わってきただけかもしれません。

結局

実際のところは、自分で手を動かしてみないとこの辺りの感覚は身に付いていかないと思います。
少しでもTDDに興味を持たれた方は、ぜひ実践してみてください。
そして、TDDBC岡山開催の際にはご参加ください。職場に持ち帰って広めてください。
一人でやるのも良いですが、TDDはチームで取り組んだ方が断然いいと思います!(私はまだぼっちです)

TDDBC岡山について

岡山のIT系コミュニティ横断的にご協力をいただけることになり、現在鋭意企画中です。
詳細、開催時期が決まりましたら発信させていただきますので、よろしくお願いします。

で、ソースは?

はい、忘れておりません。
https://github.com/Shinsuke-Abe/TDD-Practice
突っ込みはご自由に。だいぶなまっていることは自覚しておりますので…。