Programmingふとしたとき、O/Rマッパーに関する議論が勃発します。jfluteとしては「またかぁ」みたいな感じではあります。若い人の中には真に受けて真剣に悩む人もいるでしょう。「jfluteさん、どう思いますか?」って聞かれることもよくあります。議論の本質追究の仕方や問題解決の思考プロセスが曲がってしまうととくないので、ブログを書いてみました。O/Rマッパーに関しては歪んだ議論は横行します。以前こんなブログを書きました。今回はさらにちょっとした補足をしたいと。(最初で最後の記事って書いてたのにまた書いちゃった...)ビジネス要件でアーキテクチャは変わるシステム開発はビジネス的な要求のもと存在します。極端な例をしてみましょう。仮にSQLをベタベタ書いた方がトラブルが少なく、SQLをジェネレートした方が速く作れると仮定します。互いにトレードオフ持つと仮定します。とある二つのシステム開発があって、どちらも規模的には一般的に7000万円かかると想定。片方は、ミッションクリティカルでいかなるトラブルも許容できないシステム、9000万円かけてもいいから、リリース後のトラブルは発生させて欲しくないとのこと。こちらはSQLをベタベタ書いて作った方が良いでしょう。機能によってはちょっとくらいはトラブってもいいし、とにかく早くリリースしたいし、5000万円しか出せない。こちらはSQLをジェネレートして作った方が良いでしょう。他にも要因はたくさんあるので、あくまで仮の世界の話。ここで言いたいことは、アーキテクチャの正解なんて、ビジネス要件によって簡単に覆るということシステム要件ならず、機能ごとにも変わります。求められるSQLも変わってくるでしょう。時間の無駄だと言われるでしょう。半分しか結論はでないその半分も大事だけど、やはり半分は半分なのです。要求のない世界にいながらも、要求を仮定した議論の中で、アーキテクチャの柔軟な組み合わせを考えるべきです。僕らにできることは、現場にフィットする多様な組み合わせを議論してその特徴を把握し、いざ現場でそれを実践すること。「SQLが書けない人がO/Rマッパーに頼る」という論理を掲げる人は後を絶ちません。ここにとても感情的な問題意識をDI(注入)する人も。なんとかして、"O/Rマッパーを使っている人をSQL書けない人に仕立て上げたい"という思いがひしひしと伝わってくることも。それが問題であるならば、しっかり問題分析しましょう。SQLが書けないことは確かに問題になり得ます。パフォーマンス劣化を引き起こす可能性のあるSQLが次から次へと作り出される可能性があるから。全員がハイレベルなSQLを書けるべきでしょうか?システムはDBのために作っているわけではありませんDBだけで成り立っているわけではありません。DBは大事な要素の一つですが、全体の一部に過ぎません。ディベロッパーのやるべきことは多様化しています。適切な業務仕様の設計ができる人がいるでしょうか?ディベロッパー、というか、人の時間は限られています。全ての人が全てのレイヤでハイクラスになるのは難しい。いくら全員がハイレベルなSQLが書けても、Java部分がひどくてCSSも非効率だったらだめなのです。現実的な策を創造していかないと誰もハイレベルなSQLが書けないのは確かにつらい。いう人を連れてくる、もしくは、育てる。効率の良いわかりやすい資料を作ったり勉強会をやるとか。パフォーマンス劣化しやすい機能だけはSQLベタベタ、それ以外は開発スピード重視でSQLをジェネレートするとか。やれることは幾らでもあるし、正解はないでしょう。残念ながらそれでは現場は納得しません。自分のレイヤの重要性を主張します。自分もその気(け)があります...というか、やっぱり多少なりありました。だれでもあるのかもしれませんね。気持ちもわかるっちゃわかるんですけどね。自分の得意なレイヤの仲間を増やしたいという気持ちが作用するのでしょうか?まあ、そのレイヤの人口が少ないのであれば、その人口を増やすのは確かに大事なこと。それはそれで、アーキテクチャが悪い、ツールが悪いと言ってるだけでは何も進まないでしょう。現実的な策を創造していかないとDB周りに興味のある人がいれば、時間を惜しまず親身に教えてあげるとか、そのきっかけを与える資料を作ったり。ときには、講演会をやったり勉強会を開いたり。人に何か伝えるチャンスの場は限られています。jfluteは、DBFluteというツールを通じて、そういった活動にもつながればいいなとは思っています。少なくともDBFluteは、RDBを強く意識したツールであり、RDBのリテラシー向上につながるツールだと思っています。いう思いも込めて日々開発をしています。現実的な実践に移していかないと世の中は何も変わりません。...ちなみに、DBFluteコアユーザのみなさんは、ものすごくSQLも書けますね。DB設計スキルも素晴らしい。どちらかというとそういう人に好まれるツールかもしれません。O/Rマッパーもがんばれ一方で、O/Rマッパー提供側も考える必要があるでしょう。O/Rマッパーを使うことによるデメリットは確かにあるはず。それを少しでも軽減したり、リスクが顕在化しないような努力が必要だと考えています。「見やすいSQL」としてログに出力される方がいい。プログラム上で組み立てたものがどんなSQLになるか、ディベロッパーがログですぐに確認できるように。一行のSQLだったら、見る気も失せてしまいますから。SQLのエラーとか、O/Rマッパーの中でのエラーメッセージは、できるだけ親切であげたいものです。SQLベタベタしたい人からすれば、そのラップされた世界は「余計なもの」に見えます。そこが足を引っ張れば、当然遠慮なくいやな顔されるでしょう。逆に、ラップすることで得られるメリットもあるはず。そのメリットを最大限活かす機能を創造していきたいし、そこをもっと主張しないと伝わらないでしょう。少なくする努力しないと、なかなか支持してもらえないでしょう。「いいじゃん、これぇー」って言ってくれた人が何人もいらっしゃいます。今年一年でも何人かいましたし、今の現場にもいらっしゃいます。(というか、DBFluteはSQLベタベタ書くのも便利だし)親身になって、その現場の特徴と求められていること、それに対するツールによる支援の必要性などを伝えました。現場の思いとニーズが合って使っていると。当然のことながらjfluteが関わってるプロジェクトだけ。厳しい議論を耐え抜いてきたんだろうと切に思います。(ありがとう、ありがとう...)その議論が少しでも楽になるように、jfluteはもっと頑張らなければなりませんね。10歳になってのDBFluteフェス。再開したディズニーシーにはてなブログをはじめよう!jfluteさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。