世間一般に認められている優秀なフレームワークというのは結構ある。 中には開発生産性を大きく高めるものもあり、そういうものは大変ありがたく使わせてもらっている。
しかし、社内アーキテクトによくある勘違いが、 「じゃあ、それをラップして、より便利なフレームワークを作ろうぜ (￣ー￣)ニヤリ」 というものだ。
このやり方は、アーキテクトの自己満足になるだけで、実際の開発者には メリットがない場合が多い。具体的なデメリットとして以下のようなものがある。
- 開発者は、基本的には両方のフレームワークを知らなければならない
- ソースが追いづらい
- ラップされる側（いわゆる有名なフレームワーク）の理解が中途半端になる
- アーキテクトの技量が低いと、ラップされる側のフレームワーク機能が使えなくなったりする
- ドキュメントに、ラップされる側へリンクを貼った形式が多くなり理解しづらい
また、実はアーキテクト側にも面倒なことは多い
- ラップされた方のフレームワークに緊急バグフィックスがあった場合に、影響を受けてしまう
- 常にラップされる側のフレームワークの動向をチェックしないといけない
- ラップされる側の有名フレームワークを知っている新規開発者が入ってきても、教育が必要になってしまう
なので、百害あって一利なしだと思う。 基本的には有名なフレームワークを、そのまま使うのがいいのではないか。 フレームワークをラップして洗練するというのは アーキテクトとしては楽しい作業であり、つい盲目的にやってしまいがちだが、 アーキテクトの使命は開発者に楽をさせることだというのを忘れてはならない。
なんてことを、NHibernateをラップしたActiveRecoredを使っていて思いました。 ようするに愚痴です orz