スタートアップ＆インクリメンタル開発
をターゲットにした、Eclipse Pluginとして作成されている ERDツールです。
(ERMaster をフォークした ERMaster-b をフォーク)
RDB意識を高める根本のモデル
ERDは、RDB意識を高めるモデルだと考えています。やはり「視覚的な訴え」というのは、人にとって大きなインパクトです。
これはjfluteの個人的な感覚値ですが、"ERDのある現場" と "ない現場" では、RDBへの意識レベルが違ったように思えます。
"ない現場" では、SQLに関する議論もしづらく、「DBは単なる入れ物でたまたま構造的に保存されてる」という感覚になっているムードがあったように思えます。(もちろん個人差ありますが、現場メンバーのスキルレベルはバラバラですから)
ERDのキープするためには？
ただ、ERDのキープはなかなか難しいもの。ERDでシステムは動きませんし、ERDが正しくなくてもシステムは動きますから、ただ描くだけでは、見たいと思うようなERDになりません。9割合ってるけど1割間違ってる(or古い)ERDを見たいとは思わないものです。スタートアップの現場で図をメンテナンスし続けるのは、ほぼ不可能なことだと言っても過言ではありません。
二つ方法があります。
ひとつ、DBからリバースする。
でも、この技術は確立されていません。
リバース自体はできても、人が目で見て嬉しい形に配置されないからです。
リバースされたものを人が手で直して、再リバースしたときに配置を記憶して...とかってのを思いついたりはしますが、実現には随分と時間がかかるでしょう。
もうひとつ、ERDからDBを作る。DBFluteのReplaceSchemaのような機能があれば、ERDからDDLを出力するだけでOKです。その技術は多くのツールで確立されています。
ということで、後者の
ERDドリブンスタイル
による運用が一番現実的だと考えています。
スタートアップでのDB変更
スタートアップなどのインクリメンタル開発では、特徴的なDB変更が発生します。
A. 最初はざっくり設計、あとからしっかり
B. DB設計の得意な人は現場にいない
C. みんなでDB変更
A. 最初はざっくり設計、あとからしっかり
これはもう、以前のブログが参考になる話です。
// SIとスタートアップの違いを知ろう | jfluteの日記
http://d.hatena.ne.jp/jflute/20151007/sista
すでに運用中のテーブルに対して、DB変更がひんぱんに発生します。
B. DB設計の得意な人は現場にいない
これ意外にポイントです。
スタートアップで集まったディベロッパーたち、なかなか "DB設計得意です！" って人が都合よく参加したりしません。
創業プログラマーは得意だったとしても、そのあと集まったメンバーが得意であることは少ないです。
創業プログラマーは別のお仕事でどんどん忙しくなります。
DB設計あまり得意ではない人が設計するということを前提にしないといけないのです。
もちろん "DB設計をちゃんと勉強しよう" とは言いますが、他にも勉強しないといけないことがたくさんありますので、なかなかDB設計だけに注力することは難しいでしょう。
サービスがでかくなって、DBに詳しい人が入ってきたとしても、規模的にその人がすべてを設計するのは難しく、レビューワーの立場として注力するのが現実的なラインです。
つまり、DB設計してリリースして後からまたDB設計し直す、
DBリファクタリングのようなことも頻繁に発生します。
ERMasterとERMaster-bの功績
さて、これらのインクリメンタル開発のジレンマを解決すべく、jflute身の回りでは、ERMaster と ERMaster-b を使っている現場が多いです。
みんなでDB設計するために、ライセンスの縛りのない身軽なオープンソース。それでいながらもグラフィカルで高機能。
ERMaster-b に関しては、ERMaster で現時的に厳しいところを修正して、30テーブルから300テーブルに発展していく過程を、見事にこなせるだけの機能が備わっています。
ERMasterとERMaster-bのジレンマ
ただ、保存ファイルはXMLですが、保存のたびに順序やIDが変わってしまい、実質的にマージはできません。
マージは100歩譲るにしても、差分が取れないので "何を直したのか？"の確認が取りづらいのもつらいです。
もちろん、DBFlute を使っていれば、HistoryHTML でそこは確認できますが、DDLを出力して自動生成するタイミングになるので、もっと早い段階でわかりたいものです。
...
オープンソースの良いところでもあり、つらいところでもあります。
ERMaster や ERMaster-b はコミットがほとんどありません。まだまだ改善の余地はあると考えていますが、それが難しい。
オープンソースなので直せるはずですが、機能が非常に豊富な分コードが積み上がっているため、現実的に現場で片手間で直していくというのも難しい。
フォークして直されている方々もいらっしゃいますが、本家の ERMaster からそれぞれ枝分かれしており、それぞれ個別個別には問題は解決していても、それら解決が一つにまとまったプロダクトは存在せず、現場ではジレンマを抱えていると言えるでしょう。
また、フォークしたプロダクトが、リッチにメンテナンスされるとは限らないでしょう。"ERMasterぷらすあるふぁ" としてのフォークがほとんどかと。(もちろん、それはユーザー次第とも言えますが)
それぞれフォークがあること自体はとても良いことです。
ただ、それと現場のジレンマは別問題で。
ERFluteのかたち
もろもろのジレンマや要件が満たされているわけではないですが...
とりあえず、
ermファイルをマージできる
ようにしました。
マージなんてしないよって人でも、gitの差分で何を修正したのかわかりやすいのは嬉しいでしょう。また、細かいものであれば、XML だけの修正でERDの修正もできます。何か "壊れたー" というとき、XMLの修正で直せたりもします。ERMaster や ERMaster-b ではそれがほぼ不可能でした。
そして ERFlute では、もろもろのジレンマを踏まえた運用をしたいと思っています。
ずばり、ERFluteも同じく、リッチなメンテナンスはできないと考えています。
(jfluteは、DBFlute, LastaFluteを持っていますから)
ゆえに、薄く長く続けていくための構成にしていく必要があると。利用頻度の低い機能はいったん削りました。必要であれば、またそのときにしっかりスマートに作ればいいと。
それよりも、
コードをできるだけシンプルにすること
が求められるからです。
ERFluteは、ERDを描くことに注力したいと考えます。
例えば、DBFluteのような周辺ツールでできることであれば、あまりERFluteには要らない方向で。実際、DBFluteに機能を実装する方が、他のERDツールを使われてる方も恩恵を受けられるので、費用対効果が高いです。
その代わり、ERDを描くために必要な細かい改善を積み上げていきたいと思います。
例えば...
o テーブル名やカラム名の物理名を必須 (done)
o テーブル名やカラム名の重複バリデーション (done)
o ショートカットキーの追加 (not yet)
o などなど
コードや構成を整えて気軽な修正がもっとできるようにして、ERMasterやERMaster-bでは改善されてこなかった細かいところを直していきたいと思っています。
ERMaster や ERMaster-b のコードを読んだことある人であれば、ERFluteの XML を読み込んだり書き込んだりするところ、その分のコードを読むとその意味がよくわかると思います。
プルリクも募集します。
コードをいじるためにあると嬉しい概念図も提供します。
あと、個々にフォークされた "ERMaster-なんとか" で改善された内容を取り込むとかも可能な範囲でできればと。そして、どうせフォークするなら ERMaster からではなく、"ERFluteからフォーク" っていう土台になれればいいなぁとも。
はてさて、どうなることやら
単なるフォークというか、ERMaster や ERMaster-b という素材を使って、新たなERDツールを作ったという風に言えるかもしれません。
はてさて、うまくいくかどうかはわかりませんが、3週間前までのどうにもならないジレンマを抱えていたときに比べれば...(いつか、ERMaster や ERMaster-b をやめないとかなぁ、といか ERD 描くのも諦めるかなぁってもやもや...ってね)
随分と希望に満ちてきた感はありますね(^^。こういうのできたらいいなぁ、と妄想だけしていたものが、形になったときの快感はモチベーションのひとつです。
※試してくれる人は、フィードバック気軽にいただければと。ブログのコメントでもいいですし、Twitterのメンションでもいいですし。
