2009-10-29

アジャイルの心得

InfoQに出てた記事Agile's "One Essential Ingredient"で、アジャイルにおいて一番大事なのは、Humility(謙虚さ)のカルチャーだみたいなことが書かれているが、うーむと思ってしまう。

この記事ではマインドセットとかカルチャーという言葉が使われている。また、今読んでいる、Kent BeckのExtreme Programming Explainedでも、アジャイルにおけるValue(価値)とPrinciple(原理原則)っていうものを説明してから、Practice(方法論)にはいる。このValueとかも、マインドセットやカルチャーに共通したものを指してるような気がする。

日本では、価値とかマインドセットというものを突き詰めてしまうと、心とか精神とか根性とか、そういうものになっちゃいそうな気がして、それではソフトウェア開発の方法論にならないじゃないかと危惧してしまう。逆に、そういうことを全く考えない文化では、ちょっとはそういうことも考えると、丁度よくなるのかもなぁ。

スポーツにおける、強くなるための方法論と精神論のバランスの具合みたいのが、日本と西欧とでかなり違うのに似てる気がする。

2009-10-26

GMLの勉強

今度仕事で、GMLっていうのを使いそうなのでお勉強中。GMLは、簡単に言うと地図のための情報をXMLで表現するもの。

フィーチャー・ドリブンとどこかに書いてあったけどGMLでは。
『橋がある』「その幅は３m』『長さは１２m』、それから『場所はxxx, yyy』
という感じで表現される。

ということは、日本を10km四方のマス目に区切って、各マスの平均気温を記録する、というような表現には向いてないようだ。

2009-10-21

アジャイルでのテスト

今回のプロジェクトは、僕にとって初めての本格的なアジャイルでの開発です。ぼちぼちと、気がついたことを書いて自分の考えを整理できたらと思って書きます。

まず、テストのこと。

ユニットテストは、当然デベロッパーが各クラス毎に書いています。使っているのはJUnit4,DBUnit, Mock Unit, Mockitoとか。問題は、その一つ上の段階のテスト。インテグレーション・テストと呼んでいたのですが、人に依って定義がまちまち。また、誰がそのテストを開発し実行するのかも意見がまちまち。

作っているジステムは、一種のメッセージ・キューイングを使ったシステムでWEBのユーザーインターフェースはありません。そのため、SELENIUMのような画面ベースのテストツールが使えないかわりに、スクリプティングで自動化できそうでした。

チームのテスターは多少スクリプティングができるとはいえ、デベロッパー:テスター比率が7:1なので、一人でテストスクリプトを全て書くのは無理。デベロッパーだけが、次のイタレーションに移り、テスターが前のイタレーションのテストをしてるという状態を許すと、バグが発見される度にデベロッパーは前のイタレーションに引き戻され経験的にこれはしんどいです。アジャイルの中では、よくクロスフ・ファンクショナルという言葉が出てきますが、イタレーションをテストまで含めて終わらせるためにテストのスクリプトをデベロッパーとテスターが一緒に書くことにしました。

現在は、このテストをストーリー・テストと僕たちは呼んでいます。ストーリー・ブレークダウンを行う時に、そのストーリーのテストも一緒に考えます。ストーリーのカードには、どうやってストーリーがデモできるかも書いてます。第一のテストは、このデモ内容をスクリプティングしたものです。

まだまだ、チームとして試行錯誤的なとこもありますし、自分の中で納得できてないとこも結構あります。ストーリーテストは、ストーリーのサイズが適当であれば、うまくいくと思います。しかし例えば、『ユーザーはシステムにログインできる』というようなストーリーは、場合によってはとても複雑な処理を必要とします。レガシーシステムやセキュリティ認証のシステムをSOA等で接続して、初めてユーザーのログオンが可能になるようなシステムの場合、通常のストーリーのサイズ(4-5日)に収まりません。この場合、小さいストーリーに分割し、その小さいストーリー毎にテストしていくことになります。この場合、全体を通したテストは、いつ誰がどういう形でやるのが適当なんだろうとか答えがでてません。

2009-10-19

Erlangでリストの処理

Erlangで、リストをイテレートして結果をリストで返す時の、定石のやりかた。

リストの先頭と、それ以降を[H|T]でアクセスしたり、パターンマッチングで実行するファンクションを決めたり、随分、Javaとかとは雰囲気が違って頭の体操になります。

map(P, L) -> map(P, L, []).
map(P, [H|T], Result) -> map(P, T, [P(H)|Result]);
map(P, [], Result) -> Result.

2009-10-18

Erlangのガードエクスプレッション

なかなかErlangの文法に馴染めません。今日つまずいたのは、if文の中のガードにファンクションが使えないという点。case文を使ったものをif文で書き直そうとしたら駄目でした。なんかよくわからない。googleしたら、やっぱし駄目らしいことが書いてあったけど。変なの。

filt (P, [H|T]) ->
  if 
   P(H) -> [H | filt(P, T)];  <--これ駄目！
    true -> filt(P, T)
  end;
filt (P, []) -> [].

2009-10-18

またまたドメインオブジェクト

以下に、僕の理解する所のドメインオブジェクトについて記します。間違ってたり、違うと思うところがあったら指摘してください。

Wikipediaによると、ビジネス・オブジェクト(ドメインオブジェクト)とは以下のような定義だそうです。

Business objects are objects in an object-oriented computer program that represent the entities in the business domain that the program is designed to support. For example, an order entry program might have business objects to represent each orders, line items, and invoices.
Business objects are sometimes called domain objects; a domain model represents the set of domain objects and the relationships between them.

一般的に、ドメインオブジェクトとかドメインドリブンデザインというと、ビジネス、業務のエリアの設計・デザインを指します。しかし、ドメインという言葉自体は『領域』という程度の意味合いなので、ドメイン・オブジェクトが発注とか受注といった業務アプリケーションにしか存在しないというのは間違いだと思います。例えば、デバイスドライバーをオブジェクト指向的に書いたら、『割り込み』とかはデバイスドライバーというドメインにおけるドメインオブジェクトになるでしょう。

また、DSL(ドメイン・スペシフィック・ランゲージ)という言葉のドメインという言葉の使いかたは、正に、単に領域という意味で使っています。例えば、AntはビルドというドメインにおけるDSLだし、Railsはウェブアプリケーション開発というドメインでのDSLです。でもAntもRailsもビジネス・アプリケーションではありません。Antはビルドのツールだし、Railsはウェブアプリケーション開発のためのフレームワークです(その上で作ったものはビジネスアプリケーションになる場合が多いですが)、

Osawatさんからコメントされた、XXXManagerとかはドメイン・オブジェクトなんだろうか、ということについてですが、それはXXXManagerオブジェクトの持つ責任／役割によると思います。それが、開発対象のドメインに属する処理、例えば在庫の引き当てとかだったら当然ドメイン・オブジェクトになるでしょう。

ここで注意しなければならないのは、従来の多くのJ2EEのアプリケーションの設計はデーターベースドリブンだったということです。本来のOOPでいうオブジェクトは、データとそれに対する処理が一体化したものです。しかし、多くのJ2EEアプリケーションは、データーベースのレコードを保持するエンティティ・オブジェクトと、処理のロジックだけを持つオブジェクトに分かれていました。悪名高いEJB2のエンティティ・オブジェクトと、それを回避するためにデザインパターンとして、こういうのが推奨されてきたわけですが。

Domain Driven Designが言っているのは、本来のOOPのデザインをしようということだと思います。つまり、『受注オブジェクト』といったら『受注数みたいなデータ』と受注関係の『ロジック』も、受注オブジェクトに持たせようということです。また、ある一つのオブジェクトの処理として実装すると不自然になる処理、２つのオブジェクトにまたがる処理、例えば、受注数の更新と在庫の引き当ては、一連の処理として行いたい場合、この処理はどこに属するべきでしょう。多分、受注オブジェクトでもなく在庫オブジェクトでもない、XXマネージャーとかXXサービスとかに含めたほうが、自然だと思います。でも、このXXマネージャーはあくまでも、そのドメインの処理をしてるのでドメイン・オブジェクトです。

追記
佐藤匡剛さんのBLOGと
Java EE勉強会のページが大変参考になりました。

2009-10-17

Erlangの修行

今日は、またErlangの本を読み直していた。IRCLiteを一応理解したつもりなのだけど、前に進む前に、もう一回ErlangのTail-Recursiveとか、spawnとか基本的な言語の要素を復習していた。わすれちゃったから。

デバッガーを使ってみようと思ったらトラップ。ここのページによると、Erlangをソースからビルドして、wxWidgetsを入れないといけないらしいので、めげた。たしか、僕はErlangをMacPortsでインストールしたはずだし。

デバッガーとかGUIを必要とするErlangのアプリケーションは特にOSX上では、駄目駄目らしい(参照)。
かといって、Rubyのようにシェルの中で色んなことが対話的にできるわけでもない。