愚直なシンプルさを求めるか

etc

直近で呼んだ2つのエントリが妙にリンクしたのでちょっと書いてみる。

普通に良い設計を目指したつもりが、結局はその完璧さを求めるがゆえに脆さを埋め込んでしまうことになります。
もともと正しく動いていて、しかもシンプルな仕組みを再設計するには、それ相応のコストをかける必要があります。
事前検証とテストに時間をかけないといけません。

(途中略)
コンテキストによくマッチしている解法だからシンプルなのです。誰がみても原則がわかりやすく、ぶれない。状態が少なく仕様を覚えやすい。

http://d.hatena.ne.jp/HappymanOkajima/20080617/1213709303

この「ERモデルの関連を明示化する」ことが、JPA・Hibernateの最大の特長ではないかと感じています。
その為のLAZYロードでありJPQLによるJOINの省略記述です。
ER設計時にこのEntityの関連を厳密に定義し、外部キー制約等を含めてJPA・Hibernateの規約に合うような設計を行えば、
JPA・Hibernateの利便度は確実に上がると感じています。逆にこの部分を厳密に定義しない場合（外部キーが厳密な外部キーでない、
結合条件にロジックが必要、主キーが無い等）、SQLの結果セットではなくERモデルそのものを基盤とするJPA・Hibernateは
非常に使い辛い代物に成り果てます。

（途中省略）

JPA・Hibernateの問題点は、そういう現実をあまり主張せず「RDBを隠蔽してオブジェクトによる永続化処理を行う」と宣伝してしまっていることだと思います。
それは間違いではありませんが、「RDBを隠蔽できる」＝「利用するDBがどのような状態であっても、そのDB設計に依存せずにORMだけを見て処理が出来る」ことではありません。
真にRDBからの依存をなくしてObjectによる処理を行いたければ、まずはJPA・Hibernate利用を前提としたDB設計を行い、
JPA・HibernateによるERモデルのマッピングを完璧に理解し、その上でEntityに対して継承戦略・クラス組み込みなど
RDBの概念に無いクラス定義を加えていく形になります。そこは利用者が行わなければなりません。

http://d.hatena.ne.jp/da-yoshi/20080618/1213746180

これら2つから振り返ってみると、以下のようなことが心にひっかかりました。

  • シンプルさ・愚直さが重要。驚き最小限の法則は常に成り立つ。
  • 完璧を目指さない方がうまくいくのではないか。
  • 道具には使いどころ、というのがある。


上記id:da-yoshiさんの例ではJPAが出ていますが、ER設計がJPAを使う想定で正しく行われていないと、
使うのはしんどいのかなあという印象を受けました。
つまり、JPAに精通した人がきちんとER設計から行えれば効果が出る可能性があるという点が
現実なんじゃないかと思います。
そのような設計が行えたときに始めて効果が出る、つまり上記のコンテキスト内で使ってこそ意味があるテクノロジとも言えるんじゃないかと思います。


ではわが身を振り返ってみて、過去現場でそのレベルのER設計ができて、かつJPAのようなJava標準を知っている開発者というのが
どのくらいいたかなあと思うと、非常に稀でしたね（今はまわりに中村さんとか小林さんとかいるんですが）。
なんで、そこは昔自分がいたような現場では敷居が高いかもなあと思っちゃいますね。