コード生成はコード品質を向上させますか？
コード生成について議論して、コード品質を向上させる方法の例をいくつか探しています。コード生成の意味を明確にするために、私は私のプロジェクトについてのみ話すことができます。
XMLファイルを使用してデータベーススキーマのエンティティの関係を記述しているため、エンティティの追加、削除、変更に使用できるORMフレームワークとHTMLフォームを生成できます。
私の考えでは、人的エラーが減少するため、コードの品質が向上します。何かが正しく実装されていない場合、モデルで破損します。これは、生成されたコードも破損するため、エラーがより早く表示される可能性があるため、問題ありません。
コードの品質の定義を求められたので、これを明確にしましょう。つまり、ソフトウェアの品質です。
ソフトウェア品質：これは1つの属性ではなく、多くの属性です。効率、変更可能性、可読性、正確性、堅牢性、包括性、使いやすさ、移植性など、相互に影響します。
コードジェネレーターは、ジェネレーターを作成した人よりも優れたコードを生成できません。
コードジェネレーターでの私の経験は、それらは問題ないということです生成されたコードを編集する必要がない限り。あなたがそのルールを守ることができるなら、あなたは行ってもいいです。つまり、システムのその部分を確実かつ迅速に確実に再生成し、必要に応じて自動的に機能を追加できます。私はそれが品質を数えることができると思います。
私はかつて、1人のプログラマーが1日に何行ものコードを生成でき、コードジェネレーターを使用すると数千行も生成できるというコードジェネレーターの議論を聞いたことがあります。明らかにそれが私たちがジェネレータを使用している理由ではありません。
反対を主張します-興味深いアプリケーションを作成していると想定すると、コード生成によりコード品質が低下します。コード生成の性質は、大規模で複雑で醜いコードの束を継続的に生成するためにコード生成ツールに継続的に依存せずに対処するのが非常に困難になる、非常にクッキーカッター、誇張、仕様過剰のフレームワークに報います。これは優れたツールになる可能性がありますが、実際にはボックスの主要なツールであってはなりません。
自動コード生成とコード品質はある程度直交しており、必ずしも相関しているとは限りません。
コード生成は、特定の技術タスクを解決する方法にすぎません。それがコード品質の向上をもたらすかどうかは、あなたが何をしているかに依存します。
あなたの状況はコード生成の良い例であり、潜在的なエラーを早期にキャッチすることでコード品質を向上させます。
自動コード生成によってコード品質が低下する別の例を挙げましょう。それは万能のASP.NET Webフォームです。 UIコントロールの階層をHTMLマークアップに変換することにより、コードの自動生成を行います。
結論を導き出すために、自動化されたコード生成は、適切に使用するとコードの品質を向上させるのに役立ちます。
コードの生成は、コードquality自体には影響しません。コードconsistencyと同じくらいです。
生成されたコードは、生成のインスタンス間で一貫します。ジェネレーターが高品質のコードを生成するように設計されている場合、生成されたコードは一貫して高品質になります。ただし、コードジェネレーターが低品質のコードを出力する場合は、一貫して低品質のコードが生成されます。
コード生成は、コードの作成にも使用できますfaster。ただし、高速であっても良いというわけではありません...品質の悪いコードをより早く入手できるということです。
コード生成は、次の場合に適しています。
- 生成されたコードは編集されるべきではありません
- コードジェネレーターは、必要なことを実行するのに十分な柔軟性を提供します
- コードジェネレーターへの入力言語は、他の方法で記述する必要がある言語よりも優れています（つまり、DRY）。
- コードジェネレーターは、たとえ冗長であっても、心配する必要のない信頼性の高いコードを作成します。
これらが当てはまる場合、品質を考慮する必要があるコードは、ジェネレーターに入力されるコードです。
品質の簡単な尺度は、要件の一般的な変更に対して、どれだけ手動で編集する必要があるかです。少ないほど良い。
[〜＃〜] dry [〜＃〜] によるコード品質の向上（繰り返さないでください）。
コード生成ルールは1回記述されます。生成されたコードのすべてのインスタンスに対してハードコーディングされているわけではないため、わずかな変更を加えてコンテンツをコピー/貼り付けする際の人的エラーの可能性を減らします。
私はあなたが特定の社内使用のためにハンドロールされたプロプライエタリなコードジェネレーターを意味していると思います。しかし、ここに行きます：
ブループリントのノードグラフは、生成するGLSL/HLSLコードよりも維持しやすく、エラーが発生しにくい（そして、そうでなければ手書きする必要があった）ことは非常に議論の余地があると思います。
また、グラフを変更すると最終結果がどのように表示されるかをリアルタイムで視覚的にフィードバックできるので、新しいシェーダーを考え出す方がはるかに生産的です。 GLSL/HLSLコードの代わりにこの方法でノードグラフで表される何千ものシェーダーを維持することを私は間違いなく望んでおり、実際にはブループリントを使用するよりもGLSL/HLSLを書くことに慣れています。 「ビジュアル言語」は、多くの場合、たとえば、少なくともAFAIKのシェーダーをクラッシュさせます（私は確かにブループリントの専門家ではありません）。
保守する「コード」さえありません。グラフ内にノードを配置し、それらの間にリンクを描くだけで、シェーダーコードが生成されます。 「ご存知のとおり、これはブループリントを使用する代わりにGLSLコードで記述しただけの方がはるかに簡単で、はるかに多くの自由時間が得られるでしょう。 "おそらくない。
とはいえ、人生をより困難にする独自のコードジェネレーターの共有に遭遇したため、生成されたコードの言語でコードを記述することよりも、非常に限られた利点しかないこの愚かなメタ言語を学びました。私にとって、シテであるコード生成の明確な兆候は、少量のボイラープレートを削減するだけで、実際にはバグの可能性を削減するものではありません。元の言語にはなかったバグを引き起こす新しい方法が実際に導入されている場合、それは特にシテです。しかし、上記のようなコード生成の場合には、生産性の向上が非常に大きく、細心の注意を払って膨大な時間を費やすことになるため、誰もそれを使用して振り返ることはありません。
私にとって、Epicチームのブループリントの独自開発については、一般に向けられている多くの余分なプログラミング言語よりも、新しいものはほとんどありません。
あなたの場合、品質は少し向上するかもしれませんが、開発時間は大幅に短縮されます。時々、生成されたコードは不安定でぎこちない、またはまったくひどいです。これらの場合、生成されたコードは品質を低下させ、プロジェクトにテスト/修正/回帰テスト時間を追加する可能性があります。また、一部のタスクは複雑すぎて簡単に生成できません。ジェネレーターは、それ自体が完全に別のシステムになります（おそらくメインプロジェクトより大きく、複雑になります）。
コードジェネレーターは問題ありませんが、注意してください。
私は以前、コード生成に大きく依存する店で働いていました。私の考えでは、プロジェクトのコードは非常に統一されています。その点で、品質はまあまあでした。
ただし、すべてがジェネレーターを通過する必要があるためにカスタムコードの作成が許可されなくなった場合、プログラマーであるというエッジの一部を失うと思います。
確かに、これはダブルエッジソードのトピックだと思います。はい、ジェネレーターはエラーを減らし、コード標準を増やすので素晴らしいですが、手を汚さずにジェネレーターに依存しているため、プログラマーの一部を馬鹿にしています。
ちょうど私の2セント。
マーティンの回答に加えて、レコードごとに作業する場合、SQLコード生成は非常に優れていると付け加えます（select * from tab1 where tab1.pkcolumn =：parameter、update tab1 set [any number of columns] where tab1.pkcolumn =：parameter、etc）。そして、生成する必要のあるSQLが実際に反復的であるため、そのシナリオではORMが輝きます。
私の主な心配事はメタクエリです。ORMがなんらかのアルゴリズムを使用してSQLに変換するオブジェクトのプロパティに対するクエリです。非常に類似したメタクエリは、完全に異なるSQLを生成する可能性があります-この生成されたSQLがパフォーマンスを発揮するという保証はありません。
データ収集を効果的に実行するためのクエリプランに変換される別の言語（SQL）に変換されるメタクエリ言語。そして生成された結果はオブジェクトでなければならないので、ORMは影響を受けるオブジェクトをインスタンス化する必要があります-メタクエリ自体によってもたらされなかったオブジェクトの属性を満たすためにクエリの別の雨を引き起こす可能性があります...
生成されたコードを編集する必要がない（できれば、見る必要がない）限り、コード生成は問題ないと言う人に完全に同意します。
生成されたコードが手書きとほぼ同じ行数であることを受け入れることができる場合andバグがないと言える場合は、バグを含む可能性のある行の数が減少しています。エルゴ、コードの品質は向上しているはずです。
補遺：もちろん、実行時間などの他の要因が役割を果たす場合があります。
個人的には、かなりの数のコードジェネレーターを作成しましたが、最初のアプローチとしては使用していません。
既存のコードに繰り返しパターンがあることに気付いたのはいつだったので、ジェネレーターは新しいが類似したコードを追加するときに既存のコードをいくつか使用し、その可変部分をパラメーター化しました。
その点で、私の生成されたコードは既存の手書きのコードとほとんど同じです（ただし、視覚的に配置され、より均一になる傾向があることを除きます。
ところで、ツールとそのメンテナの詳細を含め、コードが生成されたことを示す開始/終了コメントを挿入することをお勧めします。