不完全な抽象化としてのＯＲマッピング

Joel on softwareの本を最近やっと読みました。いい本ですねこれは！！わりと最近の事情とかが織り込まれているので、ソフト開発の関係者なら、近年のソフトウェアエンジニアリング一般教養を最低限はフォローするのに適した本だといえましょう。Webの記事はよみましたが、本のほうとして読んでおく価値があるでしょう。

この中で出てくる概念なのですが、「不完全な抽象化」というのがあって、抽象化は良いけど、自明でない抽象化については必ずその下の下位層の理解が必要になる。結局それで、下位層を理解しなくて良い訳ではないよ、ということになる、ということです。

思ったのは、「ＯＲマッピング」は、正に不完全な抽象化なのだよなあ、ということです。

Joelは、ただ、「不完全な抽象化がいけない」と言ってるわけではなくて、その存在を認識しておけよ、ということを言っているのだと私は解釈しました。理想的なのは、下位層を理解したうえで、いつそれが破れても良い覚悟（と直すスキル）を持って、その「不完全な抽象化」を使うということです。その上で抽象化による利便性は十分に享受する、と。

問題は、抽象化された上位レベルしか知らずに、「下位層を知らなくても良いのだ」と考えるというメンバが開発してしまうことで、破壊的なダメージをもたらす、ということです。ＯＲマッピングの例で言うと、ＳＱＬやＲＤＢＭＳの常識を知らずに、Hibernateで隠蔽されたオブジェクトを通じてシステムを作ってしまうことです。そのようなシステムは最終的にはまともな性能を発揮することはないでしょうし、その修正には眼もくらむようなコスト（有形無形の）がかかることでしょう。このような事態は、最高優先度で避けるべきです。

とはいえ、使う側・費用対効果の問題として言うと、「ＤＢＭＳの熟練した経験者でありかつ熟練した Hibernateの経験者」を集める・育てるのは相当な覚悟（OR/AND高い単金）が必要です。技術取得が１段階余計にかかりますからね。また、ＳＱＬのエクスパートは、そうなればなるほど、ORマッピングツールなんか（まだるっこしくて）使いたがらないものです。動機の面でも問題があるということです。

ということで思ったのは、

「ＯＲマッピングツール利用者のためのＲＤＢＭＳ入門」

があるといいなあと。Hibernateバリバリ利用なシステムを作るときに、とんでもないシステムにならないようにするためのＲＤＢＭＳの最低限の知識入門。生のＤＢＭＳではなくて、「ＯＲＭツールを通じて見たときのＲＤＢＭＳの挙動」を過不足なく解説する書籍（もしくは文書）があるといいな。あるいは

「GORMで学ぶRDBMS入門」

とかね。
私にはスキルがなくて書けませんけれども…。