日本Springユーザー会の勉強会で「企業におけるSpring」という話をしてきました。発表資料はSileShareにあげたのと、Google Groupのファイル共有にあげておきました。サンプルコードもGoogle Groupにあがっていますよ。
20090624-勉強会_企業で使うSpring.pdf
20090624-勉強会_企業で使うSpring_サンプルコード.zip
追記：Springではありませんが、便利機能として紹介したのがSFL4J/logbackのマーカーやコンバーターという仕組みです。マーカーはログの出力切替で利用し、コンバーターはログへのユーザー情報などの埋め込みに使えます。あと、Maven2のプロファイル機能は、profilesタグを使ってプロファイルを定義することで、プロファイルを切り替えることによる設定ファイルの入れ替えを可能とします。
ここ数年はユーザー企業向けの標準化策定というネタが多いので、そこら辺について思っていることを書いてみました。懇親会などでもフィードバックを頂いたのは、コンポーネントの集約と分離という話でしょうか。ここら辺はマイクロソフト萩原さんの受け売りなところもあるので、萩原さんの「アーキテクトの審美眼」を読むと良いですよ。
総じて言いたいのは「きちんと頭を使ってやろう」ということだけです。技術は使いこなしてんなんぼ。ただの道具です。Springを導入することが目的になったらプロジェクトは失敗です。どういうデザインをしたら、よりよいソフトウェアになるのか。そこを真剣に考えた上で、それにあったインフラとして技術を導入しないといけない。
別に経営者の立場になって考えるなんて必要はないけど、そういう心意気は重要。ITがもたらす価値なんて、その企業活動にしてみれば、ほんの一部。たくさんの人が動いてこその企業活動であって、ITは、それを支援するだけ。「現場の人が、こういうことで価値を作っているから、こういう風に支援したい」ぐらいは言っていいし、がんがん提案すればいい。「だから、この技術なんです」って言えばいい。
「早く作れるからユーザー価値が高いんだ」というだけでは、あまりに短絡的で技術者のエゴとしか思えないです。
あともう1つはバランス感覚。普段、皆さんが現場で「これ変だろ」と感じていることは、大抵正しい。だけど、プロジェクトには多くのステークホルダーが関わっていて、そのうちの誰かから見ると変じゃない。そういうことはたくさんあります。
じゃ、それを諦めろとも、徹底的に戦えとも思っていなくて、より大局的な視点からバランスを取るように考えなきゃいけない。これは「がんばってるけど顧客のためになってる？と悩むあなたへ」に書いたことです。
ITの重要性が高まっていることは間違いありません。一方で、技術に振り回されて十分に使いこなせていないのも実態。だから、エンジニアもきちんとした態度で応えていくべきでしょう。
あと、勉強会で「やっぱりビジネスロジックの分割について話を聞きたい」という意見も頂きました。ここら辺は正解のないところなので、なかなか難しいのですが、個人的に「エンジン」と呼んでいるような話なら面白いのかな。最終的なデータを汲み上げるまで複雑なプロセスで処理される場合に、どうしてもロジックが大きなクラスになりがちです。それをワークフローのように組み立てることで、個別のロジックを小さくし、単体テスト性を高めるのがエンジンの役割です。パイプラインアーキテクチャ、コンテキストによるパラメタ渡し/スコープ制御、ステート管理、履歴管理、バリデーション、UIとの連携あたりがネタかな。まぁ、これとて一般的な話といえば、それまでですが。
あ、あとニューキャストの山本さんによる「GrailsでSpringをGroovyにしよう！」が、たいへんマニアックで面白かったです。まずもって、Grailsへの愛が溢れていました（追記：SlideShareはこちら）
。僕自身は2006年ぐらいに「GroovyでSpringを設定する from 稚北」なんつって遊んでいたのですが、これが現実になっていました（もちろん、練り込まれ方は数段レベルは上でしたけど）。Groovy、いいんだけどなぁ。Grails、かわいいんだけどなぁ。エンタープライズで考えちゃうと、なかなか躊躇するところがあるんですよ。言語的なマルチパラダイムは好きなんだけど。
 | アーキテクトの審美眼 (DBMagazine SELECTION) 萩原 正義 翔泳社 2009-03-03 by G-Tools |
