私の質問は簡単に思えますが、見た目より少し理論的です。プログラミング言語を使用せずに実行できるコード生成ソフトウェアまたはアプリケーション構築ソフトウェアがあります。Intelliunの VE Server や VE Designer などのアプリケーションは、このタスクを実行する必要があります。私の質問は、実際には、開発チームとソースコードの進化プロセスを持つことと比較して、この種のツールの実際の節約量を誰かに追跡してもらうことです.
VE デザイナーの特定の例では、アプリケーションはデザイナーから実行され、そのコードは表示されません。VE サーバーでアプリを実行するだけです。すべてのコードは、XML 内部コマンドのように見えます。
その時間をどのように測定するかによって異なります。
すべてのコードを手動で入力するグループと、コード ジェネレーターを使用するグループの 2 つのコントロール グループを比較すると、コード ジェネレーターを使用するグループの方が時間がかからないことは間違いありません。もちろん、ジェネレーターをどこまで使いたいかにもよりますが、生成されたコードの割合が上がるにつれて、手動入力がますます悪化していることは間違いありません。
私が気にかけている唯一のことは、そのコード ジェネレーターがどこから来て、その設計にどれだけの考慮が払われたかということです。
ウィザード/コード ジェネレーターが生成するコードを理解していないために触れたくない場合は、コード ジェネレーターに対してカウントする必要があります。
コード ジェネレーターによって不適切な設計が強制された場合は、コード ジェネレーターに対してカウントする必要があります。
コード ジェネレーターが非常に多くのクラスを吐き出して、何が起こっているのか誰も追跡できない場合は、コード ジェネレーターに対してカウントする必要があります。
コード ジェネレーターがあなたのメンテナンス ライフを地球上で地獄にするなら、それはコード ジェネレーターに対してカウントされるべきです。
可能であれば、自分のツールを理解して作成するという考えが好きです。他の人から提供されたウィザードは、問題を引き起こす可能性があります。それらの説明は、問題を反映する必要があります。
「コード ジェネレーターは悪いものですか?」という質問に対するいくつかの回答を参照することをお勧めします。'。質問自体は、コード ジェネレーターを使用する必要があるかどうかに関連していますが、多くの応答には、コード ジェネレーターの使用のマイナス面と、生成されたコードを実際の人間が確認/編集する必要がある方法についてのメモがあります。であること。これは常に当てはまるとは限らず、生成されたコードの品質に大きく依存します (結局のところ、本当に木こりになりたがっていて、キーボードの近くで許可されるべきではない、潜在的に恐ろしいプログラマーによって書かれたテンプレートを吐き出すだけです)。高品質のコードを生成している場合は、おそらく時間を節約できます。そうしないと、結果のリファクタリングに費やされる時間が、最初に実際にコードを書くのに費やされる時間と同じかそれ以上になる可能性があります。
私は個人的に、コード ジェネレーターとの結果がまちまちでした。たとえば、Visual Studio (具体的にはフォーム デザイナー) によって自動的に生成されたコードは、悪夢のように通り抜けることができ、特別な動作を突然実装する必要がある場合、フォームが期待どおりに見えなかったり動作したりしなくなり、通常はコストがかかります。より多くの時間。クラスをレイアウトし、組み込みの編集可能なテンプレートを使用してすべてのメソッド シグネチャなどを構築できるため、Eclipse のものが好きです (完全に自動化されたコード生成ツールではありません)。自分のせい）。一般的なフレームは、それが良いと思って、あなたが望んでいることを正確に実行するものを取得するよりもはるかに便利な時間の節約になります (たとえば、車のシャーシが与えられます) 。完全に組み立てられた、右にしか曲がらない 3 つの車輪のみの車)。
私はコード生成 (つまり、コードの 3 分の 2 ほどを自動的に吐き出して、残りをプログラマーが埋めるプログラム) を 2 つの状況で使用しました。自分で書いたツール。どちらの状況でも、結果がまちまちであることがわかりました。
1) その時点で必要なものを開発する時間を節約できました。
2）しかし、それは私たちを私たちの設計に閉じ込め、コードの柔軟性を大幅に低下させました. これにより、簡単に変更できない多くの重複したロジックが作成されました。
私が知る限り、例外はあると思いますが、人間が後で変更しなければならないコードを出力するコード生成ツールを使用すると、長期的には時間を失うことになります。基本的に、それがコンパイラのように機能せず、簡単にリファクタリングできない場合は、おそらく上記のトレードオフが生じるでしょう。
「コード ジェネレーター」と「プログラミング言語」の間に明確な区別はありません。ソフトウェアを使用してコードを生成する場合は、詳細を理解していなくてもプログラミングを行っています。C++、Java、および C# は、低レベル言語にコンパイルされるという意味で「コード ジェネレーター」であり、プログラマーがそうするように選択した場合、これらの低レベル言語自体を手作業でコーディングできます。多くのプログラミング言語はマクロ ツールとして始まります。XML ベースのツールを使用してスクリプトを作成しても、同じスクリプトが Perl、Python、または Ruby で作成された場合よりも「プログラム」であるとは言えません。
一般的に言えば、ソフトウェアを使用して反復性の高いコードを生成することで時間を節約することは良い考えです。潜在的な欠点は、プラットフォームに閉じ込められる可能性があることです。つまり、コード ジェネレーターが提供する機能に制限されます。コード ジェネレーター (またはプログラミング言語) を使用する価値があるかどうかは、特定の問題に対してどれだけ効果的であるかによって決まります。
XML や HTML などの一部の形式は死んだ「データ」であり、C++ や Python などのその他の形式は「コード」であると考える心の罠にはまらないでください。データとコードは交換可能です。HTML の「コード」の例が必要ですか? 次の点を考慮してください。
HTML は宣言型言語です。その中で、「ここに段落があり、ここに見出しがある」などの方法で、存在するものを指定します。Python やその他のプログラミング言語には、「x と y を追加し、x をメモリに書き込む」などを指定する命令部分があります。
ただし、この関係を逆にすることはできます。HTML の場合、ブラウザーを介してフィードするときに必須になります。「これらのプロパティを持つ段落です」は、Firefox によって「これらのパラメーターを使用してテキストの本文をレンダリングする」と解釈されます。ファイルとしての HTML は単なるデッド データですが、インタプリタのコンテキストではライブ コードになります。同じことが Python で逆に起こります。実行中、Python 命令はインタープリターへのディレクティブになりますが、Python ファイル自体は単なるデッド テキストです。ある意味では、Python プログラムは、Python インタープリターを介して実行するまで、データ形式の潜在的な命令のコレクションとしてそこに置かれます。まったく同じように、HTML は、ブラウザーがそれを処理する時が来るまで、ファイル内のデータとして存在します。
XML はデータ形式ですが、命令はデータの一種です。XML を使用して、算術演算や関数呼び出しなどの命令ステートメントを含めることができます。その XML をデータとして解釈するかコードとして解釈するかは、コンテキストに完全に依存します。ある意味では、すべてのコンピューター データはデータであると同時にコードでもあります。データとコードの区別は人間の慣習であり、コンピューター固有の現実ではありません。
編集: ここでは、プロセッサ アーキテクチャ レベルでは、コードとデータの間に非常に具体的な区別があることが多いことを認めるべきだと思います。コードは、プロセッサ コアを介して供給され、マシンの状態を変更するものです。一般的なアーキテクチャでは、実行を待機しているビットを、実行可能コードを表さない他のデータとは別のメモリ領域に保持します。しかし、通訳について話し始めると、この区別はすぐに曖昧になります。