Sind Code-Generatoren schlecht?

https://stackoverflow.com/questions/202871

03-07-2019
|

Frage

Ich verwende MyGeneration zusammen mit nHibernate die grundlegenden POCO Objekte und XML-Mapping-Dateien zu erstellen. Ich habe einige Leute sagen hören, sie denken, Code-Generatoren sind keine gute Idee. Wie ist die gegenwärtige beste Denken? Ist es nur, dass die Codegenerierung ist schlecht, wenn es Tausende von Zeilen nicht verständlich Code generiert?

Lösung

-Code durch einen Code-Generator erzeugt sollte nicht (als Verallgemeinerung) in einer Situation verwendet werden, wo es anschließend durch menschliche Eingriffe bearbeitet wird. Einige Systeme, wie die Assistenten auf verschiedenen Inkarnationen von Visual C ++ Code generiert, der Programmierer wurde dann von Hand bearbeiten erwartet. Das war nicht beliebt, da es Entwickler erforderlich, um den generierten Code auseinander zu nehmen, ihn zu verstehen und Änderungen vornehmen. Es bedeutete auch, dass der Erzeugungsprozess ein Schuss war.

generierte Code soll in separaten Dateien von anderem Code im System lebt und nur vom Generator erzeugt werden. Der generierte Code Code sollte klar als solche gekennzeichnet werden, um anzuzeigen, dass die Menschen es nicht ändern sollten. Ich habe Gelegenheit gehabt, schon einige Code-Generation-Systeme von einer Art zu tun oder zu einem anderen und alle von dem Code erzeugt, so hat so etwas wie dies in der Präambel:

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

Code-Generierung in Aktion zum Thema ziemlich gutes Buch.

Andere Tipps

Code-Generatoren sind groß, schlechter Code ist schlecht.

Die meisten anderen Antworten auf dieser Seite sind entlang der Linien von „Nein, weil oft der generierte Code ist nicht sehr gut.“

Dies ist eine schlechte Antwort, weil:

1) Generatoren sind Werkzeuge wie alles andere - wenn man sie missbrauchen, nicht das Werkzeug schuld.

2) Entwickler neigen dazu, stolz auf ihre Fähigkeit, große Code einmal zu schreiben, aber Sie nicht Code-Generatoren für eine off-Projekte verwendet werden.

Wir verwenden ein Code Generation System für die Persistenz in allen Java-Projekten und haben Tausende von generierten Klassen in der Produktion.

Als Manager Ich liebe sie, weil:

1) Zuverlässigkeit: Es gibt keine wesentlichen verbleibenden Fehler in diesem Code. Es wurde so ausgiebig getestet und verfeinert im Laufe der Jahre als beim Debuggen ich nie über die Persistenz-Schicht sorgen.

2) Standardisierung:. Jeder Entwickler-Code ist in dieser Hinsicht identisch, so gibt es viel weniger für einen Kerl ist zu lernen, wenn Sie ein neues Projekt von einem Mitarbeiter Kommissionierung bis

3) Evolution. Wenn wir einen besseren Weg finden, Dinge zu tun, wir die Vorlagen schnell und konsequent Update 1000 von Klassen aktualisieren

4) Revolution: Wenn wir zu einem anderen Persistenz-System in Zukunft schalen dann die Tatsache, dass jede einzelne persistente Klasse eine exakt gleiche API hat macht meine Arbeit viel einfacher

5) Produktivität: Es ist nur ein paar Klicks ein persistentes Objektsystem von Metadaten zu bauen - das Tausend von langweiligen Entwicklern Stunden spart

Code-Generierung ist wie ein Compiler - auf individuellem Einzelfall könnten Sie in der Lage sein, besser optimierte Assembler-Sprache zu schreiben, aber über eine große Anzahl von Projekten würden Sie lieber den Compiler es das Richtige für Sie zu tun haben

Wir verwenden einen einfachen Trick, um sicherzustellen, dass Klassen können immer ohne Verlust Anpassungen regeneriert werden: jede generierte Klasse abstrakt ist. Dann erstreckt sich der Entwickler es mit einer konkreten Klasse, fügt die benutzerdefinierte Geschäftslogik und überschreibt alle Basisklasse Methoden will er von der Norm abweichen. Wenn es eine Änderung in Metadaten ist er die abstrakte Klasse jederzeit regenerieren kann, und wenn das neue Modell seine konkrete Klasse bricht der Compiler ihn wissen lassen.

Das größte Problem, das ich mit Code-Generatoren gehabt haben ist während der Wartung. Wenn Sie den generierten Code ändern und dann eine Änderung an Ihrem Schema oder eine Vorlage machen und versuchen, sich zu regenerieren können Sie Probleme haben.

Ein Problem ist, wenn das Werkzeug nicht erlaubt, Sie Änderungen schützen Sie den geänderten Code gemacht haben, dann werden Ihre Änderungen überschrieben.

Ein weiteres Problem, das ich gesehen habe, vor allem mit Code-Generatoren in RSA für Web-Services, wenn Sie den generierten Code ändern zu viel der Generator wird sich beschweren, dass ein Konflikt ist und sich weigern, den Code zu regenerieren. Dies kann etwas so einfach geschehen, wie den Typ einer Variablen zu ändern. Dann sind Sie stecken Sie den Code in ein anderes Projekt zu erzeugen und die Ergebnisse zurück in die Original-Code zusammenführen.

Code-Generatoren können ein Segen für die Produktivität, aber es gibt ein paar Dinge zu suchen:

Lassen Sie sich so, wie Sie arbeiten wollen arbeiten.

Wenn Sie Ihren nicht-generierten Code biegen, um den generierten Code passen, dann sollten Sie vielleicht einen anderen Ansatz wählen.

Ausführen als Teil Ihrer regelmäßigen bauen.

Die Ausgabe sollte zu einem Zwischenverzeichnis generiert werden und nicht in der Quellcodeverwaltung überprüft werden. Die Eingabe in die Quellcodeverwaltung werden müssen, jedoch eingecheckt.

Nein installieren

Idealerweise Sie das Tool überprüfen in der Quellcodeverwaltung, auch. Die Dinge Leute installieren, wenn eine neue Maschine zu bauen Vorbereitung ist eine schlechte Nachricht. Zum Beispiel, wenn Sie Zweig, möchten Sie die Werkzeuge mit dem Code-Version können.

Wenn Sie müssen, ein einziges Skript, das eine saubere Maschine mit einer Kopie des Quellbaums nehmen, und die Maschine nach Bedarf konfigurieren. Vollautomatische, bitte.

Keine Bearbeitung Ausgang

Sie sollten nicht die Ausgabe zu bearbeiten. Wenn die Ausgabe nicht sinnvoll genug ist, um wie sie ist, dann wird das Werkzeug nicht für Sie arbeiten.

Auch sollte der Ausgang klar sagen, dass es sich um eine generierte Datei ist & sollte nicht bearbeitet werden.

Lesbare Ausgang

Die Ausgabe sollte gut geschrieben und formatiert werden. Sie wollen in der Lage, den Ausgang zu öffnen und es ohne viel Mühe lesen.

#line

Viele Sprachen unterstützen so etwas wie eine #line Richtlinie, die Sie den Inhalt der Ausgabe zurück zum Eingang Karte lässt, zum Beispiel, wenn Compiler produziert Fehlermeldungen oder wenn in dem Debugger zu treten. Dies kann nützlich sein, aber es kann auch lästig sein, es sei denn, wirklich gut gemacht, so dass es keine Anforderung.

Meine Haltung ist, dass Code-Generatoren sind nicht schlecht, aber viele Verwendungen von ihnen sind.

Wenn Sie einen Code-Generator für Zeitersparnis verwenden, die guten Code schreibt, dann groß, aber oft nicht optimiert ist, oder fügt eine Menge Aufwand, in den Fällen, ich denke, dass es schlecht ist.

Code-Generierung können Sie einige Trauer verursachen, wenn Sie Verhalten wie in Ihren Klassen mischen. Eine ebenso produktive Alternative könnte sein, Attribute / Anmerkungen und Runtime-Reflexion.

Compiler sind Code-Generatoren, so dass sie nicht von Natur aus schlecht, wenn Sie nur in rohen Maschinencode programmieren möchten.

Ich glaube jedoch, dass die Code-Generatoren immer vollständig den generierten Code kapseln. D. h Sie sollten nie haben den generierten Code von Hand zu ändern, eine Änderung durch Modifizieren der Eingabe in den Generator und regenerieren den Code getan werden sollte.

Wenn sie ein Mainframe-COBOL-Code-Generator, Fran Tarkenton Sie versucht dann zu verkaufen, absolut ja!

Ich habe ein paar Code-Generatoren, bevor geschrieben - und um ehrlich zu sein sie mehr als einmal meinen Hintern gerettet

Wenn Sie eine klar definierte Aufgabe haben - Sammlung - Benutzerkontrolle Design, können Sie einen Code-Generator verwenden, um die Grundlagen für Sie zu bauen, so dass Sie Ihre Zeit als Entwickler, um effektiver das komplexe Material in den Bau verwendet werden, nachdem alle, der wirklich will, 300+ öffentliches Eigentum Erklärungen und variable instatiations schreiben? Ich würde eher in die Business-Logik stecken als alle sinnlosen sich wiederholende Aufgaben.

Der Fehler, den viele Leute machen, wenn die Codegenerierung verwendet, ist den generierten Code zu bearbeiten. Wenn Sie daran denken, dass, wenn Sie glauben, wie Sie den Code bearbeiten müssen, müssen Sie den Code tatsächlich Generation Werkzeug zu bearbeiten Sie ihn ein Segen für die Produktivität ist. Wenn Sie ständig den Code kämpfen, die erzeugt wird es kostet Produktivität Ende geht.

Die besten Codegeneratoren ich gefunden habe, sind diejenigen, die es Ihnen ermöglichen, die Vorlagen zu bearbeiten, die den Code zu generieren. Ich mag Codesmith aus diesem Grund wirklich, weil es Template-basierte und die Vorlagen sind leicht zu bearbeiten. Wenn Sie feststellen, gibt es einen Mangel in dem Code, der generiert wird, müssen Sie nur die Vorlage bearbeiten und Ihren Code regenerieren und Sie sind immer gut danach.

Die andere Sache, die ich gefunden habe, ist, dass viele Code-Generatoren sind nicht super einfach mit einem Quellensteuersystem zu verwenden. Die Art, wie wir um diese bekommen haben, ist in den Vorlagen prüfen , anstatt den Code und das einzige, was wir in die Quellcodeverwaltung überprüfen, die erzeugt wird, ist eine kompilierte Version des generierten Codes (DLL-Dateien, meist ). Das spart Ihnen eine Menge Ärger, weil Sie nur lieber ein paar DLLs einchecken müssen als möglicherweise Hunderte von generierten Dateien.

Unser aktuelles Projekt macht intensiven Gebrauch eines Codegenerators. Das bedeutet, dass ich gesehen habe, sowohl die „offensichtlich“ Vorteile der Code zum ersten Mal zu erzeugen - kein Coder Fehler, keine Tippfehler, eine bessere Einhaltung einer Standardcodierung Stil - und nach ein paar Monaten in den Wartungsmodus, die unerwartete Nachteile. Unser Code-Generator hat, in der Tat, verbessern unsere Qualität Codebasis zunächst. Wir haben darauf geachtet, dass es voll automatisiert und integriert mit unseren automatisierten Builds. Allerdings würde ich sagen, dass:

(1) Ein Code-Generator eine Krücke sein. Wir haben mehr riesigen, hässliche Flecke von harten pflegenden Code in unserem System jetzt, weil an einem Punkt in der Vergangenheit war es einfacher, zwanzig neue Klassen in unsere Codegenerierung XML-Datei hinzufügen, als es die richtige Analyse und Klasse zu tun war, Refactoring.

(2) Ausnahmen von der Regel, die Sie töten. Wir verwenden den Code-Generator mehrere hundert Bildschirm und Business Object-Klassen zu erstellen. Zunächst erzwungen wir einen Standard auf, welche Methoden in einer Klasse erscheinen könnte, aber wie alle Standards haben wir begonnen, Ausnahmen zu machen. Nun ist unsere Codegenerierung XML-Datei ein massives Monster, gefüllt mit Spezialfall-Schnipsel von Java-Code, der in ausgewählte Klassen eingeführt werden. Es ist fast unmöglich zu analysieren oder zu verstehen.

(3) Da so viel von unserem Code generiert wird, Wert aus einer Datenbank verwendet, ist es schwierig erwiesen, für Entwickler eine einheitliche Code-Basis auf den einzelnen Arbeitsstationen zu halten (da es mehrere Versionen der Datenbank sein kann). Debugging und Tracing durch die Software ist viel schwieriger, und Neulinge an dem Team viel länger den „Fluss“ des Codes, um herauszufinden, wegen der zusätzlichen Abstraktion und impliziter Beziehungen zwischen den Klassen. IDE kann nicht zwischen zwei Klassen holen Beziehungen, die über eine Code-generierten Klasse kommunizieren.

Das ist wahrscheinlich genug für heute. Ich denke, Codegeneratoren sind groß, als Teil eines einzelnen Toolkit Entwickler; ein Projekt machen Starten viel einfacher eine Reihe von Skripten, die Ihren Textvorschlag Code schreiben. Aber Codegeneratoren tun nicht machen Wartungsprobleme verschwinden.

In bestimmten (nicht viele) Fällen sind sie nützlich. Wie wenn Sie Klassen erzeugen, basierend auf Lookup-Typ-Daten in den Datenbanktabellen werden sollen.

Code-Generierung ist schlecht, wenn es Programmierung schwieriger (IE, schlecht generierten Code oder ein Alptraum in Sachen Wartung) macht, aber sie sind gut, wenn sie die Programmierung effizienter zu machen.

Sie wahrscheinlich erzeugen nicht immer optimal Code, sondern je nach Bedarf, können Sie feststellen, dass Entwickler Mann-Stunden gespeichert für ein paar kleineren Probleme machen entscheiden.

Alles, was gesagt, mein größtes Problem mit ORM-Code-Generatoren ist, dass die Wartung der generierte Code ein PITA, wenn die Schemaänderungen werden kann.

Code-Generatoren sind nicht schlecht, aber manchmal sind sie in Situationen verwendet werden, wenn eine andere Lösung besteht (dh eine Million Objekte instanziieren, wenn ein Array von Objekten besser geeignet gewesen wäre, und in ein paar Zeilen Code ausgeführt).

Die andere Situation ist, wenn sie schlecht falsch, oder codiert verwendet werden. Zu viele Menschen schwören Code-Generatoren, weil sie aufgrund von Fehlern schlechte Erfahrungen gemacht haben, oder deren Missverständnis, wie es richtig zu konfigurieren.

Aber an und für sich, Code-Generatoren sind nicht schlecht.

-Adam

Sie sind wie jedes andere Werkzeug. Einige geben bessere Ergebnisse als andere, aber es ist an den Benutzer zu wissen, wann sie zu benutzen oder nicht. Ein Hammer ist ein schreckliches Werkzeug, wenn Sie in einer Schraube Schraube versuchen.

Dies ist eine jener sehr strittigen Fragen. Ich persönlich denke, Code-Generatoren sind wirklich schlecht wegen des nicht optimierten Mists Code der meisten von ihnen löschen.

Allerdings ist die Frage wirklich eine, die nur Sie beantworten können. In vielen Organisationen ist die Entwicklungszeit wichtiger als die Ausführungsgeschwindigkeit Projekt oder sogar Wartbarkeit.

Wir verwenden Code-Generatoren für die Daten Entitätsklassen Erzeugen von Datenbankobjekten (wie Trigger, Stored Procs), Service-Proxys usw. Überall, wo Sie sehen viele Wiederholt Code nach einem Muster und viel Handarbeit beteiligt, Code-Generatoren helfen können. Aber Sie sollten nicht zu viel verwenden, um das Ausmaß, dass die Wartbarkeit ein Schmerz ist. Einige Probleme entstehen auch, wenn man sie regenerieren wollen.

Tools wie Visual Studio, haben Codesmith ihre eigenen Vorlagen für die meisten gängigen Aufgaben und machen diesen Prozess zu vereinfachen. Aber es ist einfach selbst ausrollen.

Es kann wirklich ein Problem mit Wartbarkeit, wenn Sie zurück zu kommen und können nicht verstehen, was im Code los ist. Daher oft müssen Sie abwägen, wie wichtig es ist, das Projekt schnell zu erledigen im Vergleich zu einfacher Wartbarkeit

Wartbarkeit <> leicht oder schnell Kodierungsprozess

Ich verwende My Generation mit Entity Spaces, und ich habe keine Probleme mit ihm. Wenn ich eine Schemaänderung ich regenerieren nur die Klassen und es klappt ganz gut.

Sie dienen als eine Krücke, die Ihre Fähigkeit deaktivieren kann das Programm langfristig aufrecht zu erhalten.

Der erste C ++ Compiler Code-Generatoren waren die C-Code ausspucken (Cfront).

Ich bin mir nicht sicher, ob dies ist ein Argument für oder gegen Code-Generatoren.

Ich denke, dass Mitchel es auf den Kopf getroffen hat. Code Generation hat seinen Platz. Es gibt einige Situationen, in denen es effektiver ist der Computer zu haben, die Arbeit für Sie tun! Es kann Ihnen die Freiheit geben, Ihre Meinung über die Durchführung einer bestimmten Komponente zu ändern, wenn die Zeit, Kosten, um die Code-Änderungen zu machen klein sind. Natürlich ist es wahrscheinlich immer noch wichtig, dass der Ausgang des Codegenerator zu verstehen, aber nicht immer. Wir hatten ein Beispiel für ein Projekt, das wir gerade beendet, wo eine Reihe von C ++ Anwendungen benötigt, um mit einer C # -Anwendung über Named Pipes zu kommunizieren. Es war besser für uns kleine, einfache, Dateien zu verwenden, die die Nachrichten definiert und haben alle Klassen und Code für jede Seite der Transaktion erzeugt. Wenn ein Programmierer am Problem X arbeiten, das letzte, was sie brauchte, war über die implentation Details der Nachrichten und dem unvermeidlichen Cache-Treffer zu befürchten, dass sich bringen würde.

Dies ist eine Workflow-Frage. ASP.NET ist ein Codegenerator. Die XAML-Parsing-Engine erzeugt tatsächlich C #, bevor es zu MSIL umgewandelt wird. Wenn ein Codegenerator ein externes Produkt wie Codesmith wird, die aus Ihrer Entwicklung Workflow isoliert wird, muss besondere Sorgfalt Ihr Projekt synchron zu halten genommen werden. Zum Beispiel, wenn der generierte Code ORM ausgegeben wird, und Sie machen eine Änderung des Datenbankschemas, werden Sie entweder müssen entweder vollständig den Codegenerator verlassen oder sonst Vorteil von C # 's Kapazität nehmen mit Teilklassen zu arbeiten (die können Sie Mitglieder hinzufügen und Funktionalität zu einer vorhandenen Klasse ohne es zu vererben).

Ich persönlich mag nicht die isolierte / Alt-Tab Natur des Generator Workflows; wenn der Code-Generator nicht Teil meines IDE ist dann fühle ich mich wie es eine Flickschusterei ist. Einige Code-Generatoren, wie Entity Spaces 2009 (noch nicht erschienen), sind stärker integriert als frühere Generationen von Generatoren.

Ich denke, das Allheilmittel für den Zweck von Code-Generatoren kann in Precompilieren Routinen genossen werden. C # und andere .NET-Sprachen fehlt dies, obwohl ASP.NET es genießt, und deshalb sagen wir SubSonic so gut für ASP.NET funktioniert, aber sonst nicht viel. SubSonic generiert C # -Code zur Build-Zeit kurz vor den normalen ASP.NET-Kompilierung Kicks in.

Fragen Sie Ihren Anbieter von Tools (zB Microsoft) Pre-Build-Routinen gründlicher zu unterstützen, so dass Code-Generatoren können in den Workflow Ihrer Lösungen integriert werden Metadaten, anstatt manuell extern ausgegeben Code-Dateien verwaltet, die eingehalten werden müssen, in der Isolation.

Jon

Die beste Anwendung eines Codegenerators ist, wenn das gesamte Projekt ein Modell ist, und alle den Quellcode des Projekts wird von diesem Modell erzeugt. Ich spreche nicht UML und verwandten Mist. In diesem Fall wird auch das Projektmodell enthält benutzerdefinierten Code.

Dann das einzige, was Entwickler müssen kümmern sich um das Modell ist. Eine einfache architektonische Veränderung der sofortige Änderung von Tausenden von Quellcodezeilen führen kann. Aber alles bleibt synchron.

Dies ist meiner Meinung nach der beste Ansatz. Sound utopisch? Wenigstens weiß ich, dass es nicht;) Die nahe Zukunft erzählt

In einem aktuellen Projekt wir unseren eigenen Code-Generator gebaut. Wir erzielten alle Datenbank stuff, und alle Basis-Code für unsere Ansicht und View-Controller-Klassen. Obwohl der Generator zu bauen mehrere Monate in Anspruch nahm (vor allem, weil es das erste Mal war, dass wir das getan hatte, und wir hatten ein paar Fehlstarts) es sich bezahlt das erste Mal, dass wir es lief und erzeugt das Grundgerüst für die gesamte App etwa zehn Minuten. Das war alles in Java, aber Rubin macht eine hervorragende Code-Schreibsprache besonders für kleine, einmalige Art Projekte. Das Beste war die Konsistenz des Codes und die Projektorganisation. Darüber hinaus haben Sie Art von den grundlegenden Rahmen auszudenken vor der Zeit, was immer gut ist.

Code-Generatoren sind groß vorausgesetzt, es ist ein guter Code-Generator ist. Insbesondere arbeiten C ++ / Java, die sehr ausführlich ist.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow