パイプ式ファイル指向プログラム設計

J2EE

このデモを見せて頂いて、目から鱗が落ちた。

http://homepage2.nifty.com/igat/igapyon/diary/2005/ig050512.html
http://hp.vector.co.jp/authors/VA027994/blanco/blanco.html

私は研究畑なので、開発も純粋な研究用ソフトウェアやオープンソースソフトウエアに関してだけであり、一般的な開発現場はほとんど体験したことがない。そんな私でも、実際の開発現場では、少々愚かとも言える、非効率な慣習が沢山あり、その非効率な部分にかなりの時間が費やされることを承知している。

開発を効率化できるような、役に立つさまざまなプログラミングパラダイムや開発方式のほとんどすべてが海外で考えられている。それらはもちろん素晴らしい…が、日本独自の慣習に合わない部分も若干あることがある。もちろん、それらの方法がうまく適合するように開発全体を見直すのが一番良いであろう…しかし、実際にはすべてが顧客次第で、こちらの言うことを素直に聞いてくれるわけではない。しかも、発注元が技術者ではないことも多いのだ。そこでどうするのか？

そこで考えられたのが、このパラダイムである。つまり、日本固有の顧客の要求をあるがまま受け入れ、従来のボトルネック部分を徹底的に分析して解消していくことで、大幅な効率化を図ろうとするものだ。その中には、既存の手法の教えと真っ向から反対するものもある…が、結局は見ている方向が同じなのだ。

この設計方法では、コード、設計書、最終納入ドキュメントという、一般的に独立していると思われるものを、相互に連携させる。現時点では、設計書の記述に世の中で広く使われているMicrosoft Excelを使う点では、Excel-centricなプログラム設計と言い換えることができるかもしれない。

実際に次のようなものを見せて頂いた。デモには、Eclipseを用いて、その外部エディタとしてExcelを使用していた。

この重要な点は次のようなところか（多少誤解はあるかもしれない）。

  • Excelデータの解析は、単純な木構造のXMLデータよりはるかに難しい。これを容易にするために、たとえば表データはこのように書かれるというような経験則をいくつか用いている。ただし、この仮定は妥当だと思う。
  • Excelデータは自動生成されたコードから取り込まれて解析される。つまり、設計書とコードが常にリンクしているので、実際の設計との乖離が起こりにくい。
  • 自動生成されるコードは、フラットである。これは生成されたコードの可読性を高めるためであるが、もちろん人間が緻密に実装したコードとはかなり異なってくる。しかし、柔軟性の確保は、人間の場合はプログラムの構造で確保しようとするのに対して、これではコード生成器で確保されるので、大きな問題にはならないと思われる。一般の現場では、巧妙なコードよりも、理解しやすいコードが重要なのだろう。
  • 一般的に実装で発生しやすいような問題が、設計情報の段階でチェックでき、そのような問題が生じないコードが生成される。これは本当にノウハウの固まり。
  • blancoDBでは、リレーショナルデータベース/SQL指向。ダイレクトにRDBを触れるが、型マッピングにおいては実行時エラーが起こりにくいような制約が課されている。

これらを見ていて思い出したのは、plain2というソフトウェア。これも罫線で書くとコードを自動生成するという、固定幅フォントを主に用いる日本特有のソフトウェア。

http://www.asahi-net.or.jp/~vw4k-kbys/plain2/plain2_b.html

これらのソフトウェアは本当に目的指向なので、私のような門外漢が使う機会はないだろうと思うが、本当に面白いものを見せてもらったと思う。