http://d.hatena.ne.jp/imaginator/20070929厳しく、かつ、非常にありがたいお言葉を頂きました。
丁度良い機会なので、DBFluteの現在あるリスクを分析したいと思います。
しかし、これは恒久的なリスクでないことを決心するため、タイトルに日付を入れています。主なものを以下に挙げます。
1. ConditionBeanと外だしSQLの境目の判断要素の欠如
2. 複数データベースでシンプルな対応ができない
3. 環境構築がうざい
4. 環境に負荷が高い
5. 個人管理である。
<1. ConditionBeanと外だしSQLの境目の判断要素の欠如>
上記の記事の通り、現場のプログラマが迷うことがあります。
そして、「迷いのコスト」と「得られるメリット」の差し引きで
この問題は割り切り(逃げ)たくないと考えています。
プログラマの迷いは極力無くしたいと考えます。原因は幾つか存在すると思われます。
A. そもそも2つの選択肢があること自体が迷う
B. ConditionBeanでどこまでできるかのドキュメントが無い
C. DBFluteを使った参考実装が無い
D. DBFluteの経験者が少ない。「A」は、もちろんその通りですが、別の話題で話したことありますが、
今の世の中のシステム構造・ビジネス状況では、どちらか一方に寄せるのは厳しく、
実際の現場で適用しやすい解決ではないと思っています。
よって、「A」は受容することが前提で「B」以降を検討します。
DBFluteは、あくまで「ConditionBeanと外だしSQLの良きバランス(量的な)」が
現場に一番フィットするだろうというポリシーで話を進めます。「B」は、切実な問題です。
以前から自己認識していますが、解決に至っていません。
これは、リスクの「5」と大いに関連する事柄でありますが、
絶対的に必要なので、「作る」以外の答えがありません。
しかし、じゃあいつ出きるんだという問いには、
「今年中になんとか」という貧弱な返答しかできないです。「C」も、切実な問題です。
「B」も「C」も充実すれば、大分状況が違うでしょう。
さらに、「C」だけでもあればかなり違うとは思います。
例えば、Teeda。Exampleがあります。
ドキュメントが非常に少なかったながらも、Exampleを見て実装ができました。
「こういう場合は、こう実装。そしてこういう場合は、こう実装。...」
という判断が、Exampleでできました。
しかし、DBFluteにはこういったものが今はありません。
そして、この問題の解決も「B」と同様です。「D」は、Frameworkの出初めは必ずこの問題が発生します。
これは、とにかく継続してサポートをしていくことが大事です。
どんな簡単な質問でも受け付けます。遠慮なく質問下さい。
<2. 複数データベースでシンプルな対応ができない>
今は、複数データベース対応する場合は、2つの設定を作って別々に自動生成する
必要があります。すると、似たようなクラスが両方に出来上がってやりづらい部分が
多々あります。(特にjava.util.Dateとjava.sql.Dateと似たような問題)
今、1つの設定・1つの自動生成で、複数のデータベースにアクセスできるようにする
構造を検討中です。共通クラスは本当に共通で接続先だけが違うというような。
公約では、0.6.x系から実装する予定です。(頑張らないと...)
<3. 環境構築がうざい>
今、Eclipseのプラグインを作成中です。ぜひお楽しみ下さい。
今後、プラグインでの利用サポートというのを非常に重要視したいと思います。
(TeedaにおけるDoltengの存在が非常に大きいように)しかし、ごめんなさい to C#ユーザの方
自分はVisualStudioのプラグインを作る技術がございません。
いつかはやりたいのですが、まだ当分先の話になるでしょう。
<4. 環境に負荷が高い>
自動生成なので、ソースの量が多く、コンパイル時のPC性能・実行時のPermSize
に負荷をかけます。
前者はCoreDuoの普及でかなり以前よりはマシになりましたが、
自分も常にソース量を減らすことを意識しています。
ついこないだ、Velocityのテンプレートを1.4と5.0で分けました。
これにて、5.0では遠慮なくGeneric等利用できるようになったため、
都度気付いた時点で、精査を行っております。
実行時のPermSizeについては、増やしてもらうしかないのですが、
これはDBFluteを使わずとも、昨今のシステムにおいてJavaのデフォルトPermSize64M
は少ないことが多いので、少なくとも128M/256Mあたりに増やすことをお奨めします。
<5. 個人管理である>
いつか後輩に言われたことがあります。
「XXさん(jfluteさん)が交通事故で死んだらその時点でDBFluteはfinalですね」
って、おーい。なんて不吉で失礼なことをぉ!
と、ちょっと不幸のリスクはあんまり考えたくないので、
それに近い現実味のあるリスクで考えると、
「仕事が厳しくなって、残業も多くなってDBFluteに手が付かない」
なんてことは、実際にあります。実はこの一年でかなりこの状態がありました。「オープンソースは禁止!」・「マイクロソフトの製品が一番」というポリシーの方々が
主張していたことの一つとしてこんなのがありました。
「オープンソースはバグが出ても直してもらえるかどうか保証がない」
反論したい気持ちもありつつ、上記の分析からすると、反論できない面もあるので複雑でした。DBFluteは他のオープンソースと比べても体制・組織という面では非常に貧弱です。
開発スピードも遅いと思われている方も多いかと思います。
非常に大きな今後の課題です。
自分(jflute)の行動力が試されることでしょう。
その他細かいのは幾つかあるかと思いますが、とりあえずは大きなところを書き綴らせて頂きました。
明確な解決策が無いのもありますが、とにかく現状でこういったリスクがあることを明確にして、
皆様にお伝えしたいと考えました。
少なくとも、例えば3ヶ月後、同じ視点でリスク分析したときには、
上記のリスクが減っているように努力していきたいと思います。そして、それらリスクがおおよそ解決もしくは許容できるようなレベルに達したとき、
「1.0.0」としてリリースできるのかなと。