ミクロで今更な話をパラパラと
最近のまとめ(・ω・)
基本その1
PresentationやPersistenceといったレベルでのフレームワークは、それ自身が直接アプリケーション固有の課題を解決するわけではないのは言うまでも無いですが。
個々のフレームワークの汎用性と生産性のバランスが、個別の案件にたいして最適とは限らないという点については、まだまだ軽視されているんじゃないかと思ったりして(´・ω・`)
一般論を言えば、あるフレームワークの汎用性と、そのフレームワークを使用するコンテキストを特化したときの生産性は相反するわけで。
よって、個別のアプリケーション開発においては、アーキテクトはアプリケーションに最適なアーキテクチャを選択し、既存のフレームワークで足りない部分は補うものを自作したりするわけですが。
このアーキテクチャの選択・設計如何によっては、生産性は上がりも下がりもするし、品質にも影響するわけで。
まあ、開発にあたっては、フレームワークうんぬんよりも、アーキテクトがなぜそのアーキテクチャを選択し、なぜその設計にしたのかについて語るべきで(´ー｀)
アーキテクトがなぜそういう設計にしたのかを答えられなかったり、それ以前にアーキテクトがいなかったりすると、場当たり的な実装が行われて、ムキーとする人が続出すること請け合い(・∀・)ニヤニヤ
余談1
人月集約的なやりかたをする場合、アーキテクチャの設計を「誰でも出来る」レベルにしようと考えがちだが、むしろ「ついてきやがれ」レベルにした方が上手くいくかもしれないという経験則(｀・ω・´)
余談2
まあ、ミクロなレベルでのフレームワークが成熟してきた今日では、5億程度までの中規模案件なら、人海戦術が必要だとは思ってない(・ω・)
少数のメンバーで最初から最後までやった方が楽だし、金にもなるし(・∀・)
.NET
アーキテクチャの構築にあたっては、.NETの場合は、他に比べて足りない部分の作り込み作業が少なくてすむ気がする(・ω・)
これは、.NETの場合はフレームワークというよりはライブラリ的な面があるので不要な制約が少ないこと、機能の充足度、汎用性と生産性のバランスが良いためじゃないかと考えますが。
ちなみに、EFが嫌われる面があるのは、L2Sに比べて機能/生産性と汎用性のバランスが前者に傾いているからではないかと思う(・ω・)
なお、ここで比較対象としているLINQ to SQLは、前に日記で書いたような拡張メソッドも含むものです。
使われる.NETテクノロジ
WPFにしろEntity Frameworkにしろ、アドホックなものには良いけど、(テクニカルな面が)簡単定型なものを量産するときにはその強みが発揮できない面があったりして。
多くのSI屋がやっている業務系システムといわれるもののは、後者が大半を占め、処理の主体はビジネスロジックと呼ぶ「データ処理」なわけで。
モデルとしては、ERモデルをそのまま使用した方が取り扱いが単純になったりするので、この場合のデータアクセスの方針としては、基本的な処理については式ツリーからSQLを生成するフレームワークを使用し、それ以上の複雑な処理についてはSQLを外だしするタイプのフレームワークを使用するとかいう現実解(・ω・)
とか言いつつ、個人的には最近はWPF/Silverlightのアーキテクチャについて色々検討していたりするけど(・∀・)
業務系システム
この分野では、スマートさや生産性よりもまず、バランスの確保(ベタに書いてどうにか出来ることと言っても良い)が必須になる面もあるので。
これは、CAPのCが必須なのかPが重要なのかみたいなもので、どっちが正しいとかいうものではなくて。
もっとも、設計が微妙だったり、実装がいまいちだったり、生産性と汎用性のバランスがおかしいフレームワークを使用していると、システム固有のアーキテクチャの作り込みが大変だったり、それが出来ていないせいでプロジェクトが上手く回らない結果になるというのも、よくある光景(´・ω・`)
っで、フレームワーク、アーキテクチャが整備されてくると、ドメイン固有のデータ処理が設計の主作業になりますが。
古くはCOBOL時代、あるいは4GL*1というのは、このある種の理想状態にあったわけで。*2
また、SI屋でプログラムが軽視される理由も、ここにあったりするわけですが。
まあ、でも、それを楽しいと思うかどうかは別の話(´・ω・`)
実際のところは、そんなに単純なものでも無いし。
もっとも、まだまだその理想状態には達していないケースの方が多数であり、それ故にアーキテクトの重要性が叫ばれるわけですが…(´д｀;;)
金、その先を見据えて
理想状態に近づくと、プロジェクトのリスクや利益面では大幅な改善が見られて。
それは単に、今までは個々人の場当たり的な作業で、無駄な原価を使っていたと言うことにすぎないわけですが(´д｀;)
まあ、それは良いとしても、技術力の成長という面では、個々人がもっと苦労した方がイーンジャネーノとかも思わんではない今日この頃(・ω・)
これは、技術力は上がっていると感じていなければ駄目で、維持していると思っているなら落ちているという話なわけで。
フレームワーク、アーキテクチャが一度構築され、その点について悩む必要がなくなると、技術力の低下が始まって将来的にヤベーことになんじゃねーの？、っという危惧があるということ(´д｀)
まあ、別に場当たり的な作業で、無駄に原価を使えということじゃないですけど。
対処としては、プロジェクト運営の中に学習プロセスをどう盛り込んで、技術力を蓄積していくかがポイントになると考える次第。
どうせ、学習プロセスはプロジェクトの成功にも必要な要素だし(・ω・)
実行環境
話を言語とかフレームワークとか、そっちに戻す。
正直、.NET以外の環境については、言語ごとに微妙な仕様なフレームワークがあるよりも、完全なASP.NET Web Formsのぱくり*3と、ASP.NET MVCタイプのものと、LINQ to SQLのぱくりがあれば良いと思う、…っとぶっちゃけます(・∀・;)
まあ、クロージャと匿名型のサポートが無いとちょっと微妙になるところもあるので、多少別のアプローチでも良いんですが。
結局のところ、.NETテクノロジが選択できない理由は実行環境の問題にすぎないと思って(・ω・)
PHPが使われているのは、安価なホスティング環境でもどこでも使えるからという面が大きいからで。
変化が遅かったり、仕様が無駄に真面目だったり、未だに2002〜2003年頃のアーキテクチャやSI屋的なフレームワークが幅をきかせている、良い意味でも悪い意味でもEnterpriseでLegacyになってしまったJavaでなければ嫌というこだわりが無ければ、.NETを選択するのは良い選択だと考えマッスル。
余談3
そんなわけで、Javaを選択した場合は.NETを選択した場合に比べて、アーキテクチャののりを作るのが作業が多く発生すると思っていたり。
最初はそれも楽しいけど、繰り返すうちに面倒になってきたりして(´д｀;)
別に.NETだとそういう作業が無い訳じゃないんだけど、作る必要があるのはあくまで個別のアプリケーション固有のアーキテクチャに関する部分だけであって。
既存のフレームワークを使いやすくするためのSomethingとかは別にイランなという感じ(´ー｀)
クラウドっというかAzure
っで、Azureについて。
個人的には、Web Role + SQL Azureはもう単に.NETの安いホスティング環境にしか見えなかったりして。
まあ、それ故にSI屋さんにも受け入れられるだろうけど。
スケールなWebシステムが必要な人なんて、SI屋の事業領域では少数派ですよ、…っとぶっちゃけます(´д｀;)
なのでもうト・キ・メ・キは感じないっという意見もあり。
結論
っということで、みんなWorker Roleの話をしよう(・∀・)
…なんつって。
