Seit bald einem Jahr arbeiten wir bei Guave Interactive mit BEM. Zeit eine Zwischenbilanz zu ziehen.

Bevor ich im Dezember 2014 bei Guave Interactive meine Arbeit aufnahm wurden alle CSS-Anweisungen mehr oder weniger in eine einzige LESS-Datei content.less geschrieben.
Da ich in der Vergangenheit so konditioniert wurde, mich gegebenen Umständen und Standards anzupassen, schrieb auch ich meine Anweisungen in diese eine Datei.

In meinem ersten Projekt umfasste dieses eine File über 3500 Zeilen (verschachtelter) LESS-Code. Wie man sich unschwer vorstellen kann: es ist sehr schwierig, daran Code anzupassen.

Internes Barcamp änderte alles

Nach meinen ersten beiden grösseren Projekten bei Guave stellte ich Mitte September 2015 an unserem internen Barcamp (finden ca. halbjährlich statt) das Konzept von BEM vor. Zur Vorbereitung schrieb ich erste Code-Beispiele, damit ich meinen Kollegen anhand von praktischen Beispielen das Prinzip von BEM näher bringen konnte. Nach anfänglicher Skepsis gegenüber dem Konzept, lernte ich beim Ausprobieren die Vorteile von BEM kennen. Aus diesen ersten Code-Beispielen resultierte schlussendlich unser kleines Framework, das “Guave-Blocks”.

Erste Anwendungen in der Praxis

In der Nachbesprechung des Barcamps entschieden wir, künftig BEM bei uns einzusetzen, da wir uns besser strukturierte LESS-Files davon erhofften.

Ein kleiner Onepager, welcher mit WordPress umgesetzt wurde, sollte der erste Gradmesser sein. Nachdem ich das Projekt innerhalb kürzester Zeit durch hatte, war ich überzeugt: BEM ist genau das, was wir brauchen. Die Kollegen traten etwas auf die Euphorie-Bremse, da es nur ein kleines Projekt war. Dennoch, ich war überzeugt davon.

Der richtige Gradmesser folgte Anfang dieses Jahres. Wir setzten für die UPC einen Produktberater um, welcher prominent auf der Webseite der UPC platziert wurde. Zeitgleich arbeiteten bis zu 3 Leute am Code und die von mir initiierten Strukturen wurden grösstenteils eingehalten.

Erst kürzlich haben wir diesen Code aufgeräumt und noch einmal überdacht. Dies ist ein normaler Prozess und durchaus sinnvoll. Dadurch sparten wir total über 300 Zeilen Twig-Code sowie einiges an LESS-Code.

Nach bald einem Jahr mit BEM sind wir noch immer im Prozess des Lernens. Aber wir werden immer besser im Schreiben von BEM.

Einführung von Codelinting und Styleguides

Auch dieses Jahr führten wir ein Barcamp durch. Ein Mitarbeiter stellte Codelinting für JS (jshint) und LESS (lesshint) vor, welches durch Regeln zu einheitlicherem Code führt. Ich kämpfte schon länger dafür, da wir immer öfters zu dritt im Code herumwuselten. Aus meiner Sicht hat die Einführung von Codelintern ebenfalls zu besserem Code geführt.

Ich meinerseits stellte das Thema Styleguides vor und erhielt danach Zeit einen wiederverwendbaren Styleguide umzusetzen. Das Gute daran: wir können gewisse LESS-Files wie Farbdefinitionen, Schriftarten- und grössen sowie Basics direkt in unser „Guave Blocks“ übernehmen und von da weiterverarbeiten.

Es braucht Offenheit

Was ich an Guave Interactive sehr schätze: die Firma ist offen für Inputs, welche das Unternehmen besser machen. Denn nur so ist es möglich, neue Standards wie BEM oder Codelinting einzuführen.

Ich bin gespannt, was wir als nächstes einführen werden, was unsere Abläufe, Standards, whatever verbessert.