Umgang mit generierten Sourcen

Java-Forum Allgemeine Themen
21

Wo erkennst du einen Widerspruch? Ich wäge ab, natürlich sehe ich auch die Vorteile, wenn generierter Code nicht eingecheckt ist, aber das bringt eine andere Organisation mit sich. Beides hat Vor- und Nachteile.

Ein Entwickler pro Projekt, nicht im ganzen Unternehmen. Es können aber schon auch mal 2-3 Entwickler sein, oder eben auch nur einer, oft ist das dann der DBA.

Du willst keinen Vorteil sehen, das ist gerade das Problem.

*** Edit ***

Ich bin gerade mit ENUMs beschäftigt und da fällt mir ein gutes Beispiel ein:

ENUM Felder und ihre Werte sind ja schon ne halb dynamische Sache in der Verarbeitung, z.B. wird bei keiner Angabe der erste ENUM Wert gespeichert o.ä. Das kann man in einem Integrationstest ja auch schön testen, klar.
Sagen wir mal es gibt ein ENUM Feld in einer Tabelle mit den Werten A,B und C. Jetzt wird ein Datensatz gespeichert und in dem Feld wird A gespeichert, da im DTO kein konkreter Wert angegeben war.

Nun könnte es Änderungen am DB Schema geben und die Reihenfolge der ENUM Werte hat sich verändert, z.B. weil A rausgefallen ist oder ein neuer Wert D wurde am Anfang eingefügt…bewusst oder auch unbewusst, beides wäre möglich.

So, nun gibt es unsere 2 Varianten: generierter Code ist eingecheckt oder eben nicht.

Natürlich haben wir für die Änderungen einen Integrationstest geschrieben. Was passiert also, wenn man das DB Schema in der CI Umgebung vergisst zu aktualisieren? Der Test schlägt fehl, weil der Test natürlich nicht mehr auf A testet, sondern auf D.

Ok, und was passiert in der CI Umgebung, wenn das Schema aktuell gehalten wurde? Der Test wird erfolgreich laufen, alles ok.

Und was nun? Test war erfolgreich, also wandert der Code in die nächste Umgebung, automatisiert per CD oder manuelles Update, z.B. für diverse Systemtests oder gar Kundentests/Akzeptanztests.

Was aber passiert, wenn eine dieser folgenden Umgebungen nicht an dieser Stelle im Schema aktualisiert wurde und generierte Klassen nicht eingecheckt sind?

Tja, der Fehler wird nirgends angezeigt, da ja sowohl DB Schema und Entity exakt gleich falsch sind. Es wird einfach mit A gearbeitet, statt mit D.

Wäre die generierte Klasse eingecheckt und damit auf dem aktuellen Stand, würde es an irgendeiner Stelle auf jedenfall krachen und der Fehler wäre erkannt.

Je später ein Fehler entdeckt wird, desto teurer ist er. Und das Beispiel hat gezeigt, dass das Risiko einen logischen Fehler erst sehr spät oder überhaupt nicht zu entdecken wesentlich höher ist, wenn Datenquelle und dazu generierter Code zueinander passen. Und sie passen nunmal immer zueinander, wenn man den Code nicht eincheckt.

22

[QUOTE=deetee]Das ist doch kein Grund, schließlich liegt generierter Code auch separat, z.B. in eigenen Packages.

Natürlich checke ich .class Dateien nicht ein, das ist auch nicht das selbe. Wie gesagt, generierte Klassen machen erst das Projekt konsistent und lauffähig, .class Dateien kommen erst später.[/QUOTE]
Das ist doch ein Widerspruch in sich. class-Files sind doch auch Code - wenn auch in einer anderen Sprache. Und bei mir liegt generierter Code meist im target-Bereich.

[QUOTE=deetee;69709]
Und wenn ich z.B. in PHP daran denke in jeder Umgebung die Entities erst generieren lassen zu müssen, bevor das Projekt oder die Tests laufen können…das würde extra implementiert und in allen entsprechenden Umgebungen integriert werden müssen, ganz zu schweigen von der Wartung dieses Skriptes.[/QUOTE]
Die Generierung von Code gehört doch in den Build-Prozess. Alles was man generieren kann, sollte man auch tun und dies zu jedem Build-Vorgang (natürlich mit Ausnahmen, falls so etwas zu lange dauert).

[QUOTE=deetee;69709]
Wer generierten Code anfasst macht das meist nur ein einziges Mal :wink: Dafür gibt es Code Reviews.[/QUOTE]
Ihr macht Code-Reviews auf generiertem Code?

Kannst Du mir die Vorteile nennen, die eingecheckter generierter Code mit sich bringt?

Den einzigen Vorteil den ich sehe ist, dass es nicht bei jedem Build Zeit braucht, um den Code zu generieren.

Und ich finde das Beispiel wenig gelungen. Wenn ich eine Vorbelegung wünsche (und nichts anderes ist das), dann belege ich den Wert auch vor. Wenn dort kein Wert enthalten ist, es aber einen NotNull-Constraint gibt, sollte ein Fehler fliegen. Alles andere ist immer Magic-Code.

23

Gut dafür dauert dann das auschecken länger hust :stuck_out_tongue:
@deetee dein Beispiel ist merkwürdig oder eure Vorgehensweise sollte überdenkt werden.

  1. Wird das Schema nicht eingecheckt? Falls ja warum sollte der CI dann die Schemaänderun?
    Der große Nachteil hast du ja beschrieben, einer ändert das Schema vergisst die Klassen neu zu generieren oder checkt nicht ein zack fehlerhaftes Projekt.
    Wenn der Build das macht kann das gar nicht passieren.
  2. Es gibt bei uns einen Release Prozess da bekommt der Kunde nicht einfach so eine Version von dem CI. Da gehört schon mehr dazu…
24

Wir haben in unserer Firma ebenfalls generierten Code eingecheckt. Dieser wird nächtlich neu generiert und commited.
Sollte man am generierten Code wirklich Anpassungen vornehmen wollen haben wir einen eigenen CodeExchanger der einfach Code hinzufügt oder ersetzt.
Da unser generierter Code im Durchschnitt um die 500MB (~13.000 Dateien) umfasst, ist es nicht sehr produktiv wenn jeder Entwickler der damit arbeiten muss sich das in der Früh selbst generiert.

Unser Build Struktur ist mit ant bzw. nant realisiert. Hierzu gibt es einige Basisskripte und für eine neues Projekt reicht ein einziges Skript.
Das Ganze ist für unsere Ansprüche individuell genug, einfach gehalten und kann leicht erweitert werden.

25

Klar im target Bereich, weil du die Klassen ja nicht eincheckst

Das ist ja der Punkt über den wir hier streiten. Ich sehe das nicht so, das man pauschal alles was generiert wird nicht eincheckt.

Nein auf commits, und wenn die generierten Code beinhalten wird dieser überflogen. Natürlich wird kein richtiges Code Review jedesmal gemacht auf diese Klassen.

Nicht in jeder Umgebung und auf jedem Entwickler PC ist die Toolunterstützung zur Generierung notwendig. Nicht in allen Sprachen ist es so komfortabel den benötigten Code oder Komponenten zu generieren. In PHP muss man vieles selbst schreiben für sowas. Standards gibt es in PHP kaum, zumindest nicht so wie in Java.
Außerdem hat man wie gesagt, ein geringeres Risiko Fehler erst spät oder gar nicht zu erkennen. Hauptsächlich logische Fehler, wie in meinem Beispiel gegen Ende beschrieben.
Entwickler müssen sich nicht um die Generierung von Code kümmern, also ein Step weniger bei der Projektinstallation, wie gesagt, Toolunterstützung und Tool Bedienung ist sicher nichts, was jede Person die am Projekt arbeitet beherrschen muss. Ich kenne s.g. screendeveloper, die benötigen das Projekt nur weil sie in HTML und CSS Dateien arbeiten. Manchmal in Programmdateien, aber du glaubst nicht was solche Leute, die von solchen Entwicklungsprozessen keine Ahnung haben, alles falsch machen können. Und wer muss dann nach den Fehlern suchen?

[QUOTE=Sym;69741]
Den einzigen Vorteil den ich sehe ist, dass es nicht bei jedem Build Zeit braucht, um den Code zu generieren.

Und ich finde das Beispiel wenig gelungen. Wenn ich eine Vorbelegung wünsche (und nichts anderes ist das), dann belege ich den Wert auch vor. Wenn dort kein Wert enthalten ist, es aber einen NotNull-Constraint gibt, sollte ein Fehler fliegen. Alles andere ist immer Magic-Code.[/QUOTE]
Das Beispiel zeigt, dass es durchaus ähnliche Fehlerquellen gibt, die eben erst spät oder nicht erkannt werden könnten, wie gesagt, eher logische/semantische Fehler, also Fehler, die an sich erstmal keine Fehler sind und die DB daher auch keine Fehler meldet.

@SirWayne
Na klar haben wir das DB Schema versioniert. Aber nciht als SQL sondern als Originaldatei des Programms mit dem es modelliert wurde. Also nichts, was man automatisiert verarbeiten könnte im Build Prozess, falls du darauf hinaus willst. Ich kenne keien Firma, wo das dermaßen automatisiert wäre.

Richtig, wenn man vergisst die Klassen einzuchecken ist das Projekt kaputt. Solche Fehler werden aber dann früh entdeckt, und deshalb ist das gut! Wie gesagt, das ist besser, als das man auf einer scheinbar laufenden Umgebung testet, die zwar keine Fehler wirft, aber veraltet ist.

26

Wenn die anderen es nicht gut machen, machen wir es auch nicht gut :)? Verstehe…
Ich weiß nicht was ihr benutzt, aber aus unserer Modeldatei EMF *.ecore wird voll automatisch zur Buildzeit (Maven) Klassen generiert und dann hab ich solche Probleme wie ihr oben gar nicht.

[QUOTE=deetee;69859]
Richtig, wenn man vergisst die Klassen einzuchecken ist das Projekt kaputt. Solche Fehler werden aber dann früh entdeckt, und deshalb ist das gut! Wie gesagt, das ist besser, als das man auf einer scheinbar laufenden Umgebung testet, die zwar keine Fehler wirft, aber veraltet ist.[/QUOTE]

Was ist daran gut? Du verstehst mich einfach nicht. In meinem Fall gibt es ein kaputtes Projekt erst gar nicht. Klar Modellierungsfehler geht der Build nicht mehr, sowie wenn man auch Bullshit Klassen eingecheckt.
Und die Entwickler müssen auch keine Steps mehr machen, weil das über Maven gebaut wird und die Dependencies darüber auch angezogen werden, also müssen sie sowieso ab und zu mal bauen um auf dem neusten Stand zu sein (Einfach gesagt in OSGi läuft Dependencies Management besser ab).

*** Edit ***

[QUOTE=Pippl;69849]
Da unser generierter Code im Durchschnitt um die 500MB (~13.000 Dateien) umfasst, ist es nicht sehr produktiv wenn jeder Entwickler der damit arbeiten muss sich das in der Früh selbst generiert.
.[/QUOTE]

Es lebe die Modularität :), da bei uns alles schön in Module ist, kommen wir in so ein Problem erst gar nicht und wir sind auch in der Größen Ordnung

27

Verstehe das Problem nicht…

Quellen checkt man in die Quellcodeverwaltung ein, was daraus generiert wird nicht.

Mit Maven laesst man zB. Code in einem eigenen Projekt generieren, der gen. Code wird nicht eingecheckt, das entstehende Artifakt aber verteilt (Maven Repos).
Dann muss man auch nur neu generieren wenn sich wirklich etwas aendert und spart sich viel Zeit beim bauen… ansonsten hilft Generation Gap wenn man generierten Code aender moechte.

28

[QUOTE=SirWayne]
Was ist daran gut? Du verstehst mich einfach nicht. In meinem Fall gibt es ein kaputtes Projekt erst gar nicht. [/QUOTE]
Klar versteh ich dich und ich könnte auch gut mit Projekten leben, wo man die Sourcen nicht eincheckt. So wichtig finde ich das nicht, es ist nur nicht die Variante, die ich für besser halte.

Du hast kein kaputtes Projekt, genau das habe ich doch deutlich beschrieben. Dafür kannst du eine Umgebung haben die eben nicht kaputt ist, aber leider nicht aktuell. Und dann finde mal Fehler. Viel Spaß.
@maki
Ein System wie Maven gibt es nicht immer in Projekten und schon gar nicht in anderen Sprachen als Java. Ich denke da an C/C++, PHP, Python, Ruby, etc.

Wie wäre es, wenn man generierten Code als eigenständiges Projekt pflegt und als Dependency im Projekt einbindet? Hm, hat das Charme? Mal überlegen…

29

maki versteht mich :slight_smile:

Nein eben nicht hier liegt dein Denkfehler…

He? Einfach der Fehler kann nur im Model liegen…

30

Nochmal…wenn man vergisst das Schema zu aktualisieren oder z.B. dies nur teilweise aktualisiert, dann kann es sein, dass das Projekt scheinbar funktioniert, aber es eben logische Fehler gibt, die leider nicht so offensichtlich sind, wie eine Exception.

Jetzt verstanden?

31

[QUOTE=deetee]Nochmal…wenn man vergisst das Schema zu aktualisieren oder z.B. dies nur teilweise aktualisiert, dann kann es sein, dass das Projekt scheinbar funktioniert, aber es eben logische Fehler gibt, die leider nicht so offensichtlich sind, wie eine Exception.

Jetzt verstanden?[/QUOTE]

Ehrlich gesagt -->nö?
Wenn jemand vergisst das Model zu aktualisieren gibt es Probleme jo? Wenn man if mit for verwechselt auch :D?

32

Woran erkennst du, dass es Probleme gibt, wenn doch dein Schema und die generierten Klassen zusammenpassen und die Anwendung daher keine Exceptions o.ä. wirft?

Sehr schwierig, und daher ist das Risiko wesentlich höher den Fehler sehr spät erst zu erkennen.

33

Darum geht es doch gar nicht. Wenn es dafür keine komfortable Struktur bzw Tools gibt, dann geht das natürlich nicht. Wenn es aber die Möglichkeit gibt, sehe ich keine Gründe für ein Einchecken.

*** Edit ***

[QUOTE=deetee;69946]Woran erkennst du, dass es Probleme gibt, wenn doch dein Schema und die generierten Klassen zusammenpassen und die Anwendung daher keine Exceptions o.ä. wirft?

Sehr schwierig, und daher ist das Risiko wesentlich höher den Fehler sehr spät erst zu erkennen.[/QUOTE]
Verstehe ich nicht. Wenn das Schema nicht korrekt ist, werden Fehler entstehen. Ich sehe kein logisches Beispiel, bei dem dann keine Exceptions auftreten, sich die Anwendung aber nicht wir gewünscht verhält. Ich sehe auch nicht, wie ein solches Problem durch eingecheckte generierte Klassen behoben sein sollte.

Wenn ich etwas an dem Schema ändern muss, fallen nach dem Generieren der Klassen die Fehler auf. Wenn ich das Schema aber ändere und die Klassen aber nicht von mir direkt geändert werden, fällt mir das doch gar nicht auf. Kompiler-Fehler erhalte ich zunächst jedenfalls keine.

34

Ja wie gesagt verstehe ich auch nicht, wenn du ein Modellierungsfehler machst, ist so oder so schlecht, genauso wie ein Programmierfehler. Weiß auch nicht warum dir eingecheckte Klassen dabei helfen sollen.

Ansonsten weiß ich nicht wie die Tools in anderern Sprachen ist, aber wir reden hier ja von Java :wink:
@maki Thema abgliedern?

35

@Sym

Wenn das Schema nicht korrekt ist, werden Fehler entstehen, die aber nicht zwangszweise durch Exceptions o.ä. münden, sondern einfach logische Fehler sind, z.B. Rechenfehler mit falschen Werten, falsche Status oder andere funktionale Anforderungen, die definiert wurden. Die Anwendung läuft, aber eben nicht wie gewünscht. Das muss aber erstmal jemand bemerken.

Es gibt genügend Beispiele für sowas, ungefähr fast soviele und vielseitige, wie es Kundenanforderungen für Projekte gibt. Denn logische Fehler sind eine Sache der Definition, wenn eine Rechnung erstellt wird, kommt es nicht nur auf die Preise der Produkte an, sondern noch auf Steuer, Rabatte, Lieferkosten, etc. Und wenn da ein Faktor nicht den Anforerungen entspricht, dann funktioniert die Anwendung zwar, es kommt aber ein falscher Rechnungsbetrag am Ende raus. Nur wer merkt das? Und wann?

36

[QUOTE=deetee]Woran erkennst du, dass es Probleme gibt, wenn doch dein Schema und die generierten Klassen zusammenpassen und die Anwendung daher keine Exceptions o.ä. wirft?

Sehr schwierig, und daher ist das Risiko wesentlich höher den Fehler sehr spät erst zu erkennen.[/QUOTE]

Also bei mir gibt es nur Modellierungsfehler im Schema, weil das Schema und die generierten Klassen passen immer zusammen, weil sie ja IMMER aktuell sind. Klar wenn dann compiler Fehler irgendwo drin sind, bekommst du das mit weil der build nicht läuft oder deine Projekte rot werden, ganz normal halt.

37

Ok, ich habs lange genug versucht zu erklären. Du verstehst es wohl wirklich nicht. Dann zitiere ich dich mal für einen leider wenig ergiebigen Abschluss dieser Diskussion meinerseits:

38

[QUOTE=deetee]@Sym

Wenn das Schema nicht korrekt ist, werden Fehler entstehen, die aber nicht zwangszweise durch Exceptions o.ä. münden, sondern einfach logische Fehler sind, z.B. Rechenfehler mit falschen Werten, falsche Status oder andere funktionale Anforderungen, die definiert wurden. Die Anwendung läuft, aber eben nicht wie gewünscht. Das muss aber erstmal jemand bemerken.
[/QUOTE]

JUnit Tests? Da helfen beide Wege nicht? Du hast deine generierte Klassen in deinem Projekt und Workspace liegen, da gibt es keinen Unterschied zwischen beiden Verfahren. Die sourcen liegen schon vor, also ist es in beide Wege total identisch.
In deinem Fall was die Logik angeht hilft nur Testen Testen Testen und da gibt es keinen Unterschied zwischen beiden Verfahren.

*** Edit ***

Es gibt nicht zu verstehen, du willst was lösen, wo beide Ansätze keine Vor und Nachteile aufweisen.
Du kannst deinen (angeblichen) Vorteil nicht mal richtig benennen, aber zum Glück bin ich nicht der einziger der deine Vorteile nicht sieht :slight_smile: :slight_smile:

Ich kenn beide Verfahren deshalb weiß ich es gut zu schätzen wie wir es jetzt haben. Man lernt aus Fehler

39

Gerade fällt mir noch ein, wie sieht es mit generierten CSS Dateien aus? Würdest du die einchecken oder nicht?

Ich brauchs sicher nicht erwähnen…aber wir checken sie ein :wink:

40

[QUOTE=deetee]Gerade fällt mir noch ein, wie sieht es mit generierten CSS Dateien aus? Würdest du die einchecken oder nicht?

Ich brauchs sicher nicht erwähnen…aber wir checken sie ein ;)[/QUOTE]

Ich checke gar nichts ein was generiert ist :). Nada, wie gesagt ich sehe kein Vorteil. Target folder nicht, Java Klassen nicht, HTML nicht etc. etc.

Außerdem gebe ich doch offen und ehrlich zu, dass ich deinen Vorteil nicht verstehe und ich geb an dem Vorgehen nichts die Schuld. Ich sag nur welche Probleme da auftreten.
Wie gesagt bin ja froh, dass ich nicht der Einzige hier bin puhhh :wink: