Generierten Code bereinigen: Refactor oder Map?

8

Kontext:

Ich musste mich kürzlich mit einer von XSD.exe generierten Klassendatei befassen. Es war 3500 Zeilen lang mit lächerlich wortreichen Klassen- / Variablennamen (denken Sie someRidiculouslyLongPrefixThenMaybeOneThingUniqueAtTheEnd- auf einen Blick schwer zu vergleichen someRidiculouslyLongPrefixThenMaybeOneOtherThingChanged) und Anmerkungen überall. Unterm Strich habe ich ewig gebraucht, um herauszufinden, was zum Teufel los war. Ich las es und dachte, ich würde meinen Namen niemals neben etwas so ... Unrein setzen.

Frage:

1) Ist es eine schlechte Praxis, mit generiertem Code herumzuspielen (dh ihn zu bereinigen)?

2) Wäre es besser, einen Mapper zu schreiben, um die generierten Klassen meinen eigenen netten, sauberen Klassen zuzuordnen (mit denen ich dann ziemlich glücklich arbeiten könnte)?

BEARBEITEN:

Danke für alle Kommentare.

Wenn ich tatsächlich etwas Interessantes damit machen würde (dh wenn es Domänenobjekte gäbe, die alles andere als Transportobjekte wären), würde ich sie wahrscheinlich 'saubereren' Klassen zuordnen, was ich sowieso tun müsste, um welche zu erhalten Art von Funktionalität aus ihnen. In diesem Fall handelt es sich bei den Klassen effektiv um DTOs. Daher ist es möglicherweise sinnvoll, dass die Benennung mit den entsprechenden Elementen übereinstimmt. Wie bereits erwähnt, muss ich es nicht berühren - nur um Accessoren / Mutatoren aufzurufen, bevor die Daten zur Verarbeitung an eine andere Ebene weitergegeben werden.

Im Moment denke ich, ich werde sie gut in Ruhe lassen.

refactoring clean-code

— Tom Tom
quelle

Warum müssten Sie sich den generierten Code überhaupt ansehen (geschweige denn ändern)? Abgesehen vom Debuggen des Codegenerators scheint dies jedoch nicht der Fall zu sein.

Sie waren die Klassendefinitionen. : |

— Tom Tom

2

Ja, das verstehe ich, aber die Tatsache, dass es generiert wurde, bedeutet, dass niemand (außer vielleicht dem Autor des Codegenerators) den generierten Code betrachten muss. Rufen Sie es auf, ja (wenn die Klassen- / Methodennamen Sie ärgern, können Sie dann keinen Adapter schreiben, der die Hässlichkeit isoliert?), Aber sehen Sie es sich nicht an.

hatte genau das gleiche Problem mit xsd- ging mit 2

— jk.

Punkt genommen, Delnan. Ich werde mit den Namen umgehen, ohne mich zu schmutzig zu fühlen. Immerhin habe ich sie nicht verfasst.

— Tom Tom

14

Die Gefahr beim Refactoring von generiertem Code zum Lernen und Aufräumen besteht darin, dass die Änderungen verloren gehen, wenn er vom Tool selbst oder einem anderen Entwickler erneut generiert wird.

Ihr Team könnte sich in die Lage versetzen, den Code in einer anderen Datei zu generieren, in die bereinigte Version zu kopieren und Änderungen vorzunehmen, die nur Zeit und Ressourcen erfordern. (Ich war dort mit der Originalversion von Entity Framework.)

Wenn Sie mit den generierten Namen nicht leben können, ändern Sie entweder die Quelle, aus der sie generiert wurden, oder tun Sie, was Sie in # 2 vorschlagen.

— NikolaiDante
quelle

4

Das einzige Mal, wenn Sie generierten Code bearbeiten sollten, ist, wenn Sie sicher sind, dass Sie ihn NIEMALS erneut generieren müssen. Wenn Sie versuchen, sich auf manuelle Änderungen zu verlassen und neu generieren müssen, verlieren Sie auf dem Weg sicherlich etwas.

— Michael Kohne

Der Wartungsaufwand ist definitiv der Dealbreaker - danke.

— Tom Tom

1

@MichaelKohne Dann, drei Wochen später, ändern sich die Anforderungen nur ein kleines bisschen und Sie müssen es trotzdem tun. = P

— Izkata

10

Berühren Sie generell niemals generierten Code, da dies bedeutet, dass Sie versprechen, dass Sie ihn nie wieder generieren werden, oder dass Sie alle vorgenommenen Änderungen wiederholen müssen. Wenn der generierte Code besser aussehen soll, müssen Sie sowohl die Codegenerierung als auch die Bereinigung automatisieren. Wenn Sie beispielsweise irgendwo eine XML-Datei generieren, möchten Sie diese möglicherweise xmlindentals Teil Ihres Erstellungsprozesses ausführen .

Aus ähnlichen Gründen gehört der generierte Code nicht zur Quellcodeverwaltung. Sie stellen die Daten und Regeln unter die Quellcodeverwaltung und lassen Ihr Build-Skript die Codegenerierung übernehmen.

Alle Änderungen am generierten Code müssen über den Codegenerator erfolgen. Wenn Sie also möchten, dass der generierte Code anders aussieht, ändern Sie die Eingaben des Codegenerators, den Codegenerator selbst oder wenden Sie eine skriptfähige Nachbearbeitung an. Aber nicht von Hand bearbeiten.

Eine Ausnahme bilden Codegeneratoren im Gerüststil, bei denen Sie den Generator einmal ausführen, um ein Skelett zu erhalten, aus dem Sie weiter aufbauen. Mit diesen wird der Generator nie wieder für dieselbe Datei ausgeführt. Sie behandeln die generierte Datei also einfach als reguläre Quelldatei und vergessen, dass sie von einem Generator stammt.

— tdammers
quelle

Interessante Punkte RE: Quellcodeverwaltung / Erstellungsprozess. Hmm. (Entschuldigung, ich kann noch nicht +1 - musste ein neues Konto erstellen: $)

— Tom Tom

Beachten Sie, dass die Erstellung von generiertem Code manchmal recht teuer ist. Wenn zum Beispiel die Datenbank gescannt wird und Sie eine große Datenbank haben, möchten Sie dies möglicherweise nicht jedes Mal tun müssen, wenn Sie sich für eine neue

— Kaufabwicklung

3

Ich stimme der Antwort von @NikolaiDante (+1) voll und ganz zu.

In dotnet / c # haben Sie das Konzept der "Teilklassen": Der Quellcode für die "zu verwendende Klasse" besteht aus 2 separaten Dateien, einem generierten Teil und einem manuell hinzugefügten / bearbeiteten Teil. Ihre API-Verschönerungen werden in die "manuelle" Datei aufgenommen, die vom Codegenerator nicht überschrieben wird.

In der Java / Hybris-Welt verwenden sie die Vererbung für den nicht generierten Code:

Sie haben zum Beispiel eine Klasse Customer mit Ihren "API-Verschönerungen", die von "GeneratedCustomer" erbt.

— k3b
quelle

Es ist eine interessante Lösung, aber ich befürchte, dass sie im Bereich des Wartungsaufwands bleibt (Schreiben / Aktualisieren von Wrapper-Klassen für jede Änderung des generierten Codes). Aber danke!

— Tom Tom