日々常々

ふつうのプログラマがあたりまえにしたいこと。

XP祭り関西2012で話したこと

2012/4/7に行われた XP祭り関西 の記録です。

      • -

去年 XP祭り関西2011 に参加し、1年と少し経った今。まさか自分が話すことになるとは思っても居ませんでした。話を聞いた時は本気で冗談だと思ってましたし。

やったこと

質問とテーブルごとの会話、それに対する答えを頂き、私の答えも言ってみる……みたいな感じでやりました。
「祭りはワイワイガヤガヤしたものだ」と言う思いと、一方的に話すよりは意見交換を好む私の趣味でこういう形になりました。*1
今回のXP祭り技術がテーマです。技術は問題解決のための道具です。道具を適切に扱うには、それにどのような特性があり、自分がどの程度扱えるかを知る事が重要だと思っています。

"テスト駆動開発"

聞いてみれば大半がセッションタイトルの「TDD」に釣られたらしく。釣りタイトルはこれだから困ります。でもよく考えれば他の目的ってありませんよね。irofって誰やねんですし。

参考:Test Driven Development

  • Think about what you want to do.
  • Think about how to test it.

TDDの目標

TDDの目標は何か。TDDの目標は 動作するきれいなコード です。そこで「きれいなコードとは何か」と聞いてみました。

「重複の無い」「誰が見ても意味が分かる」「リファクタリング済みである」「テストしやすい」などが出ました。

その通りだと思います。それらもふまえて、私にとってのきれいなコードは「驚きの無いコード」です。悪い意味での驚きの無いコードです。もの凄く巧妙で、やたら短い…はきれいなコードではないです*2
そのコードを読んで、あるべくしてそうなっていると思えるようなコード。それがきれいなコード。当然のように重複も無く、読みやすいもののはずです。コードは読み物で、書かれたその瞬間から読み続けられるので、妙な刺激無くすんなり読めるものが良いんじゃないかと思っています。

目標達成のために

コードのきれいさがもたらす価値は、動作することが前提です。動かないきれいなコードには何の価値もありません。
動かないきれいなコードをきれいなまま動くようにする事は不可能に近く、どうしても動くようにする過程で、どんどん汚くなっていきます。
ならば「動作するきれいなコード」の「動作する」をテストに任せ、動作する状態を保ったままきれいにするアプローチをとる。私はそれがTDDだと思ってます。

変化に耐えられるものは何か?

次にこんな質問をしました。

「テストがある」「きれいなコード」「変化を意識して設計されたもの」などが出ました。

これまできれいなコードがどーこーとか話をしておきながら、この問いに対する私の答えは、「変化し続けるものは変化に強い」です。テストがあるかどうかなんて関係無く、です。

たとえテストがあったとしても、変化させた事がないものは、実は変化に耐えられないかもしれない。全く読めません。無理に変化させれば、ボロボロと塗装が剥げていくように崩れていくことでしょう。変化させた事があるもの、変化させ続けているものこそが、変化に柔軟に対応出来るはずです。

なので、テストを書いたならば、変化させてみるべきだと思うのです。

私にとってのTDD

私にとってTDDは 思ったとおりに動くコード を書く技術です。
「コードは思ったとおりに動かず、書いたとおりに動く」というのは、よく耳にする格言でしょう。これに真っ向から挑む技術がTDDだと思っています。実践することで、自分が「こう動きます」と言え、それを違える事はない、はず。
言った事が正しければ、それは信頼につながります。自分が信頼されるために、自分の思ったとおりに書いたコードを動かす。これができれば、後は自分の思いと相手の思いの擦り合わせです。それが一番難しいので、ここに注力出来る事に価値があります。

TDDサイクルを加速する技術たち

ここまできてやっと本題。残り時間は5分。

  • 止めてしまう問題
    • 昔のテストが通らない
    • 変更に対応出来ない
    • 何をしてよいのか判らない
  • 遅くしてしまう問題
    • 技術的負債
    • テストの意味が判りづらい

これらの問題に対する技術やツールをざっと紹介しました。
技術は技法と技能であり、技法は伝えられるし、技能は習得出来ます。ですが、どんな技術も解決したい問題が無ければ役に立ちません。
解決すべき問題が何で、それにどういうツールがあるか知っておくと、問題をスムーズに解消出来るかもしれません。
ツールは解決策の模範解答の一つです。集積された知識です。巨人の肩です。自分の抱える問題には合わない時も当然ありますが、考慮する価値はあるはずです。

*1:一時間半延々話しても良かったのですけど、それだと寝させる自信があったと言うのもあります……orz

*2:仕事としてのコードをコンテキストとしています。ショートコーディング等を卑下するつもりは毛頭ありません。