Hatena::ブログ(Diary)

Fly me to the Juno! このページをアンテナに追加 RSSフィード

2009-02-26

テストコードを書く意味

那須のKentBeckこと咳さん曰く

テストでは品質は上がらないですよ。テストはあくまでも品質をあげるきっかけ。品質をあげるのはプログラミングです。これは大昔からそう。

http://kakutani.com/20090213.html#p03

と言う言葉がありました。確かにそうだよな、と思ったのはいいですが、はてと思うこともありました。

じゃ、僕らはなんでテストコードを書くのだろう、

と。

以下、咳語録を自分なりに解釈して深く考えてみた軌跡です。

僕らはなぜテストコードを書くのか。それはCIにテストを組み込むことでデグレーションを起きたときに早期に気づくため、という答えもあるでしょう。が、僕が風呂に入ってぼーっとしていたら別の考えに気づきました。テストコードを書こうとすることにより、テスト対象のクラスの外側から渡ってくる値、入力と、返さないといけない値、出力を意識することで、テスト対象のクラスの質を上げるきっかけを増やしているのではないか?と思ったわけです。ソフトウェアで構築されたほとんどのシステムでは、フレームワークを用いていることが多い。いかんせん、フレームワークを使うとフレームワークから渡される値や返さないといけない値について無頓着になることが多々ある。JavaDocAPIドキュメントにどうすべきか書かれている場合はまだ対応できますが、何もなかったらどうしますか?たいていの場合「気にしない」、と言う答えに辿り着くでしょう。でもそれって、フレームワークをブラックボックスとして中を見ない、という事なので、実はとっても不安なことだったりしませんか?自分の書いたコードが、フレームワークが想定している形かどうかどうやって検証するのでしょう?

フレームワークって想定されていない使われ方をすると、途端に意図したように動かなかったり、拡張できなかったりとひどい目に会うことが多くないですか?そういうことから逃れるために、テストコードを書こうとする姿勢が正しいコードを導く助けになってくれてるんじゃないのかなと思ったわけです。

2009-02-06

ソフトウェア開発の不思議

なぜよくあるソフトウェア開発ではきっちり要求を聞いて、かっちり仕様を決めて、その通りにカチカチに固めた開発をしようとするんだろう。

例えばなんですけど、僕がプラモデルをくみ上げるとき、最初から一つ一つきっちり部品を組むと必ず失敗していました。自分が不器用なことももちろんあるのだけれども、間違った部品をはめてしまって外すのに苦労した、なんて思い出ないですか?なのでそのうち最初は緩めに組んでおき、全体的に固まってきたらちゃんと組むという手順が効果的だと気づき、そうするようになりました。世の中ではこれを仮組みって呼ぶらしいです。

いや仮組みくらい、だれだってやってると思うんですよ。最初からうまく作ろうとしたってうまくいかないわけですから。

この「最初からうまく作ろうとしたってうまくいかない」という教訓はソフトウェア開発にも当てはまるって、いろんなプロセスで繰り返し語られているわけですけど、どうも一つ一つカッチカチにしようというフォースが流れている現場って世の中にたくさんあるのってなんでなんすかね。「契約」という約束を履行しなければならない、というフォースのせいでしょうか。だとしても、その契約の中に遊びがないのはなんでなんだろ。案件が取れなくなってしまうからだろうか。遊びがない分プロジェクトが失敗するリスクが高まります、なんてコンペとかで話でないんだろうか。

ユーザーも最初から作りたいものが完璧にかっちりわかってるんだったら、自分達でプログラマ雇う方が安上がりだからそうすると思うんだ。けど、完璧にかっちりわかってないからSIに発注すると思うんだよ。「システムの改善点を提案してください。」なんて言葉は、システムをより良くしたいから、と言うよりは、ほんとのところこのシステムっていいものかどうかわかんないから、なんだろね。

「最初からきっちり作りたい症候群」という病名でもつけてみようか。

2007-12-09

知財を蓄積・活用する

改めて読み直してみて思ったんですが、この文章はどっかで聞いたような話をつらつらと書いた駄文です。なので僕が再度自分の言葉にしてみると言う試みとしてこの文章を見ていただけるとありがたいなぁと思います。

先日参加してきたJSUG第7回勉強会で気になったこと。会社内で知財を蓄積し、活用することで優位に立とうっていう話はずーっと言われ続けているけれど、それがうまくいった例って聞いたことないよねっていう話を聞いて、自分なりにそれはなぜか考えてみた。

そもそも知財を「ためる」っていうことは一種のDBを作成することと同義だし、情報はより多くの情報があるところにさらに情報が集まるものなんじゃなかろうか。ある情報を読んだり見たりしたら、それについて感想を述べたり、情報を追記したりしたくなるものが人情ってもん。現代ではインターネットなんていう馬鹿でかいデータベースがある。インターネットの情報集積能力の馬鹿でかさは改めて言わなくったっていいだろう。社内に蓄積したところで、インターネットの蓄積量からすると微々たるもんだ。

社内で蓄積したところで、社内でしか必要とされていない情報くらいしか有効に活用できないんじゃないだろうか。もしインターネット上のどこかで同じ情報が公開されていたらそっちにはさらに集まっていくだろうし。集積速度を比べたらユーザーベースで勝てるんだろうか。社内の知財データベースは。

でもね、もう一つ考えないといけないことがある。知財を活用する「方法」についてだ。Googleの検索フォームは単語を入力するという意味で直感的だけれど、最近は情報量が増えすぎた上に操作されたページランクになってしまっているので、欲しい情報にすぐにたどり着けない。Googleは検索結果が10件ずつ表示されるけれど、ページが10とか、15とかになっても欲しい情報にたどり着けないこともある。そういう時はすごいイライラしないだろうか。

ページランクがよければもっと簡単に欲しい情報にたどり着けるんじゃないだろうか。と思って考えてみたらいいサービスがある。はてなスターだ。良い!って思ったタイトルに星をつけると言うシンプルな仕組みだけれど、それによって情報の重み付けができるわけ。仮に社内にはてなスターサーバーがあって、社員で共有することができれば、その会社にとって有用な情報が蓄積していくんじゃないかと思った。

サーバー立てるのはめんどくさいので、P2Pで同じネットワーク上にいる人たちがつけた星を集計・検索できるようなアプリケーションがあれば、おんなじようなことをコストかけずにできるんじゃなかろうか。もちろん、それと同等のサービスをインターネットに用意するっちゅう手もあります。はてなスターのように不特定多数で共有するものじゃなくて、特定多数でスターを共有できるっていう。

言いたいことはたぶんこれからは知財を「蓄積」することよりも「活用」する方法に重点をおいて考えたほうがいいんじゃないかなーということなんですが、どうでしょうか。