« スタンプ属性や更新履歴テーブルの無駄っぽさ | トップページ | 「無限に広がる大宇宙」のコード進行 »

2010.12.11

さようなら「画面ファイル」

 「キレイなコードでも仕様書の代わりにはならない」の記事で出てきた4GLのもうひとつの利点が、プログラムコードの中でパネルのレイアウトまで記述できたことだった。たとえばパネル表示するためのDISPLAY命令というものがあって、

Display Fields(FIELD1(*Display ...), FIELD2(*Input ...))...

といった調子で、パネルデザインまでをプログラム内部のコードとして端的に記述できた。こういう命令を次のようなネイティブなテーブル操作命令と組み合わせて使えたのだから、便利でないわけがない。

Fetch FromTable(TABLE1) Fields(...) WithKey(...) ...

 それ以前に使っていた開発環境では、プログラムのソースファイルとは別に「画面ファイル」なるものがあった。そこに個々のプログラムが使うパネルのレイアウトや基本的な動作条件を記述する。さらにプログラムソースの中で画面ファイル名を指定し、画面ファイルとともにコンパイルすることでようやく画面が表示される。何のことはない。大昔はなにやら「MVC風」だったのである。

 「MVC風」と比べると、プログラムコードの中でパネルレイアウトまでを定義できるほうがずっと楽だった。プログラミングから実行まで一直線である。気分は完全に「アジャイル」で、どんどんコーディングしてどんどん動かして試せた。システム開発の楽しさを満喫できたし、データベースや業務ロジックの設計問題に自然に集中できた。

 その後、ブラウザベースのシステム開発に関わるようになって面食らった。プログラムコードとは別に、画面制御のためにHTMLファイルやCSSファイルを用意しなければいけないのである。開発環境が進化してコード上で画面レイアウトを含めたプログラムのすべてのありようを記述できるようになったと喜んでいたのに、いまさらマヌケな「画面ファイル」を用意しなければならないとは情けなかった。

 そんな環境での開発は苦労するだろうと予想されたが、じっさいひどく苦労した。画面ファイルがプログラムと泣き別れになって、プログラムと画面とのやりとりを心配するハメになっただけではない。画面遷移の制御に関するこまごました配慮が必要で、そのために実装が小汚くなって保守性が低下した。また、ブラウザの種類やバージョンが違うと画面の見え方が違ったりする。それら毎にテストさせられるなんて拷問みたいなものだ。ブラウザベースにすることで配布の問題が解決され、可搬性も高まるという謳い文句ではなかったのか。

 こういう経験のおかげで、WEBアプリの開発には関わりたくないと思うようになった。基幹システムの開発環境は、データベース構造や業務ロジックの確立以外の問題に手間をとられるようであってはいけない。HTMLに対してよほど透過的なフレームワークを用いるのでない限り、基幹システムをブラウザベースで作るやり方にはいまだに賛成できない。あっという間にレガシーになることが目に見えている。

 ぼくらの関係はとっくの昔に終わっていたのさ。君の顔を懐かしく思い出すことももうないだろう。さようなら画面ファイル。

|

« スタンプ属性や更新履歴テーブルの無駄っぽさ | トップページ | 「無限に広がる大宇宙」のコード進行 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: さようなら「画面ファイル」:

« スタンプ属性や更新履歴テーブルの無駄っぽさ | トップページ | 「無限に広がる大宇宙」のコード進行 »