Neulich habe ich in einer technischen Gruppe einen Beschwerdepost gesehen. Der Verfasser sagte, dass er vor dem Projektstart ein Tool zur CSS-Minifizierung verwendet hat. Am nächsten Tag öffnete ein Kollege die Stildatei und sah nur noch zusammengequetschte Zeichen – er war sofort verärgert: „Wer hat das geschrieben? Kann das ein Mensch lesen?“ Der Verfasser antwortete kleinlaut, dass die Minifizierung Teil des Build-Prozesses sei und er nichts dagegen tun könne.
Diese Situation ist eigentlich ziemlich typisch – fast jedes Frontend-Team hat schon darüber gestritten. Heute wollen wir klären: Nach der CSS-Minifizierung können Kollegen den Code nicht verstehen – wer ist schuld?
Zunächst: Was macht CSS-Minifizierung? Einfach gesagt, entfernt sie Leerzeichen, Zeilenumbrüche und Kommentare aus dem Code und kürzt Variablennamen so weit wie möglich, um die Dateigröße zu reduzieren und die Ladezeit der Webseite zu verkürzen. Das ist an sich nicht falsch – in der Produktionsumgebung ist Leistung wichtig, und Minifizierung ist Standard. Das Problem entsteht jedoch, wenn viele Leute die minifizierten Dateien direkt in das Code-Repository committen oder sogar die Originaldateien überschreiben. Wenn Kollegen den Code ziehen, sehen sie nur noch Hieroglyphen wie „a{b:c;d:e}“ – da ist man doch verwirrt, oder?
Wem kann man also die Schuld geben? Manche sagen, es sei die Schuld des Minifizierungstools, weil es zu „brutal“ sei. Aber das Tool ist unschuldig – es ist nur ein Programm, das Befehle ausführt. Wenn du es anweist zu minifizieren, dann minifiziert es eben bis zum Äußersten. Wenn du dich beim Gemüseschneiden mit dem Küchenmesser schneidest, kannst du nicht dem Messer die Schuld geben, dass es zu scharf ist.
Andere sagen, es sei die Schuld der Kollegen – wer als Frontend-Entwickler minifizierten Code nicht lesen kann, habe grundlegende Fähigkeiten nicht gemeistert. Das ist leicht dahergeredet. Minifizierter Code ist für den Browser gedacht, nicht für Menschen. Es ist wie wenn du einen Roman in Morsecode übersetzt und an einen Freund schickst – wenn er ihn nicht versteht, kannst du ihm nicht vorwerfen, dass er kein gutes Deutsch kann? Normale Menschen lesen Code mit Einrückungen, Kommentaren und Zeilenumbrüchen – minifizierter Code ist völlig unleserlich. Von Kollegen zu verlangen, dass sie minifizierten Code mühsam lesen, ist keine Fähigkeitsförderung, sondern Quälerei.
Meiner Meinung nach liegt die eigentliche Schuld bei den Prozessen und Richtlinien. Einfach gesagt: Das Team hat nicht festgelegt, „was committet werden soll und was nicht“. Der richtige Ansatz ist: Der Quellcode (also das für Menschen lesbare CSS) bleibt im Repository, die Minifizierung erfolgt automatisch in der Build-Phase, und die minifizierten Dateien werden entweder in das dist-Verzeichnis ausgegeben oder direkt in das Release-Paket integriert – sie müssen nicht in die Versionskontrolle. Viele Teams machen es sich jedoch einfach oder haben es anfangs nicht durchdacht und committen die minifizierten Dateien direkt – und schon entsteht das Problem.
Manche könnten sagen: Was ist, wenn das Unternehmen verlangt, die minifizierten Dateien zu committen? Zum Beispiel bei bestimmten statischen Hosting-Plattformen oder wenn das Backend direkt auf Dateien im Repository zugreift. Diese Fälle gibt es tatsächlich, aber auch dafür gibt es Lösungen. Du kannst die Minifizierung als separaten Build-Schritt ausführen, der vor dem Release durchgeführt wird, anstatt nach jeder Codeänderung schnell zu minifizieren und zu committen. Oder du verwendest Tools wie Pre-Commit-Hooks, die vor dem Commit automatisch die Minifizierung durchführen, sodass im Repository immer eine unminifizierte Version für Menschen lesbar bleibt. Es gibt immer mehr Wege als Probleme – entscheidend ist, dass jemand im Team die Initiative ergreift und diese Richtlinie etabliert.
Ein weiterer oft übersehener Punkt sind Code-Kommentare. Viele CSS-Minifizierungstools entfernen standardmäßig auch Kommentare, sodass selbst wenn du Hinweise in der minifizierten Datei hinterlassen möchtest, diese nicht erhalten bleiben. Daher müssen wichtige Logik und Hinweise für spätere Entwickler unbedingt in der Quelldatei stehen – und du solltest nicht erwarten, sie nach der Minifizierung noch zu sehen. Das ist auch der Grund, warum die Quelldatei so wichtig ist – sie ist der „wahre Körper“ der Teamarbeit.
Letztendlich ist CSS-Minifizierung an sich nichts Schlechtes – schlecht ist das Fehlen begleitender Management-Gewohnheiten. Wenn Kollegen den Code nicht verstehen, liegt es nicht daran, dass sie unfähig sind oder das Tool dumm ist, sondern daran, dass im Workflow ein Glied fehlt. Es ist wie beim Kochen: Das Messer ist gut, aber wenn du das Gemüse zu Brei zerkleinerst und servierst, und die Gäste sagen, es sieht nicht gut aus – kannst du dem Messer die Schuld geben?
Also: Streitet nicht mehr darüber. Wenn es das nächste Mal passiert, gib offen zu, dass die Prozesse nicht klar definiert waren, und ergänze schnell die Richtlinien: Quelldateien ins Repository, Minifizierung dem Build überlassen – und niemand sollte die minifizierten Artefakte direkt committen. Wenn das schon lange so gemacht würde, gäbe es doch gar keinen Grund zur Schuldzuweisung? Letztendlich steckt hinter technischen Problemen oft ein Managementproblem. Oder etwa nicht?