なぜ Teng は良いものなのか
なぜ Teng は良いものなのか､を YAPC で再考させられたのでここにメモしておく｡
Teng は自社開発のウェブアプリケーションを作ってる人たちが作っていて､それがうちのニーズにあってるのでいいっていう話であって､どこでもすごい最高!! と主張したいわけではないです｡まあ､個人の感想ですね｡
ソースが読みやすい
ソースがよくモジュール化されていて､読みやすい｡自身で書いている部分が多いという贔屓目を抜きにしても読みやすいんじゃないかなーと｡
僕らのような自社開発のウェブ屋では､なにか無茶な要望を受けた時にささっと対応するということが求められるシーンが多いので､ソースの読みやすさというのはかなり重要なファクターとなっています｡
複雑な SQL を発行できないように機能が制限されている
SQL ビルダーを使って JOIN やサブクエリを駆使したウェブアプリケーションを開発してしまうと､運用担当や後世の開発者が､以下のような問題を抱えることになります｡
- mysql のスロークエリログを元にクエリを修正しようとしても､どこで実装されているのかを調べることが困難
- クエリビルダの文法に運用担当が慣れていないとチューニングが困難
実装箇所がわかりづらいという点については､SQL Comment で生成位置を挿入する方法もあるので､それでも解決できます｡ 後者の問題は深刻で､大体の場合では社内でSQL に詳しい人は運用を担当しているので､そういう人に診てもらう時にすごく嫌なかおをされたりします｡
まあ､そんな感じでこのへんははある程度以上トラフィックがあるサイトでは致命的な問題となってきます｡
Teng では､SQL ビルダーライブラリの機能はある程度制限したうえで､複雑なクエリは直接SQLをゴーリごりと書けばいいという感じになっています｡
どこでクエリが発行されているかコードを見ればすぐわかる
過去の O/R Mapperでは､コードを見てもどこで DB にアクセスしているのかわからないものもありました｡
そのような O/R Mapper を使っていると､まあ常識的に考えてチューニングが困難になります｡
Relationship サポートをコアに断固としていれていない
has_a や has_many などのサポートを標準ではいれていない｡
これを入れると､開発が楽になるが一方で何も考えずにクエリを発行してしまいがちになる｡
まあ､has_a なり has_many にあたるメソッドは各自で生やせばいいんで､いいですね｡
一息おいて､自分で考えて実装する分には問題はない｡
Teng が作成された本当の理由
DBIx::Skinny っていう Teng の元になった O/R Mapper で上記のうちの大体の機能は実現されていたんですが､DBIx::Skinny ではクラスとしてもインスタンスとしても動くという謎の機構が入っていて､これのせいで非常にコードが読みづらくなっている｡この問題を解消するために Teng として作りなおしたというのが大きい気がしている(これは､僕が持ってる印象なので､他のこみったの人は違う印象かもしれない)｡
まとめ
Teng は初期開発の楽さよりも安定した運用を重視したハイパフォーマンスウェブアプリケーション開発者養成ギプスである｡