top / index / prev / next / target / source

2009-01-04 diary: ソースコード自動生成に対する一般的な考察

いがぴょんの日記 日記形式でつづる いがぴょんコラム ウェブページです。

old-v2

ソースコード自動生成に対する一般的な考察

私は昔からソースコード自動生成に取り組んできました。そして、2005年からは blanco Framework] というオープンソース・プロダクトを通じてソースコード自動生成に取り組んできました。これらの経験ものとに、特に一般的だと考えられる点について考察してメモしておきます。

ソースコード自動生成に対する一般的な考察

私は昔からソースコード自動生成に取り組んできました。そして、2005年からは blanco Frameworkというオープンソース・プロダクトを通じてソースコード自動生成に取り組んできました。これらの経験ものとに、特に一般的だと考えられる点について考察してメモしておきます。

まずは歴史を知っておこう

ソースコード自動生成を考えるにあたり、先人たちが 20世紀からおこなってきた様々なソースコード自動生成の取り組みについて知っておく必要があります。この点については、以前、＠ITの記事の導入部に概略を記載しました。

この記事からもわかるように、ソースコード自動生成という取り組みは、とても「古くさい」ものなのです。昔からたくさんの人たちや企業が取り組んできた「常識」なのです。どのようなメリット・デメリットがあるのかについても、すでに多くの知見、多くの人的あるいは金銭的投資、そして多くの失敗が積み重ねられてきている、もはや歴史のあるジャンルなのです。(☆なぜ、ここまで強調するのかというと、いまだに歴史を調べずにソースコード自動生成に取り組む人が多く存在しているようだからです)

メリットを導き出すと、デメリットがセットで発生します

コンピュータ・システムで何かメリットを導き出そうとすると、必ずと言っていいほどデメリットが発生してしまいます。(☆これは、ソフトウェア工学の世界では常識の内容であることでしょう)ソースコード自動生成も例外ではありません。何かを自動生成すると、ほぼ確実にデメリットが発生します。これは重要なことです。あなたは ソースコード自動生成に取り組む際には、何かを効率化して、その代償として何かを犠牲にする必要があるのです。違う言い方をすると、目的をはっきりもって、デメリットが発生することを承知の上で、ソースコード自動生成に取り組む必要があるということです。これ以降の様々なコストも勘案したうえで、バランスが取れたシステム化・機械化が求められます。

○○システムを導入すると、教育コストが発生します

メリットとデメリットとがセットで発生する、もっともイメージしやすいものが教育コストです。(そしてツールの設計時に、忘れられやすいもののひとつでもあります)一般的に、何かシステムを導入すると 少なからず教育コストが発生します。ソースコード自動生成のためのツールも例外ではありません。そもそも見方を変えると立派な○○システムなのです。悲しいことに、ソースコード自動生成ツールが多機能になればなるほど、教育コストは増大していく傾向にあります。

例として、ソースコード自動生成ツールをシステム開発プロジェクトに導入する例を考えてみましょう。そのシステム開発プロジェクトに従事する人が そのツールの経験が無い場合、ほとんど強制的に教育コストが必要になってしまいます。ツールがデファクト・スタンダード(事実上の標準)にでもなっていないかぎり、確実に初期稼働が発生してしまうのです。このコストは、ツール設計者は最初から見積もっておく必要があるように考えます。こういった事情から、ソースコード自動生成の効果が教育コストに見合わない場合には、ソースコード自動生成の範囲やツールの仕様を見直す必要があるのです。これは、特にツールを適用するプロジェクトの期間が短ければ短いほど致命的な欠点となります。 私の経験などでは、どうもツール作成者は 何が何でも徹底的にやってしまう、そういう傾向があるように見受けられます。でも、これではうまくいかないのです。目的をはっきり持って、最大のリスク要因のひとつである教育コストとのバランスをしっかり見極める必要があるのです。 これは、ソースコード自動生成ツールという範囲以外においても発生します。ソースコード自動生成ツールかどうかにかかわらず、何かツールの標準教育コストをリストアップしておくことは有益であろうと考えます。

初期教育コストという話題だと、一方で (不思議あるいはジレンマなこととしては) SQL 言語、Java 言語、JSP + Apache Struts、Eclipse統合開発環境などといった広く普及しているツールの初期教育コストが低く見積もることが可能である点にも注意が必要です。というのも、普及して且つ良く利用されるものについては、それらをほぼ 常識として扱って、初期教育コストから除外することが可能である場合があるためです。※たまたまこの日記を書いた時点では、これらが広く普及していた。

ソフトウェア・システムの寿命と、ソースコード自動生成との関係

一般的に、自動生成されたソースコードを手動で編集してはなりません。設計情報からのソースコードの再生成が実行できなくなってしまうからです。この点はソースコード自動生成の歴史が指し示す最大の示唆です。ところが、ところがです。この日記を書いている時点では、自動生成したソースコードを手動編集させるような○○システムなるものが、まだまだ多く存在しています。これは残念なことです。歴史を知らずにやってしまっているのか、あるいは歴史を知った上で、デメリットを覚悟で強行しているのか、それは私には分かりかねます…。※一般的には、＠IT: Excelからプログラムを作る多言語対応オープンソース にあるように、ジェネレーションギャップ・デザインパターンやフック・パターンを用いて、この欠点を回避します。

もちろん、これは開発したシステム・プログラムの寿命と深い関係があります。システム寿命が極端に短い、あるいはシステムのメンテナンスの必要がほとんどない場合には、ソースコードの再生成なんて考える必要はありません。一方、組み込みシステムで何かしらの事情によって制約があり、最適解が利用できないなどの場合にも、これは当てはまらないことでしょう。

逆に考えると、そのような よほど特殊な事情でもないかぎり、一定期間保守する必要のあるシステムの開発においてはソースコード自動生成の再実行が考慮されていないソースコード自動生成の仕組みを構築してはなりません。

ソフトウェア構造化 (コード体系、モジュール分割、パッケージ構造) の重要性

一般的に、ある程度の規模をもったソフトウェアを開発する場合には、何かしらソフトウェアの構造化を考慮しておく必要があります。そしてソースコード自動生成を行う場合には、妥当なコード体系の構築、適切なモジュール分割 (コンパイル単位、ソースコード自動生成単位、jar 単位)、妥当なパッケージの構造といったものを熟慮しておく必要があるのです。経験的には、システムの都合による分割ではなく、業務などの意味による分割が、もっともうまくいくと考えます。これは構成管理とも強いつながりがあるものです。自動生成したソースコードの構成管理における考え方も、明確化しておく必要があります。

一方で、ソースコード自動生成を導入することにより、ソースコードの均質化が機械的に実現できることが期待できます。

開発プロセスの変更を強要するものが存在します

一般的に、何か生産性・保守性を改善する取り組みの中には、開発プロセスの変更を強要するものがあります。ところが、開発プロセスの変更はコストやリスクを伴うものが多いです。これは初期教育コストとも強いつながりがあります。ソースコード自動生成の仕組みの都合上、開発プロセスの変更を強要するものも多いように考えます。でも、あなたのシステム開発プロジェクトで、開発プロセスの変更が可能かどうかについて、妥当性を検証する必要がある点に留意してください。多くの場合、開発プロセスはシステム開発より前に既に決まってしまっている場合が多い点も重要です。

例えば、ドメイン事前登録を必要とするソースコード自動生成ツールは、システムの開発プロセスがウォーターフォール (あるいはウォーターフォール的)になっていることを前提条件としているものが多いです。ところが、ところがです。いくつかのプロジェクトでは (そして正常ではないプロジェクトにおいて)、設計工程の遅れからちゃんと設計が決まっていないのに製造しなくてはならない、などという場合があります。そのような場合に、ドメイン事前登録タイプのツールだと、恐ろしいことに開発が止まってしまう恐れがあるのです。(すべてのツールがそうなっているわけではありません)

自由度、あるいは拡張時の特殊さ

ソースコード自動生成ツールの中には、生産性は高いのだけれども自由度が低いものがあります。少し変わったことをしようとすると、対応できない、あるいは対応できるのだけれども該当箇所だけそれまでとは全く異なる特殊な記述方法になる、というものがあります。あなたが従事しようとしているプロジェクトと、そのツールの制限範囲とのギャップが大きい、あるいは大きくなるリスクが高い場合には、自由度の低さや例外対応の特殊さに悩まされるリスクが高いと考える必要があります。

XML シンドローム

世間の生産性向上ツールの中には、生産性・保守性向上の裏に XML 記述を必要とするタイプのものがあります。その XML を手動で編集するものは要注意です。そのメリットの裏側に、大量の XML 記述を強要するタイプのツールには、特に注意が必要です。

ソースコードと XML と、いずれのほうがコストが高いかについては、ケースバイケース、あるいは工程によって異なるでしょうね。でも、XML を手書きさせられることによる生産性の低下現象は、世の中の多くのプロジェクトでその発生必然性が実証されています。感覚的な表現だと、XMLが開発者の経験値やソースコードの可読性といったものを台無しにしているような感じ、そんなところです。※この日記の記述時点では、世間一般の XML リテラシーがそんなに高くないことも原因と考えられます。XML 整形式かどうかのチェックが出来ない開発者が、依然多く存在しているのです。

なぜか不人気な SQL

XML シンドロームとセット的に不思議なのが、なぜか不人気な SQL のことについてです。SQL を手動で編集しないと実現しにくいシステムは多く存在します。一般的に、データベース・スキーマの正規化 (そして逆正規化) が一定レベル以上実施されている場合には、SQL は手動で編集しなくちゃならないんです。ところが、ツール開発者の中に、SQLを嫌う傾向の人がいて、そういう人が作ったツールは SQL を手動で編集しないといけない現場に対応できない、あるいは対応しにくいものがあります。

リレーショナル・データベースを伴ったシステムの場合、SQL の記述は必要悪だと私は考えています。むしろ SQL は、異なるリレーショナル・データベース間でも一定の標準化がすでに実現されている、枯れて安全な言語です。集合の概念を扱う場合には、SQLは積極的に利用されるべき常識のひとつと考えます。

分散開発への対応度

システム開発コストの低減化やオフショア開発、そしてアウトソーシングなど、システム開発を巡る状況は過酷なものがあります。そういった中、分散してシステムを開発することは、比較的普通のできごとです。、、、ところが、世の中のソースコード自動生成ツールのなかには、分散開発への対応が考慮されていない、あるいは分散開発への対応レベルが低いものがあります。特にドメインを事前に登録するタイプのものに、分散開発への対応レベルが低いものがあるので注意が必要です。

その他のコスト

それ以外にも、以下のようなコストが予見されます。予め適切に見積もっておきましょう。

変更履歴

この日記について