TOP
PROFILE
MUSIC TUNE
BBS
LINK

2005年01月27日

なぜコイツに拘るのか?

ひとつには今のJavaの状況にあります、あちらはSunが低レベルな言語仕様しか提供しなかったことで良くも悪くもあらゆるフレームワークが乱立した状態になっていますが、性質の悪いことにもう猫も杓子も独自フレームワークの提供という有り難迷惑なモノを押し付けられている状況のようで、弊社でもそれに泣かされた話は枚挙にいとまがない程です。

対してNETはMSが最初から一定レベルの(そしてある程度高品質な)フレームワークを提供してくれている為、それほど拡張しなくても十分に開発できるだけの環境が用意されています。
ただそれでも不十分ではある為、やはりというかなんというか独自にフレームワークを提供してくるベンダーは少ながらずあるのが現状です。
そしてその多くがエゴ又は根拠のないスキルの妄信によって作られた酷いものもであることが多いのです・・自分がいるようなSier (そして業界の多くの企業) は、今A社のプロジェクトをやってても次にはB社のプロジェクトへ行くというのが現状で、プロジェクトが変われば、もうフレームワークも開発のやり方も開発標準も、そして文化も全く異なることがほとんどなのです。
自分は以前からこういった現場の状況にともなう既存スキルのリセットは大きな痛手だという思いが少なからずありました。
(これはサテライト校の夜学で以前みんなにこれについてどう思うかと ぶつけたこともあります)

ならばもし最良と思われるものである程度 統一化できれば、こういったロスを省けるのではないかと考えるようになってきたのが、敢えて言えばいきさつですかね。
(少し現実路線で書けば、全てのエンジニアがリセットされたスキルをまた身につけるべく勉強を重ねるわけではないのです)

そこで問題になるのがその標準化の指針を何処に置くのか?という点。
そんなの無くても良いという人もいるかもしれませんが、指針なき航海はまさに死の航海・・ようするに船出するにはせめて指針となる北極星くらいは必要だということですかね。
ただ幸いなことに.NETにはPatterns&Practicesがあります、そしてPAGチームがその集大成として作り上げたEntLibであれば標準になりうるのではないかと。
もちろんフレームワークだけで開発がうまくいくなんてことは有りえない話ですが、今のところTeamSystemでのTDDサポートやMSF AgileなどでMSが目指してる方向性は間違っていないようにも見えます。
1.0でEntLibが提供する機能は割りと一般的な共通処理 (ロギング、例外処理、構成管理等) がほとんどですが、今後のロードマップとしてSOAやスマートクライアントをも取り込むというのであれば、いずれは共通基盤としてのフレームワークへと進化していくものだと思っています。

(※ 従来のApplicationBlockはその着眼点は面白かったとは思いますが、アプローチの方法がまずかったと・・特にUIPAB (Userinterface Process ApplicationBlock) は共通基盤となり得る可能性を持ってはいましたが、結局開発の現場に導入するには不十分でした・・)

自分が掲げる3つのテーマのGOALは、
「顧客も開発者もみんなが幸せになること」
そのテーマの一角をEntLibに賭けてみようと思ってます。

Posted by GAMMARAY at 2005年01月27日 00:51 | TrackBack
Comments
Application Blockはネタにつかえますよね。 いろんな意味で。悪いいみだけでなく。 ソースが公開されてるから、使えるところだけつかっちゃえばいいし。クソまじめに使うとダメージあります。 でも、ほんと、.NETはいいよな。 Posted by: たつごろー at 2005年01月27日 11:37
従来のABについては、EMABについては問題なしですが、それ以外は面白いことをやってるなぁ〜と言った感じが本音です。 UIPABしかりCashingABしかり、SmartClientしかり(^^; 今回のプロジェクトではEMABのソースを多少拡張して使いましたが、割と大きなサイズのメソッドを、別にメソッドの抽出をするのではなくて#regionで分離してた時はちょっと笑いました(^^) そう言う意味でもAB間であまり意思の統一がないような気もします・・EntLibはそれについても統一化が図られているとエバンジェリストの方が言っておられました。 .NETはMSがネタを色々と提供してくれますから(^^) Posted by: ichikawa at 2005年01月27日 12:11
今後はEntLibを利用する機会が増えそうですね。 ichikawa氏にはわかりやすく解説したレビューの記載に期待。 ちょっとずれますが でどうこう言っていますが自分らのようなSierは 決まっていることが多いのでどうにもできん! って意見です。(>_<)/ 開発体系の見直しは必須です。 Posted by: 幽霊 at 2005年01月27日 13:06
上で抜けている箇所は http://it.nikkei.co.jp/it/column/rashinban.cfm?i=20050121xn000xn です。 Posted by: 幽霊 at 2005年01月27日 13:09
変わらないなら何故自分で変えようとしない? それが出来るエンジニアは生き残る、出来ないエンジニアは淘汰される ただそれだけのことよ。 Posted by: ichikawa at 2005年01月27日 14:56
Post a comment









Remember personal info?