2009年03月11日

SIer業界改造計画シリーズ1

新3Kと言われてしまっているSIer業界の改造計画を徒然に書いていきたいと思います。

とりあえず、

多層請負構造は禁止しましょう。


つまり、システム開発は直請けのみ許可です。

やはり、多層状態は実作業の面でもオーバーヘッドが大きいですし、妙な上下関係が生まれますし、金銭面でも無意味な中間マージンが発生してしまうので、これは止めましょう。

(つづく)
posted by 台北猫々 at 22:53| Comment(0) | TrackBack(0) | コラムみたいな

2008年09月03日

フレームワークには2通りある(おまけ)

昨日、一昨日は、「学習コスト」という面から考えましたが、精神面から考えても、「とっても苦労して習得した知識・技術」が結局宝の持ち腐れになるというのは、結構辛いことですし、その後に新しい事を学ぼうとするモチベーションも下がってしまうでしょうね。

技術畑にいない人の中には、「技術者は、新しい事をやらしておけば満足するだろ」ぐらいに思っている場合もあるのかもしれませんが、ところがどっこい「人はパンのみにして生きるにあらず」です。
posted by 台北猫々 at 20:53| Comment(0) | TrackBack(0) | コラムみたいな

2008年09月02日

フレームワークには2通りある(後半)

(続き)

現在、開発に使用するフレームワークの選択肢は多種多様ですね。オープンソースとして開発・公開されているものや、SIer達がこれらのオープンソースのフレームワークをラッピングしたりして独自のフレームワークを開発したりもしています。

こういった背景の中、SIerから2次、3次請けする会社のSE・PGが、同じフレームワークを使うプロジェクトに携わり続けるなんてことはほとんど無いでしょう。

例えば、前回はStruts+Spring+iBatis(期間6ヶ月)、今回はフレームワーク無し(期間3ヶ月)、次回はSIer独自FW+EJB3(期間8ヶ月)とかで、さらにOSやWebサーバやAPサーバの違いの合わせ技なんてのも、ありがちだと思います。

この状況下、多くの学習コスト(初期投資)を必要とするフレームワークでは、その回収がままならないというのが現実です。また、しばらく使用しないうちに個人の中の情報が劣化してしまったり、そのフレームワーク自体が陳腐化してしまったりすると、もはや回収不可能ということにもなります。

つまり、多くの学習コスト(初期投資)を必要とするフレームワークを習得することは非常にリスキーであると言えます。
※また、SIer独自のフレームワークは、機能の多い少ないよりかは、書籍が無いことやネット上の2次情報が期待できないこと、さらに下手すると1次情報(マニュアル)が貧相であることもあるので、学習コストは高く「学習コスト的に重量級」であると言えます。

よって、現状では回収フェーズにすぐに入れる「軽量級フレームワーク」が求められるもの、もしくはベターな選択であると言えます。

と、いいつつ実際の現場では重量級のフレームワーク(昔でいえばEJB2, 今だとHibernateとか)を採用している案件が結構多いような気がします。
#私も昔、EJB2の案件に携わったことが多かったです(当時はなんでこんなものが流行っているんだ?と疑問だったものです。。

わざわざ非効率的な方法を選択するのですから、酔狂なことです。

ところで、なんでこんなことになっているのでしょうか?
無知?、それともある組織の陰謀でしょうか?。

多分ですが、
通常、システム開発案件の見積もり項目に「フレームワークの学習コスト」なんて記載しませんし、記載しても認められないでしょう。現実には存在するコストなのですが、書面上には出てこないのですよね。そして、スケジュール上は多少考慮される場合もあるでしょうが、多くの管理者は個人の自助努力に学習コストを押し付けているのではないでしょうか?

こういった背景の中、「学習コスト」は管理されるべきコストからは除外されてしまいます。よって、フレームワークの選択による「学習コスト」の増減についても深く考慮されないのでしょう。
posted by 台北猫々 at 18:40| Comment(0) | TrackBack(0) | コラムみたいな

2008年09月01日

フレームワークには2通りある(前半)

今日は、現場(SIerから2次、3次請けするような会社のSE・PG)で求められるフレームワークについて考えてみます。

で、本題に入る前に投資と回収について1つ話しておきます。
例えばIT投資の場合にシステムの開発を行い運用開始するまでは、投資フェーズと言えますね。この間はお金は一方的に外に流れていきます。そして、運用開始すると回収フェーズとなります。回収フェーズではお金の流れは逆転して、システム化による売上増加や費用削減などにより、手元に入る(残る)お金は増えていきます。そして、一定の期間運用していれば、投資したお金を回収することができ、それから先が本当のシステム化のプラス(利益がっぽがっぽ)フェーズの始まりになります。

つまり、システム開発を行って運用開始しても、しばらくは「投資」>「回収」で、一定期間以上稼動させ続けないと「投資」<「回収」にはなりません。まあ、あたりまえの話ですが。

閑話休題。

フレームワークには2通りあります。
・1つは、多くの学習コスト(初期投資)を必要するため回収フェーズにはなかなか入れないが、その分たくさんの機能を持っているので回収フェーズに入った時の効率は高い重量級です。
・もう1つは、学習コスト(初期投資)は少なく早くに回収フェーズに入れるが、機能はそんなに多くない軽量級です。

で、どちらが現場に求められるかということですが、結論から言うと後者の軽量級フレームワークです。

それは何故かということは明日、説明していきましょう。
(続く)


posted by 台北猫々 at 18:57| Comment(0) | TrackBack(0) | コラムみたいな

2008年07月24日

派遣は、バブルの呪いか?

バブル崩壊後の”空白の10年”は、それまで連綿と先輩から後輩へ受け継がれてきた人材育成というバトンのリレーを断ち切ってしまいました。

そして、一度無くしてしまったバトンを取り返す努力をせずに、財務が弱体化していた企業は、規制緩和によって目の前にぶら下った”派遣”という甘い罠に安易に引っかかってしまいました。

(今思うと、この罠はあまりにも巧妙だったといえます)

”派遣”のような非正規雇用労働者の導入は、労務費の節減を可能にしましたが、同時に人材へ投資するということを放棄することでもありました。”派遣”では支払った分の成果しかでませんが、投資をした人材からは、投資した分の数倍、数十倍の成果を得られるかもしれないのにです。

このような非戦略的・非戦術的・非長期的な、つまり、”いきあたりばったり”な対策を行って短期的な収益UPを得た代償は、人材不足による日本経済の弱体化です。

本来、正規社員として責任を負って仕事を行い、鍛えられ成長するべき若者が、”派遣”という形態で働くということは、日本における人的資源の浪費以外になにものでもありません。

人的資源を食いつぶして短期的な収益を得た各企業、そして”派遣”の規制緩和を推進した政府の罪は重いです。よって、その罪を自覚し、軌道修正を行う努力をするべきなのが、”今”なのだと私は思います。

そうして、健全な社会になったときこそ、バブルの呪縛から解放されたといえるでしょう。
posted by 台北猫々 at 19:39| Comment(0) | TrackBack(0) | コラムみたいな

2008年04月18日

プログラミング言語比較の巻(3)

RubyとJavaについて

Rubyは、正直たいしたものだと思います。洗練されたオブジェクト指向というのでしょうか。プログラミングを楽しめる言語いうのも頷けます。欲しいメソッドが欲しいインスタンスに準備されているのですよね。

ただ、贅沢なことをいうと、Rubyに型宣言(変数宣言時の型を指定すること)が付けば、いいなあと思います。

私は、ふと思ってしまうのです。スクリプト言語に多くある型宣言をしなくていいということで、本当にプログラミングは楽になっているのだろうか?と。実はデメリットの方が大きいのでは?と。

というのは、型宣言がないとIDE(統合開発環境)の効果がほとんどなくなってしまいます。静的なエラーチェックや、候補表示による入力支援などできないですからね。(一部、PHPなどでは、コメント内に変数の型をアノテートすることで入力支援が可能になるものもあるようですが、実際やるとなると厳しいなあと)

私は、ここ数年で最もプログラマーを助けたのは言語やフレームワークではなく、Eclipseだと思っています(Javaに限ってしまいますが)。Eclipseの入力支援、リファクタリング、文法チェックなどの機能は卓越していると思います。これらの機能により、プログラマーが覚えておかなければならないことが軽減するからです。

JavaとRuby、StrutsとRailsを比較すれば、Ruby側の方が生産性が高いかと思いますが、これにEclipseが加わった場合はどうでしょう?ある程度の規模になった場合は、Javaの方が結局生産性が高くなると思います。

近年、開発技術は複雑化の一途を辿っています。そういった情勢の中で、IDEの存在は必要不可欠なものになっているといえます。
なので、RubyがもっとIDEとの相性が良くなってくれればなあ、などと思ってしまう今日このごろです。猫

posted by 台北猫々 at 22:47| Comment(0) | TrackBack(0) | コラムみたいな

2008年04月16日

プログラミング言語比較の巻(2)

私の独断と偏見で、「業務SE・PG向けのコア技術として習得すべき言語5選」を選出しました。

ちなみに私が使える言語は、C, C++, Java, PHP, Perl, Ruby, Python, BShell, COBOL, VB, VC++, HTML, JavaScriptです。


「業務SE・PG向けのコア技術として習得すべき言語5選」
1.C言語
2.Java
3.PHP
4.Ruby
5.HTML

1.業務アプリでC言語を使用することは、最早少ないかもしれないので、実際に仕事で使用することはないかもしれないのですが、コンピュータ・ネットワーク・プログラミングの基礎をおさえるという意味では、やはり習得しておきたい言語です。他の言語と比較して、低レベルのインタフェースを持っているため、バイナリデータや生ソケットを自由に扱えるというのは、技術への理解を深めるためには最適なものです。また、C言語を習得しておくと制御系への転身のチャンスもできるという副産物もあります。

2.Javaについては、多くを語る必要は無いように思えます。言語の特徴というより、シェアが最大の理由です。

3.PHPの「Webアプリ作成のための言語である」という特徴はやはり無視できないものです。言語開発のベクトルが明確なだけ、他の言語と比較して標準装備されている関数などが、Webアプリ開発に関して充実しています。「何にでも使えるように作ったものは、何に使う時にも微妙に不便になってしまうの法則」に縛られていないということですね。また、1次情報・2次情報ともに充実しているということも大きいです。

4.コンパイルを必要としない手軽なコマンドを作成できるスクリプト言語を1つ習得しておくべきでしょう。候補としては、Perl, Python, Rubyがあるのですが、私はRubyを挙げます。Perlについては、増改築を繰り返した老舗旅館、もしくは進化の袋小路(多くの省略記号は、本当にメンテナンスを含めた生産性を上げているのか?)というイメージがあるので、除外。残るPythonとRubyを比較すると、Rubyの方が後発である分、言語仕様が良くできている(例外処理やブロック)こと、さらにRubyが国産であることからRubyを選択しました。私的には、「Ruby on Rails」の存在よりも言語仕様の方に魅力を感じました。

5.HTMLについても、多くを語る必要はありませんね。知らなければお話にならないです。

挙げませんでしたが、C++も余裕があれば習得しておきたいところです。C言語を包含しているオブジェクト指向言語という点です。ともすれば、速度性能面が問題になりがちなオブジェクト指向で、場合によりC言語を使用して速度を出すことができるという柔軟性は魅力です(私の場合、ソフトウエアのコアエンジンを担当する場合が多かったので。昔、プロジェクトの方針でC++で作成していたエンジンを、速度UPのために大部分をC言語に書き換えたこともありました)。

あと、Windowsローカル言語(VB, VC++, C#など)は挙げませんでした。プラットフォームに依存する言語をコア技術とするのは知識や仕事の幅を狭めてしまうと考えているからです。また、挙げた4つの言語を習得していれば、後でWindowsローカル言語を覚えるのは、さほど難しくないと思っています。
posted by 台北猫々 at 20:25| Comment(0) | TrackBack(0) | コラムみたいな

2008年03月28日

プログラミング言語比較の巻(1)

最近Archiveの方で、「各種言語のスケルトン」というものを始めていまして、狙いとしてはプログラミング言語を横断的に網羅したナレッジベースを構築したいというのがあります(「コードなにがし」に方向付けを強く付加したイメージでしょうか)。

副産物として、同じ処理を色々な言語でコーディングしてみて、比較することで言語の特徴や、今後習得すべき言語を考察することもできるかなあというのもあります。

各言語に対する考察をおいおいとしていくとして、今日のところは、こんなページの紹介をしておきます。

「TIOBE Programming Community Index」
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

月毎に言語の人気ランキングを集計しているサイトです。
上位5位までの言語はやはりという感じですね、それに続くPerlも納得いう感じです。

意外なのはRubyでしょうか。メディアで取り上げれているほどには、普及していないのが実情なのでしょうか?とはいえ、日本産の言語がトップ10入りしているのは嬉しい感じがしますね猫

とりあえずは、こんなところで。

posted by 台北猫々 at 21:37| Comment(0) | TrackBack(0) | コラムみたいな

2008年02月02日

リーダーということ

結構昔ですが、仕事上関わりを持った若い人と話していて、「ちょっとずれるな」と思うことに「リーダー」の意味ということがありました。

「リーダー」の役割を、例えば会議の司会進行役を上手くやる人だという考え方をしている人がいるのですね。システム開発でいえば、目の前の作業を上手くまわせる人ということでしょうか。

もちろん、それも大事なのですが、本質とはいえないですね。

「リーダー」の意味は、そのまま訳すと「導く人」ですよね。本質はそこにあります。つまり、メンバーが道に迷わないように進むべき方向を指し示すのが、リーダーの役割だと思っています。

メンバーより多くの情報を持っているはずのリーダーがするべきことは、視野が狭くなりがちのメンバーに代わって、ずっと先のことも見越した物事を考え、チームの進むべき道を指し示す努力と成果を挙げなければならないと思います。

ただ、リーダーにも誤りがあるときもあると思います。指し示す方向が間違ってしまうことも。しかし、かといって、リーダーとしての本質を考えず、司会進行役などでリーダーの職務を全うしているようなことをいうのはナンセンスです。


#ちょっと思い出したので、
#「ソフトウエア受託開発業界考察」に割り込みました。猫
posted by 台北猫々 at 18:21| Comment(0) | TrackBack(0) | コラムみたいな

2008年01月26日

ソフトウエア受託開発業界考察3

今日は「ソフトウエアの適正価格の不透明さ」について少々。

受託システムの価格を決めるのって結構いいかげんですよね。見積もり手法はいくつもありますが、ステップ数から見積もるなんての論外ですし、FP法も経験的にいって、いまいちなんですよね(係数のさじ加減1つですし、IN/OUTのパラメータ数だけでプログラムの難易度を測るのは不確か過ぎます)。

結局のところ金額の根拠が曖昧なために、最終的には相手の思惑・予算に合わせることになります。

さておき、見積もり手法の中で、一番信頼できるのは「類推見積もり法」であると思っています。というのは、システムソフトウエアのように高度な複雑性をもっているものを予測だけで見積もるのは、多分不可能だと思うからです。

実際の現場では、ベテランが「えいやっ!」で出す見積もりは、結構正解だったりするのですが、これは自然に「類推見積もり法」をやっているからです。

そこで、「ソフトウエアの適正価格の不透明さ」に対する私の提案は、完了したソフトウエア開発の情報を集約して管理する公共のデータベースを構築することです。このデータベースには日本で過去行われたソフトウエアの開発プロジェクトの情報が管理されます。各開発会社では、システムの見積もりを行う時にはこのデータベースを検索して、過去の類似したシステムを見つけ、それを元に見積もりを行います。

(長くなったので続く猫


良かったらクリックお願いします→banner_01.gif
posted by 台北猫々 at 22:30| Comment(0) | TrackBack(0) | コラムみたいな

2008年01月05日

ソフトウエア受託開発業界考察2

ソフトウエア受託開発業界考察1で挙げている「未育成のメンバー」について、もうちょっと詳しくいってみましょう。

前提として、ここでいう「未育成のメンバー」というのは、もちろん若手も示すのですが、それだけでなく、入社5年以上のメンバーなどが含まれる場合があります。

「ホウ・レン・ソウ」がほぼ崩壊しているのも、そうなのですが、基本的に"学生"というより"子供"という表現があうような状態のまま年数だけ上がっているような状態のようです。

5、6年前までは、「未育成のメンバー」は"技術者"や"ビジネスマン"として未育成という意味だったのですが、どうも現在の状況を聞くと"社会人"として未育成というようになってきているようです。

ここでも、複数の負の要因が絡まっているのですが、
(1)現場に育成の余裕がないこと。
(2)入社してくる新人のレベル低下。
(3)全体のスキル平均が地盤沈下しているため、「未育成のメンバー」に"このままじゃいけない"という危機感がない。

またさらに、今後の「ユトリンジャー」の入社や、「新3K」という風評による業界人気低下により、(2)がさらに進行し、それに伴い(1)(3)もまた悪い方向に進行することが予測されます。

ここだけでも、負のスパイラルは存在するのですが、さらに(1)は、この業界の根深い問題である「ソフトウエアの適正価格の不透明さ」にリンクしています。

(長くなったので続く猫

良かったらクリックお願いします→banner_01.gif
posted by 台北猫々 at 09:57| Comment(0) | TrackBack(0) | コラムみたいな

2007年12月30日

ソフトウエア受託開発業界考察1

この間、昔の同僚と話をする機会があったのですが、受託開発の現場は大変な状態のようですね。まあ、昔から大変は大変だったのですが、輪をかけてという意味で。。。

ITバブル崩壊以降、少ない開発費・短い工期・不十分な投入人数などナイナイ尽くしのリソースでなんとか頑張ってきていたものが、いよいよほころびが顕著になってきた感じです。

私が受託開発の現場にいた時に見ていたものは、まともな生産性が出せる限られた人間(中心メンバー)が、馬車馬のように働いて、なんとかプロジェクトを完了させている風景ばかりでした。

そんなぎりぎりの開発では、当然のことながら若手を育成する余裕はもちろん無い状態なわけで、そうなると中堅が育ってこない状態になって、中心メンバーは永久にプロジェクトを完了させることだけに一杯々々になってしまいます。

そうなると中心メンバーは、人間ですから疲弊していきます。そして、そのような中心メンバーを満足させる給料を支払っている会社がどれだけあるだろうか、いやない(反語)。

そして、中心メンバーは少しでも優遇してくれる会社を求めて転職していき(また、さらに悪い場合は、激務により心や体を壊して戦線離脱する)、後には未育成のメンバーだけが滞留していく。

これは、受託開発業界にひしめく「負のスパイラル」の1つに過ぎません。負の要因は多くあり、網の目のように絡み合い単純な解決はもはや望むことはできません。

(長くなったので続く猫
posted by 台北猫々 at 22:07| Comment(0) | TrackBack(0) | コラムみたいな

2007年10月06日

ソフトウエア開発プロセス 〜ウオーターフォール編〜 つづき4

結局の所、変革を億劫がってやらないばかりに、根幹部分に欠陥を抱えたまま、ソフトウエア業界は今日もシステムを構築を続けています。

そして、開発に携わっている人間は(もしかすると営業サイドの人間も)、受注当初から失敗する可能性が高いことがわかりつつ、仕事を請け、案の定、火を噴く結果になります。これはある意味、病んでいると思います。

早く、真正面から現在の状況を見据え、小手先でない「変革」をしていかなければならないのです。

posted by 台北猫々 at 17:53| Comment(0) | TrackBack(0) | コラムみたいな

2007年09月30日

ソフトウエア開発プロセス 〜ウオーターフォール編〜 つづき3

理由は単純明快で、今までやってきたことを変えるのが怖いからです。特にソフトウエア開発には多大な費用がかかるというのも要因でしょう。

メインフレームの時代から数十年以上、ウオーターフォール型で開発を進めてきて、見積もり手法や、プロジェクト管理方法、生産物(納品物)のあり方、受け入れのあり方など、仕事の枠的なもの全てがウオーターフォール型をベースにして出来上がってしまっています。

実際のところ、開発が進行するにつれリスクが不明瞭に蓄積していくウオーターフォール型開発は、非常にプロジェクト管理(リスクマネジメント)がしづらいものです。

猫つづく
posted by 台北猫々 at 23:02| Comment(0) | TrackBack(0) | コラムみたいな

2007年09月22日

ソフトウエア開発プロセス 〜ウオーターフォール編〜 つづき2

メインフレームからオープンシステムへ移行し、多様なシステムの乱立と連携、色々なデータベース、また開発環境、言語やアーキテクチャは同じ第三世代であるにも関わらず多種多様です。さらにエンドユーザの要求は日々複雑になっています。

これらの要因の相乗効果により、既にシステムの複雑度は人間の脳の許容量を超えてしまっているのだろうと私は思っています。

つまり、「やってみないとわからない」ことが大変多くなっているのだと思います。

そのため、逐次的で手戻りを許さず、システムの実物ができるまで時間のかかるウォーターフォールは、現状のシステムの複雑度には、全く対応できていないと言えます。

そして、このこと、もしくは近いことを現場で働いている人間を気づいているはずです。

なぜ、改められないのでしょうか?

猫つづく



posted by 台北猫々 at 16:20| Comment(0) | TrackBack(0) | コラムみたいな

2007年09月19日

ソフトウエア開発プロセス 〜ウオーターフォール編〜 つづき

多分、ある程度の規模の受託システム開発を経験している方であれば、開発工程後期に基本設計レベルの仕様バグが出てくることが少なくないことを知っているでしょう(そして、こういったものはスケジュールに関わらず、組み込まないと運用に支障が出てしまうことも)。

こういったことは、要件定義不足・基本(外部)設計考慮不足・考慮漏れにより発生するものですが、責任の所在としては、ユーザと上流で動いているSEにあるといえます。

この辺については昨今、ユーザやSEのスキル低下が指摘されていますね。ですが、本質的には個人のスキルに起因するのでは、ないと私は考えています。

猫つづく
posted by 台北猫々 at 22:07| Comment(0) | TrackBack(0) | コラムみたいな

2007年09月18日

ソフトウエア開発プロセス 〜ウオーターフォール編〜

ウォーターフォール

言わずとしれた欠陥プロセスですね。

http://www.atmarkit.co.jp/aig/04biz/waterfall.html
にありますが、「フィードバックループ」が欠落しているものが、普及してしまったというのが実情のようです。「フィードバックループ」があれば、現在の状況は変わっていたのかもしれないですね。

現状のウォーターフォールは、一度開発に失敗したシステムにのみ適用できるものです。

これは、ウォーターフォールは仕様変更(※1)に対する許容能が低いためです(低許容能は、開発が進むにつれて仕様変更にかかるコストが指数関数的に増加することに起因します。)。

別の言い方をすると、ウォーターフォールは仕様変更(※1)がないことを前提としています。

(※1 ここでいう「仕様変更」は、「要件定義・仕様考慮不足 or 漏れ」によるものを指しています。)

猫 長くなるので次回に続く
posted by 台北猫々 at 23:10| Comment(0) | TrackBack(0) | コラムみたいな

2007年08月11日

私はなぜフレームワークが嫌いか Part3

データベースのフレームワークのあるべき姿は、

―SQLを隠蔽しないこと。
隠蔽する気持ちは分かるのですが(自分もかつて作ったフレームワークでは、定義ファイルに隠蔽しました)、これで満足するのは、フレームワークの開発側だけです。

設定や規約で隠蔽すると、プログラマは極端に2次情報の少ないものと(下手をすると1次情報も不十分なものと)不毛な格闘をしなければならなくなります。まあ、実際にはほとんどないであろう、PKが1つしかないテーブルを結合もせずに全件検索やPKのみでアクセスする以外は。

―データベースの種類に対して、簡易で透過的なアクセスメソッドを提供すること。
PHPのADODBなんかは、良いバランスで作られていると思います。JDBCだと若干水準が低いかなと、もう少し高水準なメソッドが用意されていてもいいかなと。

―EclipseなどのIDEの機能として動作する。
列名のチェックや入力支援、Entityのスケルトン作成など補助的機能の提供があると、DAOの作成が楽になるかなと思います。

こんなところかと、なにしろ今あるフレームワークは頑張る方向性が違ってしまっています。


posted by 台北猫々 at 21:51| Comment(0) | TrackBack(0) | コラムみたいな

2007年07月28日

私はなぜフレームワークが嫌いか Part2

データベースのフレームワークについて考えてみましょう。

良い道具を作るときのコツはユーザの80%が満足するものにすることです。別の言い方にすると、頻繁に使う(主流となる)利用用途に合わせてつくられるべきです。全員を満足させようとすると、80%のユーザにとって不要、もしくは邪魔といっていいものが付加されてしまうからです。

業務の根幹であるデータベースの周りのプログラムは、その業務や案件の特色の影響をもろに受けます。そのため、十人十色といっていいほどに多様化します。システムによりけりというものです。

つまり、合わせるべき主流となる利用用途はないのです。なので、無理にフレームワークを作ろうとすると、あらゆる使用用途を想定することになるため、うんざりするような多くの設定や規約をつくることになってしまいます。

さてさて、それではどうしたいいのでしょう。猫
posted by 台北猫々 at 14:55| Comment(0) | TrackBack(0) | コラムみたいな

2007年07月21日

私はなぜフレームワークが嫌いか

「私はなぜフレームワークが嫌いか」
http://local.joelonsoftware.com/mediawiki/index.php/(Forum)_%E7%A7%81%E3%81%AF%E3%81%AA%E3%81%9C%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%8C%E5%AB%8C%E3%81%84%E3%81%8B
というものを読みました。ちょっと触発されたので、私もフレームワークについて書いてみます。

以前、私もフレームワークのようなものを開発していたことがあります。機能的には今のHibernateのようなデータベースのフレームワークでした。

その時にフレームワーク開発には「バランス感覚」というものが、とても重要になることを知りました。

「どんなものにも使える汎用的なものを作ろうとすると、どんなものに対してもろくに使えないものができあがる」

引用したコラムの中にも同じようなことが書かれていますが、これも実感できます。

「プログラマーは隠蔽するのは好き、隠蔽されるのは微妙」

フレームワークの開発していると色々なものを隠蔽したくなります。そうすれば使う人はきっと便利に違いないと。

しかし、フレームワークを使っていると、「そこは隠さないでよ」というところが多々でてきます。

例えば、Strutsのタグライブラリのアプローチは、はっきり失敗と言えます。
HTMLは比較的シンプルな言語です。それをわざわざ隠蔽することで、脳の負担は
  HTML → 画面イメージ
で済むところが、
  タグライブラリ → HTML → 画面イメージ
となってしまいます。

また、SQLについても同じことがあります。SQLはRDBを扱うために最適化されている言語です。これを隠蔽して、SQLを生成するための別の設定ファイルを準備させるのは全くナンセンスと言えます。

では、どんなアプローチがベターなのか。それは・・・(続きはWebで猫
posted by 台北猫々 at 14:36| Comment(0) | TrackBack(0) | コラムみたいな