ぐらめぬ・ぜぷつぇんのはてダ(2007 to 2011)

2007年~2011年ごろまで はてなダイアリー に書いてた記事を引っ越してきました。

もくもく会@ディノ20080916 に参加してきました。

9/15の日記 今ひとつTDDとかBDDに対して懐疑的とゆーか今ひとつよく分からない。 - ぐらめぬ・ぜぷつぇんのはてダ でいちゃもんつけまくった自分。

・・・ディノに乗り込んでいってkunitさんと直に議論した方が早いのかな・・・。

今ひとつTDDとかBDDに対して懐疑的とゆーか今ひとつよく分からない。 - ぐらめぬ・ぜぷつぇんのはてダ

と書いてみたらもくもく会があるとかで早速乗り込んでいって仕舞いました。まぁちょうど適応障害の診断貰って有休消化している最中でしたし。

kunitさん自身の考えをいろいろ聞かせて頂きました。
もくもく会@ディノ20080916 終了 - kunitの日記
一通り自分が抱いていた不安や疑問に答えて頂き、解消できたと思います。すみません、わざわざ・・・。

まずそもそもTDD自体が、アジャイル開発におけるXPでの開発手法の一部分を切り出したもので、そのためどうしてもウォーターフォール型の開発プロセスの中で考えると感覚や適用範囲の匙加減で「ズレ」を感じてしまうのは仕方ない。出自を考えれば、自分が抱いていた違和感も納得が行きます。
また、外部リソースとやりとりする時点で"Unit"とは言えない→Mockなりスタブ作れ、というのがTDD推奨。となると、性能重視でDB提供のライブラリ関数を直で呼び出したり、OSのAPI(Windows32APIなりPOSIX関数なり)を直に呼んでいるようなC言語のコードは大分TDDの守備範囲から外れてしまう。これもオブジェクト指向が使える世界で育ち、しかもアジャイル開発を採り入れて「お客様を巻き込んだ上で」バリバリリファクタリングかけられてそうしたMockやらスタブを作りまくれる環境で育ったTDDの出自を考えれば、まあそもそも守備範囲じゃないよねというのも納得です。

GUIや非同期処理は、TDD推進派の中でも「これはさすがにTDDじゃ出来そうにないよね・・・」という議論になっているようです。
やはり得手不得手もあり、現在もなおその見定めは済んでおらず議論の真っ最中、のようです。

突然話が変わりますが、昨日こんなニュースを見つけました。

「本当にそれでやるんですか」。中央三井信託銀行が2008年1月にサービスを全面開始したインターネット・バンキング・サービス「中央三井ダイレクト」は、開発の企画当初から社内・グループ内で不安の声が相次いだ。システム開発の分析から設計、そして実装に至るまで、全面的にオブジェクト指向の技術や方法論で基幹系システムを構築するという前代未聞のプロジェクトだったからだ。

1800人月のネット・バンク構築 実装までオブジェクト指向で貫く | 日経 xTECH(クロステック)

「今さらオブジェクト指向で不安を感じるのか?」という人も居るようですが、これはむしろマネジメントの成功例と捉えるべきとのブクマコメントがあり、自分も同意します。
技術云々は勉強すれば良いわけです。大半の開発者は基本はプログラミングというかものづくりが好きなのでしょうから、新しい事を勉強して実地で活用する事が嫌いな人は居ないと思います。
でもやっぱり、商売で行う開発に採り入れるには「その新技術をどう採り入れればよいのか分からない」という「不安」があるわけです。
そしてみんながみんな、そこまで自分の頭で考えられる程明晰であったり思考に余裕のある人とは限らない。「仕事でやってるんだから、そこまで余計な事考えたくない。今までのやり方で上手く行くならそれでいいじゃん。」という人も居るわけです。
そういう人達に対して、ちゃんと「こういう流れで進めればあなたは余計な事考えなくて良いですよ、全体として問題ないですよ」と「プロセス」を作って提示して不安感を少しでも減らす。また万が一のバックアップとして、従来の開発手法にも戻せるようにしている。
「プロセス」という視点でちゃんと下準備を進めていたからプロジェクトも動いたしニュースにも載ったのだと思います。

まぁ実際に、オブジェクト指向の長所を生かし切ったのかどうかは知りませんが。

TDDもやはり「プロセス」にどう組み込むのか、という視点が今後も問われるような気がします。現場の開発者は全員が全員、WEB+DB PRESSを購読していたり自分から進んで新技術を勉強するような人達では無い。仕事と割り切ったベテラン連中や新人も居る。そういう人達にどうTDDの価値を実感して貰い、開発プロセスに組み込み、TDDの得手不得手を把握した上で適用範囲を匙加減できるか。
あるいは今までDEBUGプリントを目視確認したり、ログを見たり、自作のモック・スタブで手作業で確認していた「観測」と「判断」の行為を、どうやってテストコードというソフトウェアに落とし込めるかとか。

その辺りも今後、TDDが広まっていく上で問われる話だと思いました。

最後に、サンデープログラマな人達はぜひご自身のアプリでTDDを採り入れてみると良いと思います。趣味で作っているのであればリファクタリングもしやすいわけで。
実際、いちゃもんつけてる自分自身、YakiBikiという趣味で作ってるWebアプリでは一部でTDDを使っています。内部APIの部分でTDDを適用しておくと、

  • APIのIN/OUTをより洗練できる。
  • 回帰テストの自動化がやはりうれしい。
  • 暫く経ってAPIの使い方を忘れた時、「どうやって使うんだっけ」という部分をテストコードで確認できる。

という効用を実感できると思います。というか実感してます。

というわけで先日のもくもく会参加者の皆様、最初の1時間ほどお時間頂戴し、ありがとうございました。