コード生成ツールを使用していますか（プロキシの生成に使用されるツールと、組み込みのデザイナーからVisual Studioまでのツールを除く）？
アプリケーションのどの部分を生成しますか？
あなたは通常、あなた自身の発電機を転がしますか？もしそうなら、あなたはどのタイプのジェネレーターを書きますか（aspテンプレート、coddomなど）。そうでない場合は、どのサードパーティツールを使用しますか？
私は現在、データベース構造、ビジネスエンティティ、DAL、BLLの生成からすべてを処理するカスタムコードジェネレーターを使用するいくつかの異なるプロジェクトに取り組んでいます。私は他の人々の経験がこれらの種類のツールであることに興味があります。
私は、コード ジェネレーターが言語の一部にすべきことを示しているため、コード ジェネレーターは「間違っている」と見なす哲学陣営に属しています。
しかし、コードを書くコードを書くことは実用的なプログラマーの倫理の大きな部分を占めてきました。どんなに哲学的に純粋になりたいと思っても、解決したい問題ほど速く言語が進化することはありません。
Visual Studio で Windows フォームをビルドするときに生成されるコードが思い浮かびます。必要に応じて、生成されたコードを見ることができますが、見ないほうがよいでしょう。ただし、命令型コードよりも宣言型コードをプログラムで操作する方がクリーンで信頼性が高いため、WPF を使用して宣言型言語に移行する方が優れていました。
LINQ-To-SQL クラスでも同じことを行うべきでした。プロパティのみを持ち、カスタム動作を持たないクラスには、宣言型言語が必要です。おそらく、これらのエンティティ クラスを動的にすることが容易になるでしょう。つまり、基になるデータベース スキーマが変更されたときに自動的に変更されます。
CodeSmith を使用して、データベース内のすべてのテーブルの .NetTiers クラスを生成しようとしましたが、2 つの問題が発生しました。
.NetTiers は肥大化し、生成されるコードは膨大なものになりました。コード生成ツールのおかげで簡単にフィープを作成できるようになっていると思います。
スキーマは活発に開発および改訂されていたため、多くの再生成も必要でした。すべてのファイルが再生成および置換されていたため、すべてをソース管理に保持することが非常に困難になりました。生成されたコードをソース管理に入れる必要があるかどうか、最終的には確信が持てなくなりました。
コード生成に最適な場所は、設計フェーズではなく、コンパイラまたはビルド フェーズです。C# で匿名型またはメソッドを使用する場合、コンパイラはその場でコード生成を行っています。設計段階でコードを生成すると、基になるパラメーターが変更されるたびに再生成する必要がある大量のデータが得られます。
.net/web ドメインで作業しているわけではありませんが、独自に設計されたさまざまな言語による独自のコード生成ツールは、開発ツール チェーンの重要な部分です。2 つの主要なツール (文法、パーサー、正式な定義を含む) と、m4 や perl などのマクロに基づいて構築された多数のマイナー ツールがあります。それらはすべて、最終的にネイティブにコンパイルされるプレーン C を生成します。
私の経験では、ドメイン固有言語は、大規模なソフトウェア開発においてプログラマーの生産性を高める重要なツールの 1 つです。コンパイラ、シミュレータ、またはその他の非常に複雑なソフトウェアなど、基本言語 (通常は移植可能な C や C++ を意味する) ではまったくサポートされていない多くの反復パターンを使用するものを構築している場合は、コード生成ツールが最適です。私は、ドメイン固有言語を一般化の次のステップと考えています。まず、一般的な計算を関数 (または歴史的なサブルーチン) に分割し、次に一般的な関数をテンプレートまたはジェネリックに分割します (そのような機能が利用可能な場合)。より多くの共通性と反復コードを本格的なカスタム言語に落とし込みます。
実際に記述するコードの量を減らし、退屈な繰り返しや付加価値のないコードをプログラミング プロセスから取り除くことがすべてです。パターンが繰り返されるとすぐに、ドメイン固有言語を適用してください!
古典的なasp作業を行っていたとき（2001年頃）、自分のジェネレーター（データアクセス、sprocsなど）をロールバックし始めました。扱いがはるかに簡単だったので、ゆっくりとCodeSmithに移行しました。私はまだ主に、.NETコード用のすべてのデータアクセス層タイプのもの（sprocを含む）を生成していました。
数年前、私はマクロコード生成（つまりCodeSmith）からマイクロコード生成にジャンプしました。
違いは、CodeSmithを使用して、アプリ用に大量のコードをすべて汎用で一度に生成していたことです。これは、エッジケースや、テンプレートのソース（つまり、テーブル構造）を変更するときに再生成する場合に問題になりました。また、使用していないがテンプレートから生成されたコードを運ぶための在庫が多い場合もありました。これらの方法はすべて機能しましたか？多分そうでないかもしれません。生成されたコードにアクセスしてクリーンアップするのは、膨大な量の作業でした（つまり、同じコードベースで1年以上経過した後）。
対照的に、マイクロコード生成では、必要なクラスを正確に、必要なシナリオで正確に生成できます。これを行うために使用する主なツールはReSharperです。これを行う方法は、本番コードを作成する前に単体テストを作成することです。そのシナリオでは、ReSharperはユニットテストをテンプレートとして使用して、本番コードのスケルトンを自動生成します。次に、空白を埋めるだけです。
データアクセスの場合、私はもう何も生成していません。優れたO/RMが、データアクセス層（つまりNHibernate）に配置するために使用したすべてのものに取って代わることがわかりました。それを考えると、私は自分の人生で別のデータアクセス層を作成したり生成したりすることは決してありません（私は拒否します）。
さらに、特に大規模なユニットテストスイートを使用できるというメリットがあります。
Fog Creek Software の社内言語である Wasabi にはコンパイル時のコード ジェネレーターが組み込まれているため、それらを使用して、データベース テーブルにマップするエンティティ クラスの肉を自動的に作成します。したがって、多数の異なるプロパティとメソッドを持つクラスを記述する代わりに、次のように記述できます。
<ActiveRecord("Kiwi")> _
Class CKiwi
End Class
CKiwi には、Kiwi テーブルの基礎となるスキーマで定義されたすべての列の Load(ix As Int32)、Commit()、およびフィールド/プロパティがあります。これにより、巨大な O/RM ライブラリを用意する必要がなくなりますが、製品にテーブルをすばやく追加することができます。
コンパイラの精神によるコード生成は素晴らしいものです。「魔法使い」の精神によるコード生成は、一様に悪い考えであることが判明しました。
以前はCodeSmithを使用して、NHibernate hbms、エンティティ、およびその他のいくつかのものを生成していました。しばらくして、私たちはこの流れにうんざりしたので、それを捨てました。
T4ジェネレーターは無料で、生成のために調べる価値があります。
モノレールリンクの生成には、引き続きCastleCodeGeneratorを使用します。
自作のコード ジェネレーターは、どのように機能するかの例を含むエンド ユーザー スプレッドシートから単体テスト ケースを作成するのに最適です。
1 つの例については、テスト ケースを作成するためのツールを参照してください。
LLBLGen を使用して、データ アクセス層を生成します。使用しているデータベースにジェネレーターを向け、使用するテーブルを選択すると、必要なクラスが生成されます。それはすべて非常に迅速かつ簡単です。
いくつかのタスクのために独自のツールを作成します。やっていて楽しいし、長期的には時間を節約できます。非常に退屈なタスクの場合、正気を保つことさえできます。
データベースアクセスを処理する社内ビルドのコードジェネレーターがあります。1つはストアドプロシージャを記述し、ゲートウェイクラスで抽象化された対応するメソッドを取得します。
また、Flashと適切にインターフェースするために、つまり例外を適切に処理するためにWebサービスを生成します。
最後に、例外のベストプラクティス（大量のコンストラクターなど）の煩わしさを取り除く例外ジェネレーターがあります。
優れたLLBLGENに興味がある場合は、亜音速を評価することもできます。たぶん、亜音速とt4の間のオーバーラップや相互作用について、ロブ・コナリーが何と言っているかを見ることができます。
以前の雇用主には、XMLスキーマ定義ファイル（XSD）を静的C++ライブラリに変換する自家製のVB.NETアプリケーションがありました。これにより、C ++データ型（bool、std :: stringなど）の操作がはるかに簡単になり、興味深いXMLコードはすべてこれらの生成されたクラス内に隠されていました。
ここオフィスでGrailsを使い始めたところです。以前は、社内のJSF /HibernateCRUD生成スクリプトのセットがありました。
...Grailsが勝ちます。Grailsからのコード生成は非常に優れており、実際にコードをコードファイルに配置しなくても、約15分でCRUDアプリを実行できます。
もちろん、変更したい場合は、実際のコードをコードファイルに生成できます。ほとんどの場合、通常のCRUDの場合、ビューを変更するだけで問題を解決できます。
ここにある他の一部と同様に、データ アクセス、HTML フォーム処理、および特定のビジネス ロジック操作用の独自のコード ジェネレーター (Inon Datamanager/Viewmanager) も作成しました。これをうまく機能させるための鍵は、生成されたコードに触れたり見たりする必要がないように設計することです。
このようにして、それはほとんど言語の一部になります。言語 (この場合は Java) は、ドメイン モデル仕様とビューモデルを含むように拡張され、カスタム ビジネス ロジックに実際の Java コードを入力するだけです。
これにより、アナリストやビジネス ユーザーと通信するための適切なツールが得られると同時に、Java の機能を利用して基本的な動作の詳細をセットアップできます。
私がパーサーを作成したデータ形式の専門家が Web フォームから独自のサンプルを送信し、出力を見て、それが正しいかどうかを教えてくれる素敵なツールを作成しました。
そこから、jUnit テストが生成されます。素晴らしい。
誰もそれを使用することを気にしなかったことを除いて、私はテストケースをまったく収集しませんでした.
私は、さまざまなプラットフォーム (Windows、Linux、Solaris、Mac、BSD など) で再構築できるシリアライズ可能なデータ オブジェクトを生成するために 1 つを使用しました。社内解決でした。
Java Script、Action Script、Java、C#、Objective C などのいくつかの言語で Web サービスのプロキシ クラスを生成するカスタム コード生成フレームワークを作成しました。テンプレートやツールは使用せず、いくつかのヘルパー クラスでコードを生成する単純な C# コードのみを使用します。 、コード生成は本当に多くの時間を節約できますが、生成されたコードはできるだけシンプルであるべきであり、使いすぎるべきではないと思います。