まず要件があって、それに最適なアーキテクチャ構築のため、フレームワークが存在する
自分の知らないところで、色々と話が進んでいたので、ちょっと呟き(・ω・)
自分の普段のお仕事では、アーキテクチャだとかフレームワークだとか、そんなことばかりをしています(´-`)
見積もりとか要件定義みたいな時からアプリケーション構成を固めていって、いわゆる製造工程にスムーズに入れる(Howで悩まないように)準備をする事がメインで。
っで、画面やビジネスロジックの作る込みが本格的になる頃には、サポートをしつつもそのプロジェクトからは徐々にフェードアウトしていって、次のプロジェクトでまた同じようなことをはじめるカンジで。
ちなみに、お金は各プロジェクトの原価から出ていて、アプリケーションアーキテクトみたいなポジションがあったり、それ用にお金が積まれている訳ではありません。
本来、全てのプロジェクトにはこういう作業の担当官がいるべきだと思いますけどね(・ω・)
形式的なPMOとか作るより、アーキテクチャ専属班を作った方が品質にも利益にも貢献するし(・∀・)
っで、そんなわけで、OSSのフレームワーク拡張だったり、我々フレームワークなんかを作ったりもしているわけですが。
エロい人や営業さんの中で、フレームワークという言葉が一人歩きしていて驚いた(;ﾟДﾟ)
まず、フレームワークって言うのはさ、フレームワークありきで物事を考えるモノではないのよね(・ω・)
それから、「フレームワーク」と「アーキテクチャ」を混同してはいかんよ(♯・∀・)
まあ、当たり前の話なんだけど、まずは要件ありきであって。
その要件にマッチするアーキテクチャというがあって、そのアーキテクチャの構築を手助けするためのフレームワークであって(・ω・)
アーキテクチャを考えずに、フレームワークをどうこう言っても仕方がないデスよ(´Д｀)
AフレームワークではなくBフレームワークを採用する理由だとか、一般的なフレームワークを採用せずに内製フレームワークを使用する理由も、それがアーキテクチャを考えた時に合理的だと判断したからであって。
アーキテクチャを考えずにフレームワークだけ使ってみても、意味は無いどころか有害なケースもありますよ(´・ω・`)
フレームワークではなく、アーキテクチャについて語れよ(｀・ω・´)
あと、一応注意しておくと、アーキテクチャのコピペもすんな、っつって(｀Д´)
対象とするドメイン、機能要件、性能要件の他に、プロジェクトの期間や要員スキルなんかもアーキテクチャを考慮する際のパラメータになったりもするわけで。
他のプロジェクトのアーキテクチャを参考にすることはあっても、基本、ゼロベースで考えるものですよ(｀・ω・´)
大事なことなのでもう一度。
まず要件があって、それに最適なアーキテクチャ構築のため、フレームワークが存在する(｀・ω・´)
おまけ
世の中には、アーキテクチャの構築を手助けするためのフレームワークと言うよりも、
アーキテクチャの規程を強制するためのフレームワークと言うのもあったりしてね(´Д｀)
SI屋の言うところの自社製フレームワークとかいうのは、後者の方を指すことが多かったりもするわけですが。*1
こういうのはフレームワークと言っても、ある意味EoDとは逆方向を向いているので、それを使ってる開発者からの評判は悪かったりしてね(´Д｀;)
っで、それでもまだ同じドメイン、同じアーキテクチャのシステム作成に使われているならマシな方なんですが。
生産性はともかく、作りは一定になるので。*2
でも、そういうのを今までとは異なるドメイン、アドホックな要件の案件に対して適用しようとすると、ゲロ吐くことになりますよ(・∀・)♪
