さて、またまた前回から1年以上経過してしまったが、続きを書くとする。
筆者は仕事柄、さまざまのシステム開発の現場に参入させていただく機会があり、その都度、プログラムのコード自動生成の技術を援用する機会に恵まれている。
実際に使っている経験から言うと、このセクションで述べているコード生成の自動化という手法は、プログラミングの全局面でおおいに利用できる、というようなものではない。
これを使うことで役に立つ部分は、データベースの定義からの機械的なエンティティクラスのコード生成であったり、特定の実装方法が規定されている部分に対して土台作りとして利用する場合などであると思ってよさそうだ。
すべてのコードを自動生成するという実装を実現しようと思えば、できなくはないが、そのための仕掛けの作成に工数がかかりすぎるため実際の工程上難しいためだ。
通常のシステム開発の現場では、部分的に必要に応じて自動生成を使うという利用方法が実用的と思われる。

それでは現在筆者が実際に利用している具体的な手法を紹介しよう。以前は自作のコード生成ツールを使ったりもしていたが、現在ではVisualStudioに付属のT4を使うことがメインになってきているため、T4を使った手法を紹介する。

まずは、設計書からの利用。
システム開発で設計書が存在しない開発現場というものも存在することがあるが、そのようなケースは少数派と思われるためここでは考えない。
マイクロソフトのExcelで書かれた設計書を利用する方法について考える。
概要を言うと、設計書に記載された項目の属性群をT4のテンプレート内でEPPLUSというライブラリを用いてメモリ上に読み込み、その定義内容に応じて、結果として求められるプログラムコードを生成するようなテンプレートを作成することで、各種設計書からそれぞれの機能に応じたコードを自動生成するというやり方となる。
また、テンプレートは、その目的によって、それぞれ別のテンプレートファイルになる。
例えば、データベースのエンティティクラス作成用のテンプレートファイルや、画面制御用コードを生成するためのテンプレートファイルなど、必要に応じて多岐にわたるものになる。

ここで重要になるのは、このテンプレートファイルの作成であるが、これについては、一概にこれと示すことはできない。そのシステム開発の内容によって千差万別となるためである。
まずはそのシステムで共通的な要素を含んでいると思われる１つのプログラムをパイロット版として作成し、充分な吟味ののち、それをテンプレートファイルに改造する、といった手法が現実的と思われる。

この際に気を付けたいことは、このテンプレート利用によるコード生成では構造的に同じ仕組みをもったプログラムコードが生成されることになるので、重複するコード部分については、一度よく見返してほしい点だ。
つまり、構造的に同じである場合には、それをベースクラスとしてまとめることができないかどうかを一度検討すべきである。
ここはそのようなところにあまり時間をかけたくないという開発方針を持つ現場もあろうかと思うので、絶対とは言えないが、より洗練されたメカニズムを考案したほうが後々のメンテナンスで面倒が少なくなるのでメリットは大きいと思われる。

前回の記事からずいぶん日が経ってしまったが、続きを書いていこうと思う。

プログラムというものは、最大限に簡略化すると、インプットデータを受け取り、何らかの処理を行い、何らかの出力を行うものだ。こう考えると、プログラム以外でも、どのようなものもこうしたメカニズムは持っていると言えるかもしれない。それは人が行う事象への認識のメカニズムと言ってもいいのかもしれないが。
さて、哲学的な考察の穴蔵に降りていくのは避けて、実際のプログラミングについて考察に舵を取る。
データについて、それをどのように処理するか、それはいわゆる仕様と呼ばれるものだが、それに応じてプログラマーは、コードを書く。このコードを書くに当たって、さまざまの実現方法が存在している。
それは、プログラミング言語の種類にもよるし、当該プログラミングを業務として行っている場合にはその業務チーム全体で守るべきコーディング規約にもよるし、あるいは既存のソースがある場合はその一部をコピペして流用するか、新たに書き起こすかだが、それはプログラマー個人の技量にもよって、さまざまなコードが発生し得るものだ。
さまざまなコードが発生する場合にはバグも発生しやすい。バグが無いことが実証済みのコードを流用できる場合はそれを流用してコードを書くというのも一つの良い方法になる。
このさまざまなコードが発生する原因は、プログラムのコーディング方法に言語特有の柔軟性があるためでもあるが、逆に言うと、ある要求仕様を満たすコードを実現するためのコード実装方法が明確に規定されていない場合に、プログラマーが自由な裁量の元にコードを書くことができる点にある。
ということは、全ての要求仕様に対して、その機能を実現するためのコードが予め明確に規定されているならば、バラバラなプログラムコードというものは発生しないということになる。
以上の考察から、結論としては、ある要求仕様に対して、それを実現するためのコードが予め規定されているならば、プログラムは紛れなく統一的な装いを持って実装され得るということだ。
当たり前のようなことだが、これが現実的な開発の現場では実現されていないのが現状で、さまざまのコーディングとバグが存在する訳で、さてここではそれらを低減させるためのコーディング支援機能を考えていく。
やっと表題に追いついた。
具体的には、インプットデータ自体にさまざまな属性を持たせ、その属性を元に、目的に応じたコードパターンに流し込むことによって、コードを自動生成させるツールを作成することを多角的に検討していく。
続きは次回・・・。

はじめに

プログラムを作る仕事をしていると、大量のコーディングを正確に素早く書くことが求められる。そのコーディングルールに準拠した正確な表現および構文や、ロジックの妥当性、また必要にして十分なコードであるかがそのままプログラムコードの成果物として評価の対象になる。

プログラムコードを実際に書くにあたって、具体的にどのように対処するかは以下のように分類できるかと思う。

①　地道にコツコツとコードを書いていく（スニペットなど使うと多少効率的になるかな）
②　パターン化できる部分を見極めて、その部分はマクロや専用プログラムなどを自作して生成し、適宜利用する。
③　大量のコーディングの本質をリファクタリングし、少ないコードで同等機能を実現できる方法を考案、実装する。

これらにはそれぞれ長所短所がある。

①は、コード量が多ければ多いほど比例して作業時間が増え、また人為ミスによるバグの混入の危険度が増す。ある一つの工程で目的とするコード量が3600行ほどとした場合に、１行のコードを書くのに平均で10秒かかったとして3万6千秒＝10時間かかる計算。
また、個人差はあるので一概に言えないが例えば100行に一箇所書き間違いがあったとしたら（そんなに無いだろうけど）、３６個はバグがあることになる。このバグ潰しに＋αの時間がかかる。
スニペットをうまく利用したら１０％ぐらいは早くなるかな？
いずれにせよ、これは普通のコーディングのお仕事のやり方。
②は、パターン化の見極めとマクロ等の作成（デバッグ含む）に2時間かけたとして、そのあとコード生成用に必要なデータ準備、生成の実行と検証、問題があればマクロ等の手直しと再実行と検証、の繰り返し。

これに仮に2〜3時間かけたとして、計４〜5時間かかる計算。
単純に①と比較しても２倍以上作業効率の向上が期待できるだろう。いったん作成したパターンを適用できる対象が多ければ多いほど作業効率が上がるので、大量のコードが対象の場合には数十倍の効率UPという場合だってありえる。

逆に、その工程で目的とするコード量がコツコツ手書きで１時間あれば完了するものを、２時間かけてマクロ等を作っていては無駄な工数をかけただけなので、「普通にすれば簡単にできることを、手の込んだからくりを多数用い、それらが次々と連鎖していくことで実行する」(ループ・ゴールドバーグ・マシン)になりかねないので注意が必要だ。

③は、そもそもリファクタリングと効率的なロジック構造を発明できるかどうかに依存するため、かかる時間は推定できない。そもそも不可能な場合もある。
ただ、いったんできてしまえば、そしてそれが性能等に優れていることが実証されれば（この実証自体にも長い時間を要するが）、その後のスタンダードに取って代わっていく可能性があるものだ。
しかしこれによってどれだけ工数短縮効果があったかの検証も難しいことや、当初の前提となった事項に対する例外的なケースへの対処が容易ではなかったりすることがあると、それだけの欠点を根拠として現場では採用されないことも多くなるのが現実だ。

非常におおざっぱな分類と考察だが、上記のような思わくを踏まえて、まずは③の構造的な効率性の検討の実施、その後、②の手法によるコード生成の効率化、以上で賄えない部分は①のこつこつコーディング、のような方針がトータルとしてコーディングの生産性向上には効果があるのではないだろうか。

最初から最後まで自動生成するツールというものはここでは考察の対象にしないことにしている。まったく対象外として最初から考えなかったわけではない。多くのリサーチおよび実体験の結果、それらの全自動ツールはツール自体による制約が強く、生成されたコードをカスタマイズができないか又はカスタマイズが難しいと断定していい。ツールの作成者やメーカは反論するかもしれないが、自動化するための多くのギミックが詰め込まれているため効率化されていない汎用的なコードや、あるいはツール独自の前提にたった独自のコード生成などがあるため、普通のコーディング感覚でカスタマイズしようとすると、それを使わなかった場合よりかえって大量の工数が発生する、という本末転倒な結果を生じ、ツールに振り回される事態になるので。

より自動化技術が進めば改善されるかもしれないが、今はまだ却下としておく。