# -\*- mode: rst -\*-
ある青年団体で開催されたマネージメントに関する講演で、こんな話を聞きました。
[ `コモディティ`_ で勝負する時の三要素 ]
* 圧倒的に 価格競争力があること
* 圧倒的に 利便性・柔軟性があること
* 圧倒的に 安全・安心であること
.. _`コモディティ`: http://d.hatena.ne.jp/keyword/%A5%B3%A5%E2%A5%C7%A5%A3%A5%C6%A5%A3
django やら何やら。
オープンソースコミュニティを彩る天才たちの成果物をありがたく使わせてもらう凡人の身としては、大変心に染みる話でした。
特に、三番目には本当に重要。なので、テストには特段重きを置いています。
それ故にかどうかは分かりませんが、顧客には成果物に満足していただいてはいるものの、最近は開発途中で大幅な仕様変更が発生することが多くて、自分的には理想に描くような三要素の結果が得られていないのが実情。
よく「アイジャルだからコードがモックアップになる」とか、「アイジャルだから修正が容易」とかいう話を聞きますでしょ?
私はあんなものマスコミの喧伝ないしは嘘っ八だと思っています。
やはり、コードを起こす前に打ち合わせをよくよく行なって、顧客の実情に適合した仕様に煮詰めることは大事だし、
開発段階もある程度に突入すると、修正が難しくなってくるのはどんな環境になってもそれほど変わらない、と思っています。
django で一番キツいのは、model の変更かな? rails を離れて早一年弱。migration だけはいまだに懐しかったりします(w
さりとて、コンピュータ(死語?)に精通していない方が相手な訳ですから、漠然とした希望(or 状況把握)と実際のコードとのバランスを取るのは非常に難しい。
例えば、こんなケース。
打ち合わせの初期段階では予算が絡むので、決裁権の有るエラい方が相手。で、仕様(≒金額)がある程度煮詰まったら、テストリリースを持って現場へ移譲される。
しかし、移った方で「もうこんな古いやり方してないですよ」とか言われちゃうと、もう大変。「さぁて、どうすんだ」って感じ?
ロボット三原則じゃないですが、上記三要素を自己適用して、「こうなったら何とかするっきゃない」というのは当然なんですが、
「自分的には理想に描くような結果が得られていない」と上述したのは、テストのために実コードを書いているのか、実コードのためにテストを書いているのか、ここからのフローが自分の中で明確に確立していなかったのが、一番の悩みだった訳です。
2ch風に「ちゃんと打ち合わせしろよ、ゴルァ！ボケがぁ！」と言われても仕方ありませんが、しかし、肝心の情報が途絶してしまっている状況の場合、要求を受けるだけの側としては、こういう例外が発生する確率をゼロにすることは不可能ですし、むしろ、こうした逆境にも「えいや！」ではなく、冷静に即応できる体制をホールドしておくことも大事、と私は思うんですね。というのは、やっぱり、せっかく製作する(した)システムな訳ですから、「便利だよ」と現場に使っていただくことが、私には何よりの報酬でもあるからです。
で、ここで、本題の Rspec(長い前振りだったなぁ…)。
このような状況を改善するための良い手法は無いものかと、以前から気になっていた Rspec をググってみると、こんなサイトを見つけました。
`Rubyist Magazine – スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)
チュートリアルを一通り終えた感想としては、Ruby ならではの構文を駆使して自然言語風に spec を記述していく様は「素晴しい！」の一言でしたね。
要は、従前のテストと同じプロセスを辿っていることに変わりは無いのですが、自分が書いた unittest と比較してみても、その明瞭性は一目瞭然でした。「なるほど。これが振舞なのか」と。
しかし、冷静になって考えてみると、かなり Ruby ベッタリの記述になっている訳で、これを python で実現するのは難しいだろうなぁ、と諦め気分でググってみると、やはり同種のパッケージは存在しない様子。
さりとて、WebObjects(java) ⇒ RubyOnRails(ruby) ⇒ Django(python) と流れてきた身には、イヤになってグッバイした rails に出戻りするのは随分と抵抗感がありました。なので、ここ数週間「django なのかぁ。rails なのかぁ」と思い悩んでいた次第。
挙げ句の果てには rails に舞い戻る言い訳作りとばかりに django の粗探しを始めてしまったのですが(苦笑、比較すればするほど、このフレームワークの良さ(python 特有の記述の冗長性とデータベースのマイグレーションが無いことを除けば)を思い知らされるばかり。
そんな折、色々読み漁る過程で、
`クは駆動のク “D is for Driven” ~Developer TestingとBDD~
を拝読しました。いくつか重要な記述を引用すると…
* プログラミング言語の構造に偏りすぎ
* サピア=ウォーフ仮説(Sapir–Whorf hypothesis)
言語は我々の思考を形成し、思考できる内容を決定する。(ベンジャミン・ウォーフ)
* マインドセットを変える
* そのまんま書ける喜び
つまり、BDD が偉大な点は、
* Behavior ≒ 振舞 ⇔ テストする対象を明確に定義した ⇔ 仕様 ⇔ コードの使用者に最も近い位置
ではないだろうか? ということに、はたと気がつきました(この間の思考プロセスは相当端折ってますがw)。
xUnit 関連の解説にも「どこまでをテストするのかについての意見は様々です」といった記述をよく目にしますが、
考えてみれば、BDD的な結論は当然の帰結なのかも知れません。で、
* コードの使用者に最も近い位置 ⇒ 自然言語風の記述 ⇒ Ruby の機能をフル活用
という流れで Rspec が誕生したことは容易に想像できますが、ここでさらにはたと気がつきました。
そのまんま書ける喜び?
ははぁ〜。あるじゃん。ウチら(pythonists)にも。
そのまんま書ける喜び。つーか、そのまんま書けちゃう。そう。doctest。
で、ググってみると、あったあった、ありました。
おんなじコトを考えてるヒトってやっぱり居るのね。
`Behavior Driven Programming
`unittest を使ったケース`_ もありましたが、関数名が読みにくくなってしまう(nose を使えば改善するかな?)点を鑑みると、やはり可読性では「そのまんま書ける doctest」の方に軍配が上がりそうです。
.. _`unittest を使ったケース`: http://blog.wyattbaldwin.com/2007/4/25/fun-with-python-bdd
テストファーストを常日頃心掛けてはいるものの、まだまだ半人前なもので、テストコードを実際に書く際には「どこまでを単位とするのか」というところで固まってしまうこともしばしばでしたが、対象がハッキリと見えてきたところで随分と心が楽になりました。
* 開発者の感情が開発を駆動する (by クは駆動のク)
なるほど、そういうことなんですね。
