コードジェネレーターは悪いですか？

https://stackoverflow.com/questions/202871

03-07-2019
|

質問

MyGenerationとnHibernateを使用して、基本的なPOCOオブジェクトとXMLマッピングファイルを作成します。コードジェネレーターは良いアイデアではないと思う人がいると聞きました。現在の最高の考え方は何ですか？数千行の理解できないコードを生成するとき、コード生成が悪いというだけですか？

解決

コード生成プログラムによって生成されたコードは、（一般化として）その後、人間の介入によって編集される状況では使用しないでください。 Visual C ++のさまざまなインカネーションのウィザードなどの一部のシステムは、プログラマーが手で編集することを期待されていたコードを生成しました。開発者が生成されたコードを選択して理解し、修正する必要があるため、これは一般的ではありませんでした。また、生成プロセスがワンショットであることも意味しました。

生成されたコードは、システム内の他のコードとは別のファイルに存在し、ジェネレーターからのみ生成される必要があります。生成されたコードは、人々がそれを変更してはならないことを示すために、そのように明確にマークされる必要があります。ある種のコード生成システムをかなり頻繁に実行する機会があり、そのように生成されたコードの All の前文には次のようなものがあります。

-- =============================================================
-- === Foobar Module ===========================================
-- =============================================================
--
--         === THIS IS GENERATED CODE.  DO NOT EDIT. ===
--
-- =============================================================

動作中のコード生成は、このテーマに関する非常に良い本です。

他のヒント

コードジェネレーターは素晴らしい、悪いコードは悪い。

このページの他の応答のほとんどは、<！> quot;いいえ、多くの場合、生成されたコードがあまり良くないためです。<！> quot;

これは、次の理由で不適切な回答です。

1）ジェネレーターは、他のツールと同様のツールです。誤用しても、ツールを非難しないでください。

2）開発者は、優れたコードを1回作成できることに誇りを持っている傾向がありますが、1回限りのプロジェクトにはコードジェネレーターを使用しないでください。

すべてのJavaプロジェクトで永続性を確保するためにコード生成システムを使用し、数千もの生成されたクラスを本番に持っています。

マネージャーとして私は彼らを愛しています：

1）信頼性：そのコードに重大なバグは残っていません。デバッグ時に永続レイヤーについて心配することはありませんが、長年にわたって徹底的にテストされ洗練されてきました。

2）標準化：すべての開発者コードはこの点で同一であるため、同僚から新しいプロジェクトを選択する際に男性が学ぶことははるかに少なくなります。

3）進化：より良い方法を見つけた場合、テンプレートを更新し、数千のクラスを迅速かつ一貫して更新できます。

4）革命：将来、異なる持続性システムに切り替えると、すべての持続性クラスがまったく同じAPIを持っているという事実が私の仕事をはるかに容易にします。

5）生産性：数回クリックするだけで、メタデータから永続オブジェクトシステムを構築できます。これにより、退屈な開発者の数千時間を節約できます。

コード生成は、コンパイラを使用するようなものです-個々のケースでは、より最適化されたアセンブリ言語を記述できるかもしれませんが、多くのプロジェクトでは、コンパイラがあなたのためにそれを行うでしょうか？

カスタマイズを失わずにクラスを常に再生成できるようにするために、単純なトリックを使用します。生成されたクラスはすべて抽象クラスです。次に、開発者はそれを具体的なクラスで拡張し、カスタムビジネスロジックを追加し、標準とは異なる基本クラスメソッドをオーバーライドします。メタデータに変更があった場合、彼はいつでも抽象クラスを再生成できます。新しいモデルが具体的なクラスを壊した場合、コンパイラは彼に知らせます。

コードジェネレーターで私が抱えていた最大の問題は、メンテナンス中です。生成されたコードを変更してからスキーマまたはテンプレートを変更し、再生成しようとすると、問題が発生する可能性があります。

1つの問題は、変更したコードに加えた変更をツールで保護できない場合、変更が上書きされることです。

特にWebサービス用のRSAのコードジェネレーターで見た別の問題は、生成されたコードをあまりにも変更すると、ジェネレーターが不一致があると不平を言い、コードの再生成を拒否します。これは、変数の型を変更するような簡単な場合に発生する可能性があります。その後、別のプロジェクトにコードを生成し、結果を元のコードにマージします。

コードジェネレーターは生産性の向上に役立ちますが、探すべきことがいくつかあります：

思い通りに働きましょう。

生成されたコードに合わせて生成されていないコードを曲げる必要がある場合は、おそらく別のアプローチを選択する必要があります。

通常のビルドの一部として実行します。

出力は中間ディレクトリに生成され、ソース管理にチェックインされません。ただし、入力はソース管理にチェックインする必要があります。

インストールなし

理想的には、ソース管理へのツールもチェックインします。新しいビルドマシンを準備するときに人に物をインストールさせることは悪いニュースです。たとえば、分岐する場合、コードを使用してツールをバージョン管理できるようにします。

必要に応じて、ソースツリーのコピーを持つクリーンなマシンを使用する単一のスクリプトを作成し、必要に応じてマシンを構成します。完全に自動化してください。

編集出力なし

出力を編集する必要はありません。出力がそのままでは十分に有用でない場合、ツールはあなたのために機能していません。

また、出力には、生成されたファイル<！> ampであることが明確に記載されている必要があります。編集しないでください。

読み取り可能な出力

出力は<！> amp;うまくフォーマットされました。出力<！> ampを開くことができます。多くの問題なく読んでください。

#line

多くの言語は<=>ディレクティブのようなものをサポートします。これにより、たとえば、コンパイラエラーメッセージを生成するときやデバッガをステップインするときに、出力の内容を入力にマップできます。これは便利な場合もありますが、本当にうまくやらないと迷惑になる可能性があるため、要件ではありません。

コードジェネレーターは悪くないというスタンスですが、コードジェネレーターの多くの使用法は悪くありません。

時間の節約のために優れたコードを記述するコードジェネレーターを使用している場合は素晴らしいですが、多くの場合、最適化されていないか、多くのオーバーヘッドが追加されます。

振る舞いをクラスに混在させたい場合、コード生成により悲しみが生じる可能性があります。同様に生産性の高い代替手段は、属性/注釈とランタイムリフレクションです。

コンパイラはコードジェネレータであるため、生のマシンコードでプログラミングしたいだけでない限り、本質的に悪いものではありません。

ただし、コードジェネレーターは、生成されたコードを常に完全にカプセル化する必要があると考えています。つまり生成されたコードを手動で変更する必要はありません、ジェネレータへの入力を変更してコードを再生成することで変更を行う必要があります。

Fran Tarkentonがあなたに売ろうとしているメインフレームのcobolコードジェネレーターなら、絶対にそうです！

以前にコードジェネレーターをいくつか書いたことがあります-正直なところ、何度も私のお尻を助けてくれました！

オブジェクト-コレクション-ユーザーコントロールデザインを明確に定義したら、コードジェネレーターを使用して基本を構築することができます。本当に300以上のパブリックプロパティ宣言と変数のインスタンス化を作成したいのは誰ですか？心のない反復的なタスクよりも、ビジネスロジックにこだわる方が好きです。

コード生成を使用するときに多くの人が犯す間違いは、生成されたコードを編集することです。コードを編集する必要があると感じた場合、実際にコード生成ツールを編集する必要があることを念頭に置いておくと、生産性の向上につながります。生成されるコードと絶えず戦っている場合、生産性が犠牲になります。

私が見つけた最高のコードジェネレーターは、コードを生成するテンプレートを編集できるものです。 Codesmithはテンプレートベースであり、テンプレートを簡単に編集できるため、この理由でCodesmithが大好きです。生成されるコードに欠陥があることがわかったら、テンプレートを編集してコードを再生成するだけで、その後は永遠に元気になります。

私が見つけた他のことは、多くのコードジェネレーターがソース管理システムで使用するのが非常に簡単ではないことです。これを回避する方法は、コードではなくテンプレートをチェックインすることであり、生成されるソース管理にチェックインするのは、生成されたコード（DLLファイル、ほとんどの場合、）。数百の生成されたファイルではなく、いくつかのDLLをチェックインするだけで済むため、これにより多くの悲しみが軽減されます。

現在のプロジェクトでは、コードジェネレーターを多用しています。これは、<！> quot; obvious <！> quot;の両方を見たことを意味します。初めてコードを生成することの利点-コーダーエラー、タイプミス、標準コーディングスタイルの順守-および、メンテナンスモードでの数か月後の予期しないマイナス面。実際、コードジェネレーターは、最初はコードベースの品質を改善しました。完全に自動化され、自動ビルドと統合されていることを確認しました。しかし、私はそれを言うでしょう：

（1）コードジェネレーターは松葉杖にすることができます。私たちのシステムには、メンテナンスが難しいコードの巨大でい塊がいくつかあります。過去のある時点では、適切な分析とクラスを行うよりも、20個の新しいクラスをコード生成XMLファイルに追加する方が簡単だったからですリファクタリング。

（2）ルールの例外はあなたを殺します。コードジェネレーターを使用して、数百のスクリーンクラスとビジネスオブジェクトクラスを作成します。最初は、クラスに表示できるメソッドに標準を適用しましたが、すべての標準と同様に、例外を作成し始めました。現在、コード生成XMLファイルは巨大なモンスターであり、選択クラスに挿入されるJavaコードの特別な場合のスニペットで満たされています。解析または理解することはほぼ不可能です。

（3）データベースの値を使用して非常に多くのコードが生成されるため、開発者が個々のワークステーションで一貫したコードベースを維持することは困難であることが証明されています（データベースには複数のバージョンがある可能性があるため）。ソフトウェアを介したデバッグとトレースは非常に難しく、チームの初心者は<！> quot; flow <！> quot;余分な抽象化とクラス間の暗黙的な関係のため、コードの。 IDEは、コード生成クラスを介して通信する2つのクラス間の関係を取得できません。

これで十分でしょう。コードジェネレーターは、開発者の個々のツールキットの一部として素晴らしいと思います。定型コードを記述する一連のスクリプトを使用すると、プロジェクトを簡単に開始できます。ただし、コードジェネレーターはメンテナンスの問題を解消しません。

特定の（多くはない）場合に便利です。データベーステーブルのルックアップタイプのデータに基づいてクラスを生成する場合など。

コード生成は、プログラミングをより困難にする場合（IE、生成コードの悪さ、またはメンテナンスの悪夢）は悪いですが、プログラミングをより効率的にする場合は優れています。

これらはおそらく最適なコードを常に生成するとは限りませんが、必要に応じて、開発者の工数を節約することでいくつかの小さな問題を補うことができます。

とはいえ、ORMコードジェネレーターに対する私の最大の不満は、スキーマが変更された場合、生成されたコードをPITAにできることです。

コードジェネレーターは悪くありませんが、別のソリューションが存在する状況で使用される場合があります（つまり、オブジェクトの配列が数行のコードでより適切で達成されたときに100万のオブジェクトをインスタンス化する）。

他の状況は、それらが誤って使用されたり、コーディングが不適切な場合です。バグ、または正しく構成する方法を誤解しているために悪い経験をしたため、コードジェネレーターを誓う人が多すぎます。

しかし、それ自体、コードジェネレーターは悪くありません。

-アダム

これらは他のツールと同様です。他のものよりも良い結果をもたらすものもありますが、それらをいつ使用するかを知るのはユーザー次第です。ハンマーは、ネジを締めようとしている場合、ひどいツールです。

これは、非常に議論の多い問題の1つです。個人的には、コードジェネレーターのほとんどは最適化されていないがらくたコードが原因で本当に悪いと思います。

しかし、質問は本当にあなただけが答えることができるものです。多くの組織では、プロジェクトの実行速度や保守性よりも開発時間が重要です。

コードジェネレーターを使用して、データエンティティクラス、データベースオブジェクト（トリガー、ストアドプロシージャなど）、サービスプロキシなどを生成します。しかし、保守性が苦痛であるという程度まで使いすぎてはいけません。それらを再生成したい場合にもいくつかの問題が発生します。

Visual Studio、Codesmithなどのツールには、ほとんどの一般的なタスク用の独自のテンプレートがあり、このプロセスを簡単にします。しかし、自分で簡単に展開できます。

コードに何が起こっているのかを理解することができない場合、保守性の問題になる可能性があります。したがって、多くの場合、プロジェクトを簡単に保守できることと比較して、プロジェクトを迅速に完了することがいかに重要であるかを検討する必要があります

保守性<！> lt; <！> gt;簡単または高速なコーディングプロセス

Entity GenerationでMy Generationを使用していますが、問題はありません。スキーマを変更した場合は、クラスを再生成するだけで、すべて正常に機能します。

これらは松葉杖として機能し、プログラムを長期間維持する能力を無効にすることができます。

最初のC ++コンパイラは、Cコード（CFront）を吐き出すコードジェネレータでした。

これがコードジェネレーターの引数なのか、それとも反対なのかわかりません。

ミッチェルは頭を打ったと思う。コード生成には場所があります。コンピューターに作業を任せる方が効果的な場合があります。コードを変更するための時間コストが小さい場合、特定のコンポーネントの実装について心を変える自由を与えることができます。もちろん、コードジェネレーターの出力を理解することはおそらく重要ですが、常にそうとは限りません。いくつかのC ++アプリが名前付きパイプを介してC＃アプリと通信する必要があるプロジェクトの例がありました。メッセージを定義し、トランザクションの各サイドで生成されたすべてのクラスとコードを持つ、小さくてシンプルなファイルを使用する方が適切でした。プログラマーが問題Xに取り組んでいたとき、最後に必要だったのは、メッセージのインプリメンテーションの詳細と必然的なキャッシュヒットを心配することでした。

これはワークフローの質問です。 ASP.NETはコードジェネレーターです。 XAML解析エンジンは、MSILに変換される前に実際にC＃を生成します。コードジェネレーターが開発ワークフローから分離されたCodeSmithのような外部製品になる場合、プロジェクトの同期を保つために特別な注意が必要です。たとえば、生成されたコードがORM出力であり、データベーススキーマを変更する場合、コードジェネレーターを完全に放棄するか、C＃の機能を利用して部分クラスを操作する必要があります（メンバーを追加できます）既存のクラスを継承せずに機能します）。

私は、ジェネレーターワークフローの分離された/ Alt-Tabの性質を個人的に嫌います。コードジェネレーターがIDEの一部ではない場合、それは厄介な気がします。 Entity Spaces 2009（まだリリースされていない）などの一部のコードジェネレーターは、前世代のジェネレーターよりも統合されています。

コードジェネレーターの目的に対する万能薬は、プリコンパイルルーチンで楽しむことができると思います。 C＃や他の.NET言語にはこれがありませんが、ASP.NETはそれを楽しんでいます。そのため、たとえば、SubSonicはASP.NETで非常にうまく機能しますが、それ以外はあまり機能しません。 SubSonicは、通常のASP.NETコンパイルが開始される直前に、ビルド時にC＃コードを生成します。

ツールベンダー（Microsoftなど）に事前ビルドルーチンをより徹底的にサポートするよう依頼し、メンテナンスが必要な外部出力コードファイルとして手動で管理するのではなく、メタデータを使用してコードジェネレーターをソリューションのワークフローに統合できるようにする単独で。

ジョン

コードジェネレーターの最適なアプリケーションは、プロジェクト全体がモデルであり、プロジェクトのすべてのソースコードがそのモデルから生成される場合です。私はUMLや関連するがらくたを話していません。この場合、プロジェクトモデルにはカスタムコードも含まれます。

開発者が気にしなければならないのはモデルだけです。単純なアーキテクチャの変更により、数千のソースコード行が即座に変更される場合があります。しかし、すべては同期されたままです。

これは私見の最良のアプローチです。ユートピー音？少なくとも私はそうではないことを知っています;）近い将来がわかります。

最近のプロジェクトでは、独自のコードジェネレーターを作成しました。すべてのデータベースのものと、ビューおよびビューコントローラクラスのすべてのベースコードを生成しました。ジェネレーターの構築には数か月かかりましたが（これはこれが初めてだったためで、いくつかの誤った開始があったためです）、最初に実行して、アプリ全体の基本的なフレームワークを生成しました約10分。これはすべてJavaで行われましたが、Rubyは特に小規模な1回限りのタイプのプロジェクトに最適なコード記述言語です。最も良いのは、コードとプロジェクト組織の一貫性です。さらに、基本的なフレームワークを事前に考えておく必要があります。これは常に良いことです。

コードジェネレーターは、優れたコードジェネレーターであるという前提で優れています。特に動作するc ++ / javaは非常に冗長です。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow