フレームワークという制約

開発が始まって2週間が経過しました。プログラムの設計書を起こしつつ開発・単体テストをこなし、本体プロジェクトのバグ直しとなかなか忙しい日々が続いています。

今回の機能を実現するのに大きな制約が2つありました。それは「パフォーマンス」と「フレームワーク」。今日の設計ミーティングでの議題は「フレームワーク」でした。
「フレームワーク」という言葉は、糸井重里の「オトナ語の謎。」的に「ざっくり」とした感覚で使われる事の多い言葉です。
簡単に言ってしまえば、Webアプリケーションを開発する際の必要な基盤を指します。
有名な所で言えば、JakartaプロジェクトのStruts、J2EEのMVCもこれに当たります。Webアプリケーションでは共通で使用する機能が存在します。ロギングやDBとの接続、ユーザからのリクエストを一括で処理するServlet等を備えているのが、フレームワークなのです。

長所はもちろん、慣れてしまえば開発が比較的短時間で進む事にあります。しかし、フレームワークは同時に「制約」でもあります。フレームワークは想定される利用機能の集合体であって、想定外の機能を作り込もうとした場合、とてつもなく難しい開発を迫られる事になるわけです。今回のシステムは、自社開発のフレームワークを利用しているのですが、何分古かった為、フレームワークを踏襲すると、今回実現する機能が作り込めない事が判明してしまったのです。

結局、新しくその部分の設計を、フレームワークを踏襲しつつも僅かに改造する事になりました。でも、開発スケジュールは変更されませんから、来週から更にシンドクナリソウデス。

前回の日記で書いたように、システムは使い捨てのものではありません。お客様の投資の額も半端ではないのですから、当然減価償却する（=元を取る）までは大切に利用する事になります。当然そこには保守や追加開発が付属するわけで、その拡張性までも考慮する必要があるわけです。
「新しさより保守が容易で拡張可能なものを」そんな事を学んだのでした。