Archive for the ‘自社開発フレームワーク『Niji』’ Category
Niji 第1話――怨み節
8月 6th, 2009 by 渡邊
＜error desu.＞ 画面にはそれだけが表示されていた。 この日だけで128回みたエラーメッセージだった。 byte型の変数ではカウントしきれない数だな。 私はキーボードを遠投したくなる衝動を必死で抑えた。 当時、常駐先で、あるWebサイトの裏方システムを開発していた。 典型的なデスマーチ・プロジェクトだった。 「ふざけやがって。またフレームワークのデバッグをしなければならない」 向かいのデスクにいた男が膝で机を蹴り上げながら言った。 私と同じエラーメッセージを拝んでいるのだろう。 「何が原因かわからない。全く無意味なエラーメッセージですね。 『error desu』でググって(Google検索して)も、何の情報もない」 「そりゃそうだ。このプロジェクトでしか使われていないフレームワークだから。 ――単純な機能を開発するだけなら悪くないフレームワークだが、 そういう機能がシステム全体にどのくらいある？ ほとんどの時間をフレームワークのソースコード解析に費やしている。 本来の開発が全く進まねぇ」 ＜error desu.＞は、フレームワークが出力したエラーメッセージだった。 フレームワークはシステムにとって枠組みとなるプログラムである。 そのできがよいほど、開発者の負担は減り、開発コストが抑えられる。 例えば、ショッピングサイト、オークションサイト、映画館の予約サイトには、 Web上で動くシステムに共通の処理・制御がある。 リクエストからユーザの入力値を抽出し、それを然るべきプログラムに処理させ、 適切な画面に遷移させるといったことだ。 フレームワークは、こういった共通の処理・制御を担当してくれる。 従って、フレームワークの導入により、共通部の開発を省き、 開発対象のシステムに固有の仕様（画面デザイン、決済までの手順、決済処理自体等）に 集中して開発できる。 当初の計画では、このプロジェクトの為に開発されたフレームワークが、 従来の開発の8割を吸収してくるはずだった。 しかし、実際に開発が始まってみると、こういう具合だった。 確かに、システム全体の2割の機能については、 従来の開発の8割をフレームワークが吸収してくれた。 残りの8割の機能については、従来の開発以上に余計なコストが発生した。 納期は当初の前提のまま動かなかった――動かせなかった。 「フレームワークの構造上、入力から出力まで全てを実装しないと動作確認できない。 やっと動作確認できた段階になって、＜error desu.＞しか出力されない」 どこにどんなバグ（不具合）があっても、フレームワークはこのメッセージしか出さなかった。 一つの機能は、画面表示・デザインを制御するプログラム、画面遷移を制御するプログラム、 業務ロジックが記述されたプログラム等によって構成される。 それぞれのプログラムを単体で動作確認できる場合と、 全てを連携させないと動作確認できない場合では、 不具合が発生した時にどちらの方が早く原因を特定できるだろうか。 当然、前者の方が早く特定できる。その方が不具合の改修も楽だ。 [...]
Tags: Niji, フレームワーク, 渡邊
Posted in 自社開発フレームワーク『Niji』 | Comments (0)