TDD.NET

前回、 FizzBuzz は、4つの小さな仕様に分割できることを述べました。

繰り返すと、 FizzBuzz は正の整数すべてを受け付け、 それらを 4つに分類して、 それぞれに対して処理をします。 分類するところまでは分割できませんが、 分類できてしまえば、 そのあとは 4つ別々に処理することが可能でした。 小さな 4つの独立した仕様に分解できて、 それぞれを個別に考えればよかったのでした。

FizzBuzz では、 4つのそれぞれの処理はごく短いものなので、 ここまで考える必要は無いのですが、 仮にそれぞれがけっこう大きな処理 (100行とか 1000行とか) だとしましょう。 そんな長い処理を 4つも、 ひとつのメソッドに詰め込んだのでは、 まずまちがいなくとても理解しづらいコードになってしまいますから、 4つの処理をそれぞれ別のメソッドとして切り出すことでしょう。

さらに脱線します。

TDD しない前提で、 つまり、 しっかり考えてから一気にコードを書くとして、 FizzBuzz を見てみます。 まぁ、 メソッドの内部設計を、 TDD の力を借りずにやってみよう、 というわけ。

FizzBuzz の仕様はこうでした。

• 3の倍数なら、 "Fizz" と言う。
• 5の倍数なら、 "Buzz" と言う。
• ただし、3の倍数 かつ 5の倍数なら、 "FizzBuzz" と言う。
• それら以外は、 その数を言う。

これをよく考えてみると、 3番目の仕様の 「ただし、」 という文によって、 1番目と 2番目の仕様には、 書かれていない制限がなされています。 たとえば 2つめの仕様は、 5の倍数だったら、 いつでもまず "Buzz" と言っちゃっていいのか…? 違いますね。 5の倍数であっても、 同時に 3の倍数でもあったなら、 "Buzz" ではなく "FizzBuzz" と言わねばなりません。

前の 2つの仕様に書かれていない文を補えば、 「ただし」 を削ることができます。

元のエントリで、 TDD 道場でのリファクタリング結果 (の予想) をネタにしました。 じつはこのメソッドのカタチは、 午前中に行われたセッションの内容に影響を受けたとも思えます。 そこで登壇者のハンドルから Andochin バージョンと呼ぶことにします。 (オリジナルは C++ で書かれていました。 ⇒ FizzBuzzと貧乏性 )
また、 元記事のコメントには、 おがたん氏から違うアプローチのコードをいただきました。 こちらは Gwp バージョンと呼びましょう。

さて。 テストファーストやリファクタリングとは直接関係無い話をしてみます。 開発者としては、 最適化ということも面白いので。

元記事では、 「機械にやさしいより、 人にやさしい方がいいよね」 といったことを書きました。 それじゃネタにしたコードはほんとに機械に優しいのか、 つまり、 実行する処理が少なくなっているのか…?
それを見るために、 出来上がったアセンブリを ildasm.exe を使って逆アセンブルしてみましょう。 MSIL を読むことができなくても、 その量からある程度の判断はできるでしょう。

…これはべつに私が言い出したことではありません。
リファクタリングを世に広めた Martin Fowler 氏の言葉です。

Martin Fowler's Bliki in Japanese - リファクタリングの境界線
( 原文: MF Bliki: RefactoringBoundary )

リファクタリングとは、理解や修正が簡単になるための変更だと私は思っている。同じ変更でも、目的が異なれば、それはリファクタリングとは言わない。

※ リファクタリングを勉強するには、 何を措いてもファウラー氏の本は読んでおきましょう。

「リファクタリング ― プログラムの体質改善テクニック」
マーチン ファウラー (著)
ピアソンエデュケーション (2000/05)
ISBN-13: 978-4894712287

わんくま勉強会#15 の中で TDD 道場 (第5回) を開催させていただきました。
キーボードを打っていただいた 3名のかた、 ありがとうございました。 あいかわらずのグデグデでしたが、 参加していただいたみなさま、 いかがでしたでしょうか。

今回はリファクタリング超入門という感じで、 FizzBuzz をお題にして VB.NET でやりました。 開始時点でのコードはこのようになっていました。 (こちらからダウンロードできます。 ⇒ 勉強会などで使った資料 )