自動コードジェネレーター[終了]


13

私の同僚の1人は、自動コードジェネレーターを使用するのが好きです。自動コードジェネレーターは、文書化が不十分で保守が非常に難しい大量のコードを作成します。

コードジェネレーターを使用するコストは、作成までの時間を短縮するために、メンテナンスの手間をかける価値がありますか?

回答:


10

それを言い換えましょう:

優れた自動コードジェネレーターのコストは価値がありますか?

はい。

他のすべての人のためにより多くの作業を作成する貧弱な自動コードジェネレーターのコストは価値がありますか?

絶対違う。貧弱なコードの言い訳はありません。誰かが賢くなり、自動コード生成を使用したい場合は、生成されたコードが適切なコードであることを確認するのに時間がかかるはずです。それ以外の場合、それのポイントは何ですか?それはただ、お金を無駄にしないだけであり、コードの生産に関しては、そのお金はそれを書いた開発者にやめるべきです。


16
2番目の点には同意しません。生成されたコードは、パフォーマンス/セキュリティまたはその他の問題を発生させずに機能するように十分である必要があります。生成されたコードを手作業で保守することは絶対にすべきではないので、通常のコーディング標準に従っていなくてもかまいません。
ヒラ

4
あなたが同意しなくても大丈夫です。ただし、コードジェネレーターを作成するのに時間がかかる場合は、生成されたコードをきれいにするのに時間をかけませんか?一度生成されると、誰がそれを作ったのか、どのように作られたのか、それが他のすべての部分と同じくらい読みやすい/維持できない限り、その意図はわかりません。場合によっては、発電機は本格的な完成品ではなく、出発点を作成するためだけに存在します。
ウィーティーズ

1
また、コードの生成がビルドの一部である場合(つまり、ビルドごとに再生成される場合)、「美しい」コードを生成することはあまり意味がありません。しかし、コードを1回生成するだけで、それだけの場合は別の話になります。
ディーンハーディング

5
ヒラ、生成されたコードを手で維持することは絶対にすべきではありませんが、新しい/変化する要件のためにそのコードを変更する必要がある日が来たら、ジェネレーターに必要な変更を簡単に加えることができるように、コードを明確かつわかりやすくする必要があります、そして再生成します。
Carson63000

6
生成されたコードはメンテナンスのために十分である必要はありませんが、デバッグおよび検証のために十分に理解できる必要があります。
Huperniketes

23

ジェネレーターによって生成されたコードは、決して手作業で保守しないでください。変更する必要がある場合は、ジェネレーターおよび/またはその設定を微調整して、再度実行する必要があります。それを考慮すると、生成メカニズム自体が非常に明確である限り、結果のコードが理解不能で文書化されていなくてもかまいません。(コードが生成されるという事実、ジェネレーターがどこにあるか、どのように動作するかを必ず記録してください。)

アナロジー:コンピューターのプロセッサは常にマシンコードを実行していますが、高級言語とコンパイラを使用してそのマシンコードを作成する方法を知っている限り、それについて何も知る必要はありません。GCCがときどき劣ったマシンコードを生成することは聞いたことがありますが、完璧に機能する限り、誰も気にしません。データベース抽象化層は、DBエンジンで動作するSQLを生成しますが、抽象化層が明確で動作している限り、だれがそのSQLがどのように見えるかを気にしますか?

コードジェネレーターを適切に使用すると、作成だけでなく、メンテナンスコストも確実に節約できます。


4
問題は、ツールを持っているのは1人だけで、他の人は持っていないため、コードを手動で保守する必要があります。
マンブルズ

これは大金です。ソフトウェア開発者として、私たちのビジネスはコードです-どのようにそれを生成しても。
スティーブンエバーズ

12
@Davidは、ツールを持っている人が1人だけの場合、複数の人が関与するプロジェクトに使用すべきではありません。
マットオレニック

2
@Matt、正確に。ジェネレーターはプロジェクトの一部であり(ビルドスクリプトと同等)、バージョン管理または同様の中央リポジトリに保存する必要があります。
ジョナスプラッカ

2
@SnOrfus:私たちのビジネスは、人々が喜んで使用して購入できる実用的な製品を生産することだと思います。それが私たちの給料の源です。コードは単なる媒体です。
ジョナスプラッカ

6

コードジェネレーターは、コンパイラの一種です。コンパイラの出力がどれだけきれいかを心配する必要はありません。ソースコードを操作するだけです。それを使用してから出力を手動で変更することは、人間が理解できる形式で最初からそれを書くよりも難しい場合が多く、多くの作業なしでコードジェネレーターを再び使用できないことを意味します。同じ不可解なコードに対する同じ変更を正確に。

したがって、それらがビルドプロセスの一部であり、そのように文書化されている場合は問題ありません。ジェネレーターへの入力はソースコードであり、生成されるものは中間結果であり、混乱することはありません。

ただし、誰かがそれを使用して、ソースとして使用されるはずの理解できないコードを生成する場合、その人は悪いコードを生成します。その人が機械的に悪いコードを作っているのか、それとも手作業で作っているのかは関係ありません。それでもコードは悪いので、品質の問題はまだあります。

したがって、これを他の開発者が角を切り、悪いコードを書くように扱う必要があります。私はあなたがあなたの店でそれをどのように扱うのか分かりません。


3

他の回答のコメントから、コードジェネレータ自体ではなく、チームの標準について質問しているようです。

コード生成ツールをプロジェクトに含める必要があり、(適切な場合)ビルドプロセスの一部である必要があります。例として、ビルド時にデータベースオブジェクトからクラスを生成したSubsonic 2.2を使用するチームがあります。

これを行うexeは、プロジェクトの一部としてSVNにチェックインされるため、チームの新しいメンバーは、svnから新しいプロジェクトを取得し、これらすべてのデータベースクラスがどこから来たのかを把握しなくてもすぐにビルドできます(この例では、生成されたコードをsvnに含めないでください)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.