ソースコードの自動生成

design tool db

ソースコードを生成すると単純なプログラム作業を減らすことができます。そんなわけで、コード生成ツールや思いつきをメモしておきます。

テーブル駆動（テーブルスキーマからコード生成）

RDBのスキーマからコードを生成するという方法です。最近は、オープンソースのツールが公開されているので、それらを使ったり参考にできます。
開発規模が小さい場合は、導入コストも教育コストも低い「テーブル駆動」は良い選択肢だと思います。（使い捨てできるくらい短い開発であれば、生成後のコードを直接カスタマイズして再生成しないこともあります）


モデル駆動

ドキュメント駆動（Excelからコード生成）

以下、雑感です。


テーブル駆動でテーブル名以外のメタ情報を使うには

私の場合は、日本語の付加情報を扱うためにカラムのコメント欄も使っています。やはり日本語のコメントもあるほうが読みやすいからです。RDBMSのカラム名に日本語を使うというアプローチもあります。
さらに、妥当性のチェックルールや区分名(0:有効、1:無効など)を、カラムのコメント欄に持たせることもあります。ただ、ここまでくるとテーブルを使った管理としては無理がある感じがします。

モデル駆動の開発プロセス

「モデル駆動（ドキュメント駆動）」であれば、多くの入力データを管理できる反面、モデルとコードが剥離しないように注意する必要があります。仕様が変わったら、まずモデルを変更するというプロセスや、自動ビルドに組み込む必要があるかと思います（モデルからテーブルを生成するという仕組みにしておくという手もあります）。導入時の敷居は高いですが、基盤やプロセスをしっかりと取り決めていれば、生産性と品質を高められるのではないかと思います（MDAの本質はドメインの再利用かもしれませんが、コードが自動生成できるという長所は大きいと思います）。

インプットとアウトプット

コード生成ツールを採用する場合、何を入力して何を出力したいかを考えることになります。ふつうは、小さなインプット（モデルorテーブル、バリデーション、画面遷移ルールなど）から、多くのアウトプット（データアクセス、ビジネスロジック、バリデーション、画面遷移、プレゼンテーション層、テストコード、ドキュメント）を欲しいと思うものですが、その中から取捨選択をすることになります。

アーキテクチャの検討

それと、どのようなライブラリとフレームワークと組み合わせるかもポイントになってきます。チームのメンバーに負荷を掛けないようにある程度慣れたものか、教育コストが低いコードを生成するように留意する必要があります。以前読んだMDAの本によると、高度に抽象化して隠蔽化したコードを生成すると可読性が下がり、生産性も下がるという話がありました（一般的な社内フレームワークでは、Template MethodやCommandを使って、コードをオーバライドして・・・というフレームワークが多いのですが、このようなコードを生成すると、覚えにくく、アーキテクチャを強制されている感じがするので、あんまり喜ばれないということらしいです）。
もし、生成ツールを自作する場合はどのようなテンプレートエンジン(Velocity,JET,NVelocityなど)を使うか、言語によって生成を振り分けたいか（CodeDom）なども検討材料になります。

手書きコードの分離

また、自動生成コードと手書きコードをうまく分離して管理する必要もあります。継承や分離クラス（Partial）が使えます。



2009年1月、4月に修正、追記しました。