Maven2のビルド

---
昨日投稿した記事が中途半端な状態で表示されていました。
すいません。投稿しなおします
---

ようやくMaven2の実態が少しずつ見えて来ました。
まだまだ開発途上という雰囲気ですが、

http://cvs.apache.org/viewcvs.cgi/maven-components/

でソースコードが見れます。
現在ものすごい勢いで開発がすすんでいるようです。

ビルド方法はCVSから落として来たディレクトリから、

m2-bootstrap-all.bat

でビルドできます。
ただし、あらかじめホームディレクトリにmaven.propertiesというプロパティファイルを作成して、maven.homeとmaven.repo.localの二つのプロパティを設定する必要があります。
maven.homeはmaven2のインストールディレクトリ、
maven.repo.localはローカルリポジトリの位置を指定します。
mboot.jarというのはつい最近コミットされたPureJavaのmaven専用ビルドプログラムです。(その前はビルド用のプログラムはbashスクリプトでした)

使い方は現在調査中でまだ詳しいことは分かっていません。
ソースコードをざっと眺めた所、今までとは見違えるように美しいコンポーネント指向のモデルに生まれ変わっているようです。
それにしてもmaven2が依存しているライブラリは
plexusを始めとして、classworlds, xstream, qdoxなど、
CodeHaus産の物が多いですね。Jakarta産はCommons-Cliくらいなのではないでしょうか。これも時代のながれというものでしょうか。

コントラクトを普通のJavaクラスとして実装する

yoshiさんにおしえて頂いたページに紹介されていた、Contract自体は普通のJavaクラスとして記述し、Contractを呼び出す箇所のみをAspectとして記述するアプローチには大きく分けて2つのメリットがあると思います。

1.eclispeのJDTの機能をフルに活かせる
eclipseはいまやJavaの開発環境のデファクトスタンダードになっています。そのeclipseのAspectJプラグインであるAJDTでは、JDTの強力な機能である、ソースコード補完やリファクタリング機能の多くが使えません。シンタックスハイライトが聞いたエディタくらいのイメージでとらえたほうがしっくり来ます。コントラクトをPureJavaで書けるとJDTの優れた機能をそのまま使えるというメリットがあります。

2.Javaソースコードを解析する各種ツールを使用できる。
コントラクトはプログラムの仕様です。ソースコードそのままでも意味的には仕様書として通用するとは思いますが、大抵の環境では、仕様書というのはMS-WordやHTMLなどの形式で書くものだという
固定観念に囚われているのが普通です。そのような環境向けには、
ソースコードに書かれた情報をMS-WordやHTMLのような形式に変換してあげるのが良いとおもいますが、コントラクトがAspectJで書かれているとそれがうまく行きません。AspectJの構文を解析して、
その構造にアクセス出来るツールが僕の知る限りまだ存在
しないのです。
それに対してコントラクトがJavaソースコードで書かれていれば、
qdoxなどのツールを使用してコントラクトの情報を他の形式に比較的簡単に変換できそうです。

ただし、紹介されていた通りの方式でコントラクトを実装してしまうと、メソッド一つ毎に一つJavaクラスと対応するアスペクトを作成しなければならなくなります。それではあまりにも煩雑です。

そこで、JUnitがtestXXXという名前のメソッドをテストメソッドとして自動的に展開するようにpre_XXXとかpost_XXXという名前付けルールで事前条件/事後条件チェックに対応するメソッドを起動するように工夫すれば、一クラスあたり一つのコントラクト用クラスを作成すれば良くなって煩雑さが少し軽減されます。

時間をみつけてこのアイデアを実現させる方向で考えてみたいと思っています。

親父の小言

ちょっとヘビーな記事が続いて疲れたので、軽いものを一つ。
たまにこのblogにもコメントをくれる後輩のS君に僕がいつも
たれている小言集です。

だらしないコードは書くな

RuntimeExceptionは恥と思へ

設計には魂を削れ

仕様変更は覚悟しておけ

徹夜はするな

設計書を信用するな

勉強は存分にしろ

週末は良く遊べ

聞くは一時の恥聞かぬは一生の恥

思いついては実行するな

悪いコードは捨てろ

下を見ては満足するな

もうちょい沢山あると、もっと例のアレっぽくなってくるのですがねぇ。

AspectJによるDbCの注意点

AspectJを使用してDbCを実践する時には、いくつか注意しなければならない点があります。それは主にAspectJがDbCに特化したツールでなく、「何でも出来てしまう」ために起きる現象です。
チェック対象オブジェクトはコントラクトがWeavingされていようといまいと、完全に同じように動作する必要がありますが、AspectJのを間違って使うと、この原則をいとも簡単に破壊することが出来てしまうのです。以下に注意点を述べます。

1.対象オブジェクトの状態を変更しないこと
事前条件/事後条件のチェックの際に、呼び出すチェック対象オブジェクトのメソッドは、対象オブジェクトの状態を変更してはいけません。そうしないと、コントラクト自体がオブジェクトの振舞に影響を与えてしまいます。
一般にDbCを適用する際には、メソッドを「コマンド」と「クエリ」に分けて考えると良いとされています。「コマンド」はオブジェクトの状態に影響を与える何らかの処理を実行するメソッドです。
「クエリ」はオブジェクトの状態を取得するメソッドで、それ自体がオブジェクトの状態を変更することはありません。平たくいうとgetterですね。DbCでは基本的に「コマンド」に対してコントラクトを定義します。そのコントラクト内で呼び出すメソッドは「クエリ」で無ければなりません。
クラスを設計する際に最初からメソッドを「コマンド」と「クエリ」に分けて考えておくと良いでしょう。
このあたりの考え方はDesign by Contract By Exampleという本に詳しく解説されています。DbCの基本が豊富な例題を用いて分かりやすく説明されており、おすすめの一冊です。

2.チェック対象メソッドの振舞を変更しないこと
コントラクト記述の際にはaroundアドバイスを多用しますが、aroundアドバイス内では元のメソッドの振舞を好きな様に変更できてしまうので注意が必要です。具体的には

1. proceedの戻り値をきちんと返却しているか?自分で勝手な戻り値を返していないか?
2. 例外が発生した場合、そのままスローしているか?握りつぶしたり、自分で勝手な例外を投げたりしていないか?

といった点に気を付ける必要があります。

以上の様な注意点の他にもいくつかのTipsや課題が明らかになりつつあります。それらに関しても適宜紹介して行きたいと思います。

ブックレビュー：強い工場

書名：強い工場
著者：後藤 康浩
発行所：日本経済新聞社
ISBN：4-532-31052-0

日経の夕刊に掲載されていた連載記事をまとめた本で、日本の製造業をリードする企業の工場での、生産の現場でのさまざまな工夫を取り上げた本です。
伝統的なソフトウェアの開発プロセスは「工学的であること」を目標として来ました。それは特に建築との比喩で次のように語られるものです。

「日曜大工で犬小屋をつくるのであれば設計図もいらないし適当に部品をあつめていきなり作り始めてもいいだろう。失敗してもせいぜい犬が困るだけだ。しかし、高層ビルを作るとなると話は別だ。きちんと設計図を書き、計画的に作業を進めなければまともなビルを完成させることは難しい。ソフトウェアも同じだ。日曜プログラミングならいざ知らず、商用レベルのソフトウェアを作り上げるにはきちんと工程をふんで計画通り作業をすすめる必要がある。」

一見ものすごく説得力がある比喩なのですが、最近アジャイル開発手法の勉強をすすめるにつれて、いろいろと疑問が湧いてきました。まず、ソフトウェア開発はそこまで建築に似ていないだろう、ということがあります。建築よりもずっと設計にかかる比重が大きいし、仕様変更もあります。
おなじものづくりでも業種が違えば製造へのアプローチも違うはずです。

という問題意識から本屋さんで手に取ったのがこの本です。

日本の製造業の世界ではウォーターフォール型の開発プロセスが手本にしてきたような流れ作業での生産が全てでは無くなってきています。キャノン、松下電器、NECなどの日本を代表するメーカーではかわって「セル生産方式」という方式が採用されています。
セル生産方式では、1人から数人のチーム(これをセルと呼ぶ)を組んで1つの製品の全工程を担当します。流れ作業ではベルトコンベアーのスピード以上では生産出来ないのに対し、セル生産方式ではセルのメンバーが自律的に生産性工場への創意工夫を重ね、より高い生産性を実現しているとのことです。考え方的には完全にアジャイルですね。
この他にも「アジャイルな」(としか僕には思えない)方法論によって高い効果を上げたエピソードが多く紹介されていて、思わずニヤリとしてしまいます。大切なのはプロセス自体よりも、よりよいものをつくろうとする創意工夫と、そのような創意工夫の生まれやすい土壌を育てる努力なのだと、あらためて思いました。
日本のSIerの中にもそのような土壌がそだって「強いSIer」になっていかないと、アメリカはもとより中国やインドにはとても勝てないのではないかという強い危機感が僕の中にあります。いま僕がおかれてる状況をみるといろんな意味で正直厳しいかなぁ、と思ってしまいますが。。。
最後に本書のなかで気に入った部分はいくつかあるのですが、一つだけ引用したいと思います。

(p116 NEC埼玉の例)
需要が急増し始めた携帯電話端末を増産するため、ベルトコンベヤーの流れ作業にソニー製の最新鋭の組み立てロボットを導入した。一台約二千万円。ソニーがウォークマン生産のため開発したといわれるだけに三次元加工など複雑な作業に対応できる「期待通りの優秀な装置だった」。
だが、生産現場にとっては操作が複雑すぎた。生産機種変更のたびにプログラムを書き換え、設定して動かし始めるのに二ヵ月もかかった。動き始めれば効率はそれなりによかったが、止まっている期間が長く、その間は生産は落ち込んだ。
当時、携帯端末の大口の注文を受けていたが、ロボットの停止で生産は遅れ気味だった。納期が迫ってやむにやまれず、部品装填などロボットの補助業務に雇っていた女性のパート作業者七人に携帯端末を手作業で組み立ててもらった。
驚くべき現象が起きた。七人の手作業がロボットの生産台数を上回った。ロボットを使わず、ロボットの補助をしていた作業者が組み立てた方が効率が上がったのだ。

厳密なプロセスによって守られるもの

ASDに限らず、アジャイル開発方法論では、一般に細かい作業のすすめ方は開発者がお互いに相談して決めることになっています。
ここも重量級方法論の立場の人達から批判の的となるポイントです。
彼らの典型的な意見は以下のようなものになるのではないでしょうか。

「なるほど、厳密なプロセスではケース・バイ・ケースの判断が必要となる複雑な状況に対応できない、というのは分かる。
しかし、複雑な状況に対して適切な判断を下すには高いスキルが必要とされるのではないか?現実のプロジェクトではそんなに優秀な開発者ばかり集められるものではない。それに優秀な開発者ほど単価も高い。
そのような状況でも会社として案件を受注している以上、ある程度の品質を保証する必要がある。実証済の厳密なプロセスに従っていれば、状況によって多少現実とそぐわなくなる部分が出て来るかもしれないが、最低限の品質は守られる。そのことが重要だ。」

この主張に対する反論を試みてみることにします。

細かく定義された成果物とワークフローは、形式知に過ぎません。それらの意義を本当に活かすには、開発者がどうしてそのような成果物が必要なのか、成果物を作成するためにそのような手順でなければならないのかを内側から理解している必要があります。

しかしそれにはスキルが必要です。

プロセスには従っているけれど内容はボロボロな設計書など、僕はいくらでもみたことがあります。

厳密なプロセスによってスキルの低い開発者でもある程度の品質のものをつくることができるという前提が間違っているのです。

そもそも品質とはユーザに納品される価値ですが、その価値の内容自体複数の要素が絡み合って状況に応じて変わる複雑な物です。
例えばバグ。もちろんバグは品質に関する重要な指標で、少ないに越したことはありませんが、開発のスピードや機能の豊富さ、価格もまた品質を構成する重要な要素です。
これらの品質を構成する要素の間にはトレードオフがあって、開発のスピードを上げようとすれば、バグは増えるし、機能も削らなくてはなりません。
そして開発のスピード、バグ、機能、価格の間の最適なバランスは作ろうとしているソフトウェアによって異なります。
例えば、原発の制御系のシステムであれば少しくらい納期が遅れてもバグが一つもないものが望ましいでしょうが、次期Windowsのリリースが2010年で価格が1CPUあたり50万円だったら嬉しいでしょうか?

実際には厳密なプロセスはマネージャが自分で責任をとらないための言い訳として機能していると思われます。
マネージャは自分で重要な判断を下したり、開発者に委ねるかわりにプロセスに従うことで次のような言い訳ができるようになります。

「確かに今回のプロジェクトはうまく行きませんでした。でも私は標準化されたプロセスに従っていました。だから私は悪くありません...」

結局のところ、厳密なプロセスが守るのは品質ではなくマネージャの心の平和なのです。

実際にアジャイル開発手法導入を説得する際にこれをいってしまうと感情的反発をくらってうまく行かないような気がするのが悩みどころです。

ASDの世界観

昨日の続きで、ASDの視点(=ジム・ハイスミスの視点)からみたソフトウェア開発の世界観について僕なりの解釈で紹介したいと思います。

かつて、ソフトウェア開発は極めて大規模かつ長期にわたっておこなわれていました。開発手法は今となっては伝統芸能の趣すらあるウォーターフォール型で、この官僚主義的なアプローチを記念事業的ソフトウェア開発と呼びます。

このやり方は当初それなりの効果をあげましたが、その時代は長く続きませんでした。強力なPC、C++やVisualBasicなどの新しい開発環境が登場し、コンピュータで出来ることの幅がひろがると、短期的なニーズに基づき、設計を重視せずいきなりコーディングを始める手法が広まっていきました。
これを場当たり的ソフトウェア開発と呼びます。重厚長大な記念事業的ソフトウェア開発ではツールの変化やビジネスの要求の変化に対応しきれなかったのです。
もちろん場当たり的なソフトウェア開発にも欠点はあって、保守性やコードの汎用性は犠牲にされていきました。
こうしてソフトウェアは官僚主義と場当たりの両極に分解していき、その状況は現在まで変わっていません。

ASDは両極のどちらでもなく、その中間の妥協案でもない第3の選択肢をとっています。それが複雑適応系理論に基づいた「創発的秩序」によるソフトウェア開発です。

現在の記念事業的的開発の創本山はSEIのCMMです。CMMにおいては反復可能、認識可能、測定可能なプロセスを最適化していくことがよしとされています。
これは製造業に例えると、ベルトコンベアで作業する作業員の歩数などをストップウォッチではかりながら効率をあげて行く作業などが想起されます。しかし、このやり方は、刻々とベルトコンベアのフローが変化して行くような状況では当然なりたちません。

ASDは現状のソフトウェア開発の多くがこのように変化の激しい複雑な環境におかれているということを前提にしています。
複雑な環境では、最適化という作戦はうまく働きません。

例えば将棋。

「将棋で勝つ手順」をCMM的最適化の手法で編み出すことは難しいでしょう。「初心者でも必ず勝てる将棋の手順」を定義するにはあまりにも考慮すべきパターンが多すぎるのです。ソフトウェア開発
が置かれている状況も同じくらい複雑だと思うのですが、「スキルのないエンジニアでも良いソフトウェアが創れる開発プロセス」を定義できると本当に信じている人が結構いるのは驚きです。

まぁ、本当にそんな開発プロセスがあるとしても適用分野はあらかじめ必要な技術もビジネスの要求もはっきり分かっていて要求の変化も少ないような案件にしか適用できない限定的なものとなるでしょう。銀の弾丸は存在しないのです。

では、そのような複雑さに人はどのように立ち向かっていったらいいのでしょう？

将棋は単純に手順化するには複雑すぎますが、そこには一定の秩序があります。一つ一つの駒の動ける範囲はきまっていますし、勝ちにつながる定石もあります。

ソフトウェア開発も同様に複雑なものではありますが、決してカオスではなく、将棋と同様そこには一定のパターンがあります。

ASDでは、このような複雑な状況のなかで、最適では無いけれどもベターな解を見付けようとします。この「ベターな解を見付ける」ということを「適応」と言っており、解を導くのにかかる時間の短さのために「最適」より「適応」の方が優れていると主張しています。

これはASDというよりすべてのアジャイル開発手法がベースにしている考え方のような気がします。

長くなってしまってので、続きはまた次回に回します。

ブックレビュー：適応型ソフトウェア開発

書名：適応型ソフトウェア開発 変化とスピードに挑むプロジェクトマネジメント
著者：ジム・ハイスミス
訳者：山岸耕二/中山幹之/原 幹/越智典子
発行所：翔泳社
ISBN：ISBN4-7981-0219-9

アジャイル開発手法「ASD」に関する本なのですが、
ここ半年で読んだ中で、もっとも刺激的な本でした。
最初手に取った時は数あるアジャイル開発手法関連の本のうちの
一つくらいにしか考えていなかったのですが、読んでみると他のものとはかなり趣が異なることが分かりました。

アジャイル開発手法に共通する特徴として、ソフトウェアを構築するためのワークフローの詳細はあえて定義せずに、開発チームに決めさせるということがあります。ここがアジャイル開発で一番批判されやすいポイントです。定義していないということが単なる「いい加減さ」と解釈されやすいのです。
本書では、どうして詳細なワークフローを定義すべきでないのかも含めて、ASDの基本的な考え方を複雑適応系理論をベースに、ソフトウェア開発を筆者の趣味である登山に例えたりしながら、丁寧に説いています。非常に説得力のある議論で、これに正面から反論するのは難しいのではないかと思います。
実際はXPやスクラムなどアジャイル開発方法論の多くはASDと同様に複雑適応系理論にその基礎を置いていますが、それらの解説書は開発手法の実践に重きをおいており、そこまで理論的な基礎をしっかりと解説はしていません。本書をよむと、その述べられていない基礎をも理解することができるので、他のアジャイル開発方法論への理解も深まります。

具体的な内容も紹介したいのですが、長くなってしまいそうなので
今後何回かに分けて紹介したいと思います。

これはおすすめです!

設計は死んだか?

XPに対するよくある批判の中で、僕を悲しい気分にさせるのは「XPは設計をしない」というものです。
もっと悲しい気分にさせるのは、アジャイル開発手法が「設計をしない」ことの免罪符として使われることです。
「私らはずっとアジャイルでやってるんで。。。」とまともな設計をやっていないことを堂々と表明された日には、
もう絶望的な気分になってしまいます。

そんな人達に読んでもらいたいのは、マーチン先生の「Is Design Dead?」という論文です。

初稿は2000年ということもあって、目新しさはないですが
XPにおける設計の考え方が簡潔にまとまっています。

この論文のなかで、マーチン先生は
「XPは設計をしないのではなく、設計に対する考え方が違うのだ」
とはっきり述べています。
パターンもUMLも、XPにおいては大切なスキルなのです。

従来型のプロセスでは、開発プロセスの後半になるほど変更の
コストが指数関数的に増大するため、上流工程で要件をFixし、
未来の変更と実際のコーディング時に起こる問題を
予測して設計を行う必要がありました。

しかし、ビジネスの状況の変化に起因する要件変更は、
如何なる要求工学をもってしてもコントロール不能ですし、
コーディング時に発生する問題を全て前もって予測する事も
現実的ではありません。

この問題にたいするXPの解答は、
「テスト」「常時結合」「リファクタリング」の3つの
プラクティスによって変更のコストの指数関数的な増大を
回避するというものです。

ここで強調したいのは、XPで回避されるものは、

「未来の変更を回避するための過剰な設計」であって、「設計」そのものではない

ということです。「シンプル設計」というプラクティスを忘れてはいけません。
XPにおける「シンプルなコード」の基準とは

・全てのテストを通過し、
・プログラマーの意図が明確であり、
・重複したコードがなく
・最小限の数のクラスとメソッドで構成されていること

です。

パターンの力を借りずにどうやってこのシンプルさを保つのでしょうか?
UMLを使わずに、どうやってこのシンプルさを実現するための方法について
他のプログラマーとコミュニケーションするのでしょうか?

アジャイル開発手法と契約

アジャイルな開発手法を採用するにあたって障害となることの一つには、契約の問題があると思います。
アジャイルソフトウェア開発宣言では、契約よりもユーザとの協調を重視していますが、仕事をしてお金をもらうからにはやはり何らかの契約は必要になると思われます。

ここで、あらかじめ仕様をすべて明白にしてコーディングと単体テストの作業のみをビジネスパートナーにお願いするような契約の結び方は当然論外と言えます。

ある程度仕様を詰めながら順次コーディングをして、少しずつシステムを組み立てて行くようなアプローチが必要になるのですが、一般にコーディングと設計の工程が完全に分かれていることを前提にした契約形態をとっている会社ではこのような柔軟なやり方を取るのが非常に難しい。

全てを設計工程の契約のなかで行ってしまうというのが手っ取り早いのですが、設計に携わるエンジニアの方が普通単価が高いので、
これをやると全体的に費用がかかりすぎてしまいます。

かといって開発一括請負という枠組のなかでは、下請法などの制約が厳しくて柔軟に仕様変更を行うことができません。

結局元請けと下請けが両方得をするには1人月いくらという契約のなかで少し一人あたまのお値段をディスカウントしていくしか方法がないような気がしているんですが。。。
そうすると、いままで1k stepいくらとかいう良く意味のわからない契約で開発を請け負ってきた会社からはいくら頑張っても同じお金しかもらえんという文句がでそうですし。。。

むずかしいですね。