コード生成はコード品質を向上させますか？

コード生成を主張して、コード品質を向上させる方法の例を探しています。コード生成の意味を明確にするために、私のプロジェクトについてのみ説明します。

XMLファイルを使用してデータベーススキーマ内のエンティティの関係を記述するため、エンティティの追加、削除、変更に使用できるORMフレームワークとHTMLフォームの生成に役立ちます。

私の考えでは、人的エラーが減るため、コードの品質が向上します。何かが正しく実装されていない場合、モデル内で破損します。これは、より多くの生成コードが破損するため、エラーがより早く表示される可能性があるためです。

コード品質の定義を求められたので、これを明確にしましょう。つまり、ソフトウェア品質です。

ソフトウェア品質：相互に影響するのは、1つの属性ではなく、効率、変更可能性、読みやすさ、正確さ、堅牢性、理解可能性、使いやすさ、移植性などの多くです。

コードジェネレーターは、ジェネレーターを作成した人よりも優れたコードを生成できません。

コードジェネレーターでの私の経験では、生成されたコードを編集する必要がない限りは問題ありません。もしあなたがそのルールを守れるなら、あなたは行ってもいいです。つまり、システムのその部分を信頼性と速度で確実に再生成でき、必要に応じて機能を自動的に追加できます。それが品質にとって重要だと思います。

私はかつて、1人のプログラマが1日に非常に多くのコード行を生成でき、コードジェネレーターを使用すると数千行を生成できるというコードジェネレーターの議論を聞いたことがあります。明らかに、それがジェネレーターを使用している理由ではありません。

私は反対を主張します-あなたが興味深いアプリケーションを書いていると仮定すると、コード生成はコード品質を低下させます。コード生成の性質は、コード生成ツールに継続的に依存せずに、より大きく、より複雑でいコードバンチを継続的に生成しなければ対処が非常に困難になる、非常にクッキーカッターで、誇張され、過剰に指定されたフレームワークに報います。これは優れたツールですが、ボックスの主要なツールではありません。

自動化されたコード生成とコード品質は多少直交しており、必ずしも相関しているとは限りません。

コード生成は、特定の技術的なタスクを解決するための単なる方法です。結果としてコードの品質が非常に向上するかどうかは、あなたが何をしているかに依存します。

あなたの状況は、潜在的なエラーを早期にキャッチアップすることでコード品質を向上させるコード生成の良い例です。

コードの自動生成によりコードの品質が低下する場合の別の例を示します。万能なASP.NET WebFormsがリリースされました。UIコントロールの階層をHTMLマークアップに変換することにより、コード生成を自動化します。

結論を出すために、自動コード生成は、適切に使用するとコードの品質を向上させるのに役立ちます。

コード生成は、コードの一貫性と同様に、コードの品質自体には影響しません。

生成されたコードは、生成のインスタンス間で一貫しています。ジェネレータが高品質のコードを出力するように設計されている場合、生成されたコードは一貫して高品質になります。ただし、コードジェネレーターが質の悪いコードを出力すると、一貫して質の悪いコードが生成されます。

コード生成は、コードをより速くビルドするためにも使用できます。ただし、高速であっても良いというわけではありません...品質の悪いコードをより速く取得できるということです。

コード生成は次の場合に適しています。

• 生成されたコードは編集されることになっていない
• コードジェネレーターは、必要なことを行うのに十分な柔軟性を提供します
• コードジェネレーターへの入力言語は、他の方法で記述する必要があるものよりも優れています（つまり、DRY）
• コードジェネレーターは、たとえ冗長であっても心配する必要のない信頼性の高いコードを作成します

これらの場合、品質を考慮する必要があるコードは、ジェネレーターに入力されるコードです。

品質の簡単な尺度は、要件の一般的な変更の場合、手動で編集する必要がある量です。少ないほど良い。

DRYによるコード品質の向上（繰り返しはしないでください）。

コード生成ルールは1回作成されます。生成されたコードのすべてのインスタンスに対してハードコーディングされていないため、わずかな変更を加えてコンテンツをコピー/貼り付けする際の人的エラーの可能性を減らします。

マシンコード以外のコードジェネレーターはコードジェネレーターであるため、特定の社内使用のためにハンドロールされた独自のコードジェネレーターを意味すると想定しています。しかし、ここに行きます：

Blueprintsのノードグラフは、生成するGLSL / HLSLコードよりも保守が容易であり、エラーが発生する可能性が非常に低いと考えられます（そうでなければ手書きする必要があります）。

また、グラフを変更すると最終結果がどのように見えるかをリアルタイムで視覚的に確認できるため、新しいシェーダーを作成する方がはるかに生産的です。GLSL / HLSLコードの代わりに、この方法でノードグラフで表される数千のシェーダーを維持することは間違いなく好みであり、実際には、ブループリントを使用するよりもGLSL / HLSLの作成に精通しています。「視覚的言語」は、多くの場合純粋な機能的なスタイルを使用して合理的な制約を課すため、おそらくすぐにキャッチする可能性のある小さな視覚的なグリッチに加えて、大きなバグのように引き起こすことは実際には不可能だと思います少なくとも私の知る限り、シェーダーをクラッシュさせます（私は明らかにブループリントの専門家ではありません）。

もう維持する「コード」さえありません。グラフ内にノードを配置し、それらの間にリンクを描くだけで、シェーダーコードが生成されます。誰がこのようなものを維持し、「あなたが知っている、これはブループリントを使用する代わりにGLSLコードで書かれていれば、私の人生はずっと楽になるでしょう。

そうは言っても、私は人生をより難しくしたプロプライエタリなコードジェネレーターのシェアに出くわし、生成されたコードの言語でコードを書くことよりも、もしあったとしても非常に限られた利点しか持たないこの愚かなメタ言語を学びました。私にとっては、シテであるコード生成の証拠となる兆候は、少量の定型文を減らす以上のことはせず、実際にはバグの可能性を減らすことはありません。元の言語にはなかったバグを引き起こす新しい方法が実際に導入された場合、それは特にシテであることがわかります。しかし、上記のようなコード生成の場合、生産性の向上が非常に大きく、膨大な時間を要する綿密なものをレンダリングするのにわずかな費用がかかるため、誰もそれを使用して振り返ることはありません。

私にとって、ブループリントのプロプライエタリ開発には、多くの余分なプログラミング言語が一般向けに作られており、テーブルに新しいものをほとんどもたらさないというよりも、エピックチームの間でより正当な議論があります。

あなたの場合、品質は少し向上するかもしれませんが、開発時間は大幅に短縮されます。生成されたコードは、不安定で、扱いにくい、または単にひどい場合があります。これらの場合、生成されたコードは品質を低下させ、プロジェクトにテスト/修正/回帰テストの時間を追加する可能性があります。そして、いくつかのタスクは複雑すぎて簡単に生成できません-ジェネレーターはそれ自体が完全に独立したシステムになります（メインプロジェクトよりも大きくて複雑になる可能性があります）。

コードジェネレーターは問題ありませんが、注意してください！

私は以前、コード生成に大きく依存するショップで働いていました。私の考えでは、プロジェクトのコードは非常に統一されていました。その点で、品質は良好でした。

ただし、すべてがジェネレーターを通過する必要があるため、カスタムコードの記述が許可されなくなった場合、プログラマーとしての優位性が失われると思います。

ですから、これは確かに両刃の剣のトピックだと思います。はい、ジェネレーターはエラーを減らし、コード標準を高めるので素晴らしいですが、プログラマーの一部を馬鹿にします。なぜなら、手を汚さずにジェネレーターに依存しているからです。

ちょうど私の2セント。

マーティンの答えに加えて、レコードごとに作業する場合はSQLコード生成が非常に優れていることを追加します（tab1.pkcolumn =：parameterを選択*からtab1 set [any number of columns]を更新tab1.pkcolumn =：parameterなど）。生成する必要のあるSQLは実際に反復的であるため、ORMはそのシナリオで威力を発揮します。

私の主な心配はメタクエリです。オブジェクトのプロパティに対するクエリであり、ORMはどのようなアルゴリズムを使用してもSQLに変換します。非常に類似したメタクエリは、完全に異なるSQLを生成する可能性があり、この生成されたSQLがパフォーマンスに優れているという保証はありません。

データ収集を効果的に実行するためにクエリプランに変換する別の言語（SQL）に変換するメタクエリ言語。そして、生成された結果はオブジェクトでなければならないので、ORMは影響を受けるオブジェクトをインスタンス化する必要があります-メタクエリ自体によってもたらされていないオブジェクトの属性を埋めるためにクエリの別の雨を引き起こすことができます...

生成されたコードを編集する必要がない（できれば、見る必要がない）限り、コード生成は問題ないという意見に完全に同意します。

生成されたコードが手書きとほぼ同じ行数であり、バグがないと言える場合、バグを含む可能性のある行の数は減少しています。エルゴ、コード品質が向上するはずです。

補遺：もちろん、実行時間などの他の要因が役割を果たす可能性があります。

個人的には、かなりの数のコードジェネレーターを作成しましたが、最初のアプローチとしては作成していません。

既存のコードに繰り返しパターンがあることに気付いたのはいつでもあったので、新しいジェネレーターに似たコードを追加するときにジェネレーターが既存のコードを取得し、その変数の一部をパラメーター化しました。

その点で、生成されたコードは既存の手書きコードとほとんど同じです（視覚的にレイアウトされ、より均一になる傾向があることを除いて、見なければならない場合は読みやすくなります）。

ところで、ツールとそのメンテナーの詳細など、コードが生成されたことを示す開始/終了コメントの挿入を推奨します。