前回までで、講義でお話しようと思っていたトピックは一区切り付きました。

今回からは、今日お集まりいただいてる方と、フリースタイルの質疑応答のような形でこの場で議論していきたいと思っています。

実際にまず、連載第6回でお見せした『テスト駆動開発入門』（⁠Kent Beck 著／テクノロジックアート 訳／長瀬 嘉秀 監訳／ピアソン・エデュケーション 刊）を写経しました。写経した結果、テスト駆動開発がちょっとわかったと思いました。

私自身はもともとテスト駆動開発する前まではあんまりテストを書かないタイプのプログラマだったのですが、if文の条件分岐とか、ループのところの情けないバグが、もともとすごい多かった。それが私自身のやる気とか生産能力を削いでいったところが多かったんです。それらに対する不安みたいなものが、前に進むのを妨げていた点があったんですね。

それに対してテスト駆動開発自体は、実際に自分の苦手なところは厚くテストするし、これからやりたいなと思うところ自体を、テストの形で書いていく。

最初に書きたいものをテストの形で書いてみると、自分のつけるメソッド名が最初に考えた時点ではいかにイケていなかったとか、最初のやつはちょっといびつな設計だったとかっていうのがわかってくるようになります。それが、「⁠テストから得られるフィードバック」です。

テストから得られるフィードバックをもとに、ではこう実装しよう、処理の流れ場こういう流れのほうがいいのではないかなとか、情報の伝え方はこういったものがいいのではないかなという、自分がコードを書くという視点だけではなくて、コードの利用者としての、自分が最初にそのコードを使う人だという視点を持つことができる。

自分が最初のユーザで、自分がそのコードがいいかどうかも判断しつつ、より良く変えていくことができるんだなというのがわかったとき。これTDDってなかなかイケるのではないかなと思ったんですね。

ですので、TDDは、自分のプログラミング能力の底上げになるなと思いました。テストが教えてくれることをもとに、自分がもうちょっとかっこいいプログラムが書けるのではないかなと。しょうもないミスが段々減っていくのではないのかなと、考えたんです。

短い名前がいいのかもしれませんし、長い名前がいいのかもしれません。正解はありません。でも、ああ、この名前はもっと意味を表してるな、意味ありげなメソッド名だとか、自己満足な世界ではあるんですけども、だんだん自分で思えるようになるんです。基本的に、不安と自己満足とのサイクルでプログラムは開発されていくと私は考えています。

最初ここはちょっと不安だなと思ったところも、テストを書きながらコードを書くことで「うんうん、なかなかよくできたじゃないか」と。次に、「⁠こうするともっとかっこいのではないか」と、メソッド名をよりわかりやすくリファクタリングする。たとえばそういった流れでよく作業していますね。なんというか、もうちょっとできるプログラマになった感じが得られる。よく言われる「俺ってばスゲー感」というやつでしょうか。

俺ってすごいんじゃないか、なんかすごくなった感じが段々に得られるようになってきたという体験が、テスト駆動開発がなかなか良いものだと思った、私自身の原体験です。なんかすごい恥ずかしいこと喋ってますね（笑⁠）⁠。