Der Tausend-Dollar-Fehler in einer Zeile – SBT + PlayFramework

Heutzutage reden alle darüber, wie wichtig es ist, ein gutes Entwicklererlebnis zu haben, da es viele gute Nebenwirkungen haben wird, wie zum Beispiel, aber nicht beschränkt auf:

• Entwicklungsgeschwindigkeit / Produktivität

• Codequalität/Wartung

• Kosten sparen usw.

Allerdings kommt es oft vor, dass wir an Projekten arbeiten, bei denen irgendwann in der Vergangenheit ein kleines Stück Code hinzugefügt wurde, um das Projekt schneller zu machen oder sogar um etwas zu reparieren, vielleicht hat jemand versucht, den Build schneller zu machen, oder Ich versuche sogar, den Ingenieuren ein besseres Entwicklungserlebnis zu bieten. Dies war in dieser Geschichte der Fall.

Vor ein paar Jahren wurde bei einem Projekt, an dem wir gearbeitet haben (bevor ich überhaupt Teil des Unternehmens war), ein Problem beim Aufbau von SBT, Scala und Play Framework festgestellt, wodurch die Kompilierungszeit für den lokalen Aufbau des Projekts in Anspruch genommen wurde Je nach Maschine ca. 3 bis 5 Minuten. Es wurde versucht, das Problem zu beheben. Die Projektstruktur wurde wie folgt in zwei Teile geteilt:
Vorher

ProjectA
  /api
 /core
 /app

Nachher

ProjectA
 /core
 /app

ProjectApi
  /api

Folgendes wurde zur build.sbt hinzugefügt

lazy val projectA = (project in file("."))
  .enablePlugins(...)
  .settings(commonSettings)
  .aggregate(api)
  .dependsOn(api)

lazy val api = project.settings(commonSettings)

Auf diese Weise wurde zwar die Kompilierungszeit verkürzt, nur während des Builds auf der CI-Pipeline. Ich bin mir nicht sicher, ob es während der Entwicklungsphase geholfen hat, aber es fügte einen neuen und schrecklichen Fehler hinzu, der dazu führte, dass Entwickler Tausende verschwendeten Arbeitsstunden.

Nachdem diese Zeile hinzugefügt wurde, bemerkten die Entwickler, wie lange es dauerte, nur eine einfache auszuführen
sbt läuft lokal, da jetzt für jede Änderung in der Codebasis eine vollständige Kompilierung erforderlich war.

Die Reise, um das Problem zu verstehen

Gemäß Dokumentation im SBT-Referenzhandbuch – Multiprojekt

Es ist wichtig, die beiden Definitionen der Aggregation zu beachten und hängt davon ab

Aggregation bedeutet, dass die Ausführung einer Aufgabe für das Aggregatprojekt diese auch für die Aggregatprojekte ausführt

Ein Projekt kann vom Code in einem anderen Projekt abhängen. Dies erfolgt durch Hinzufügen eines dependOn-Methodenaufrufs. Zum Beispiel, wenn der Kern util in seinem Klassenpfad benötigt.

Nachdem ich ein oder zwei Tage damit verbracht hatte, Dokumente zu lesen und viele frustrierte Versuche, das Problem zu beheben, kam ich schließlich zu diesem Github – falsche Neukompilierung in Multi-Projekt-Build. Dies war nicht die Lösung selbst, brachte mir jedoch am Ende Licht des Tunnels, um zu verstehen, dass das Problem tatsächlich mit dem Multiprojekt-Setup zusammenhängt.

Und außerdem verstand ich, was los war, und jetzt war meine build.sbt-Datei genauso einfach wie:

lazy val projectA = (project in file("."))
  .enablePlugins(...)
  .settings(commonSettings)
  .dependsOn(api)

lazy val api = (project in file("api"))
  .settings(commonSettings)

Es gab ein Problem mit der Einrichtung von ProjektA in SBT. Wir haben SBT angewiesen, die API des Projekts einzuschließen (was richtig war), aber die API-Definition verwies auf den gesamten Projektstamm. Das bedeutete:

Immer wenn die API kompiliert werden musste, versuchte SBT auch, projectA selbst zu kompilieren.
Da projectA die API zum Kompilieren benötigte, würde es eine weitere API-Kompilierung auslösen.
Dadurch entstand eine Endlosschleife, die Entwickler dazu zwang, SBT zu beenden und bei jeder Codeänderung alles manuell zu bereinigen und zu kompilieren.
In einfacheren Worten ist Folgendes passiert:

Wir haben SBT angewiesen, die API des Projekts einzubinden.
Die API-Definition verwies auf das gesamte Projekt.
Das Kompilieren der API löste eine vollständige Projektkompilierung aus (wieder einschließlich der API).
Diese Schleife machte SBT sehr langsam und für Entwickler frustrierend.

Das Team beschäftigte sich seit mindestens 4 Jahren mit diesem Problem...

Folgen – Behebung des Problems

Nachdem ich meinen Teamkollegen gesagt hatte, dass ich ein Überraschungsfeature bereits auf dem Master zusammengeführt hatte, verstanden die Leute nicht, was passierte. Ich wollte jedoch die Freude auf ihren Gesichtern sehen und sagte dem gesamten Team, es solle das Master-Feature in eines davon integrieren Einige von ihnen bemerkten beim ersten Versuch überhaupt nichts, während andere bemerkten, dass nach der Änderung eines Codes in der Codebasis nur die betroffene Datei innerhalb von Sekunden und nicht wie zuvor in Minuten kompiliert wurde. Und die größte Überraschung war, als einer der Teamkollegen es bemerkte und es laut im Büro sagte.

Gust ... hast du das Problem mit der Kompilierungsschleife behoben? Ich arbeite hier an etwas und bekomme sofort Feedback zu allen Änderungen im Code.

Damals musste ich zugeben und teile die Neuigkeit mit allen anderen Ingenieuren, es hat mich zu einem glücklicheren Ingenieur gemacht, da ich jetzt glücklich bin, an diesem Projekt zu arbeiten und nicht lange auf eine vollständige Zusammenstellung unseres Projekts warten zu müssen .

Wenn Sie das Gefühl haben, dass etwas auf unsere Art und Weise läuft, wann immer Sie sind, was auch immer Sie tun, denken Sie daran, dass Sie die Chance haben, es besser zu machen, und vergessen Sie niemals, was Sie begonnen haben.

Wenn Sie diesen Artikel gerne lesen oder sich mehr Inhalt wünschen, lassen Sie es mich bitte in den Kommentaren wissen, ich teile gerne mehr über diese Reise.

Vielen Dank fürs Lesen.

Ein paar Statistiken zum Projekt:

Projektstart:

• Etwa 4.000 Java-Dateien

• Rund 300 Twirl-Vorlagen

• Kompilierungszeit vor Verbesserungen 3 bis 5 Minuten für jede Änderung im Code

• Die Kompilierungszeit nach Verbesserungen beträgt durchschnittlich 1 Minute und 20 Sekunden für die vollständige Kompilierung

• Die Kompilierungszeit nach Verbesserungen beträgt durchschnittlich 5 bis 10 Sekunden für jede Änderung mit sofortigem Feedback (die meiste Zeit wird für den Neustart des HTTP-Servers durch Playframework aufgewendet)

Titelbild erstellt von AI.

Das obige ist der detaillierte Inhalt vonDer Tausend-Dollar-Fehler in einer Zeile – SBT + PlayFramework. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!