Absurditäten des Web-Alltags

Das Leben als Freelancer bietet einen Einblick in die Arbeitsweisen verschiedener Firmen und Agenturen. Der Freelancer lernt nicht nur, mit welchen Frameworks und Tools die Firmen arbeiten, sondern auch, dass Code-Standards in jedem Betrieb anders aussehen können.

Ich bin seit über zehn Jahren als Freelancer tätig. Das ist manchmal anstrengend, da man selten weiß, ob man in zwei Wochen einen Job hat, bedeutet auch viel Arbeit, da neben der eigentlichen Tätigkeit der Web-Entwicklung die Organisation des eigenen Mini-Betriebes hinzukommt mit Steuerkram, Angebotserstellung, Akquise-Aktivitäten usw.
Ein durchaus positiver Nebeneffekt ist jedoch, dass man sich als Freelancer nicht stets im eigenen Saft suhlt, sondern durch unterschiedliche Aufträge immer wieder neue Firmen und Agenturen und damit unterschiedliche Arbeitsweisen kennen lernt.

In der Regel werde ich für zwei Wochen bis hin zu drei Monaten gebucht, oft von heute auf morgen und das auch schon mal in Frankfurt, München, Bielefeld, nicht immer direkt vor der Haustür. Häufig werde ich dann gebucht, wenn ein Entwickler im Urlaub ist oder wenn ein Projekt mit eigenen Kräften der Agentur nicht mehr gestemmt werden kann. Vor allem komme ich fast immer in laufende Projekte hinein, sodass grundlegende Entscheidungen für die Frontend-Entwicklung bereits getroffen sind.

Jede Firma ist etwas anders organisiert, hat eigene Standards, spezielle Lösungsansätze und eine andere Art, Webseiten zu bauen. Derweil haben sich Grunt bzw. Gulp und LESS bzw. SASS als Best Practice durchgesetzt, was jedoch nicht bedeutet, dass überall gleich gearbeitet wird. In jeder Firma werden diese Technologien im Detail anders interpretiert. Aussagen wie »Wir arbeiten nach dem BEM-Konzept, haben das aber etwas für unsere Zwecke angepasst« sind keine Ausnahmen.

Das hat für mich den Effekt, dass ich im Grunde jede Buchung als eine Art Fortbildung, manchmal auch als Inspiration zum Nachdenken erlebe. Aus jedem Projekt gehe ich mit mehr Knowhow heraus und werde sogar dafür bezahlt. Das heißt nicht, dass mein Wissen gigantisch groß ist. Es ist eher so, dass ich in jedem Projekt kämpfe, den Anforderungen der einzelnen Agentur gerecht zu werden, dafür aber einen guten Eindruck davon habe, was »draußen« in der Web-Welt abgeht, wie sich die Frontend-Entwicklung verändert und wie modernes Webdesign in der Praxis gelebt wird – und wie gut Gemeintes oft einfach nur gutgemeint bleibt ;-).

Ich warte auf den ersten, der sich tot-strukturiert

Recht häufig sehe ich, wie viel Mühe in die Strukturierung eines Projektes gesteckt wird. Struktur ist wichtig, ohne Frage. Aber mehr ist nicht immer mehr. Da werden SASS-Dateien für einzelne HTML-Elemente, Module und Objekte angelegt, was zu Beginn eines Projektes sinnvoll erscheint.

Mit fortlaufendem Projekt ist es jedoch keine Seltenheit, dass ein Projekt 100 SASS-Dateien und mehr umfasst. Schon bei 20 einzelnen Dateien ist es kaum möglich, intuitiv zu erkennen, was sich in welcher Datei verbergen könnte. Für diejenigen, die eine solche Struktur über Monate entwickelt haben, mag das alles völlig klar sein. Kommt man als Freelancer erst spät in ein Projekt, ist man schon mal »Lost in Space«.

Abgesehen davon habe ich es nicht nur einmal erlebt, dass ein Grunt-Task aufgrund wachsender Anzahl von Sass-Dateien (und natürlich auch wachsender Anzahl anderer Dateien) 30, 60 oder mehr Sekunden dauerte, und dies aufgrund des Gesamtsettings und des Fortschritts im Projekt nicht auf die Schnelle umzustellen war. So bin ich schon mehrmals an die Grenzen meiner Geduld gestoßen.

»Wir trennen nach Struktur und Farben«

Wie gesagt, ich halte Struktur für wichtig, es ist nur die Frage, wie weit man es treibt. Bei einem Auftraggeber wurden grundsätzlich einzelne Dateien für die Struktur, also die Flächenaufteilungen und andere Dateien für Farben angelegt. Das war insofern durchdacht, da in dem Haus diverse Webseiten mit demselben Grundlayout aufgesetzt waren, lediglich die Farben den einzelnen Auftritt ausmachten. Was jedoch dazu führte, dass zusammengehörige border-Eigenschaften auseinander gerissen wurden. In der einen Datei standen also border-style und border-width, die Farbe der border war jedoch in einer anderen Datei zu finden. Kann man machen. Macht es aber nicht einfacher.

Meine Lieblings-SASS-Variablen: $white und $black

Ich weiß nicht, wie es euch dabei geht. In jedem zweiten Projekt sind diese beiden Variablen zu finden. Und ich sitze davor und frage mich: Welchen Mehrwert hat das? Ich frage mich, in welchem Projekt man sich überlegt: »Heute ändern wir den Wert von $white in #ff0000.« Kann man machen? Ja! Macht man es? Nein! Ich würde auch behaupten, dass Variablen wie $lightgray, $middlegray, $darkgray oder $middledarkgray weder zu einer besseren Pflegbarkeit noch zu einer effektiveren Arbeit führen. Warum machen wir das? Weil es geht. Ist es sinnvoll? Ich sage: Nein!

Bereits im Vorfeld habe ich zu der Thematik der SASS-Variablen Feedback erhalten, dass man es schon erlebt hat, dass der Weißwert von #ffffff auf #f2f2f2 geändert wurde. Inhaltlich ist es ja sinnvoll, aus einem klaren Weiß ein etwas gedämpfteres Weiß zu machen, damit Texte auf dem Bildschirm nicht ganz so knallen. Aber – jetzt kommt der Moment, wo ich als Freelancer später zu einem Projekt hinzustoße: Ich setze diese Sass-Variablen ein und werde mich wahrscheinlich wundern, warum mein eingesetztes $white nicht wirklich weiß ist?!? Bessere Varianten wären sicher $text-white-color oder $background-black. Variablen wie $white bzw. $black sind aus meiner Sicht keine geeigneten Bezeichnungen für Variablen, da sie im Grunde keine Variablität zulassen.

CSS bietet ja generell die Möglichkeit, mit einem Schlag das Aussehen und die Farbgebung eines kompletten Web-Angebotes zu verändern. Ja, das geht. Macht man es? Nein. In über zehn Jahren habe ich noch kein Projekt erlebt, bei dem bei einer Überarbeitung lediglich das CSS ausgetauscht wurde. Selbst wenn es kein Relaunch war, sondern nur ein Re-Make oder gar nur ein Re-Brush (was scheinbar eher eine Formulierung für das Angebot war, da das doch wesentlich billiger klingt), gab es bei solchen Projekten auch immer Anteile am HMTL, die verändert wurden, was dann auch eine Ergänzung des CSS notwendig machte.

Kommentieren ist wichtig!

Ja, dem stimme ich auch zu. Dann schaue ich in einen Quelltext und finde Folgendes:

Huaaah… Solltet ihr das lesen und solltet ihr in dieser Weise kommentieren: Bitte lasst es! Wenn eure Kommentare lediglich das wiederholen, was offensichtlich im HTML zu lesen ist, hilft das weder euch noch anderen Entwicklern, um den Quelltext besser zu verstehen. Das bläht nur das HTML auf und ist letztendlich nur Makulatur.

Wenn zusammengehöriges HTML auf unterschiedliche Dateien verteilt ist, dann ist es für folgende Entwickler hilfreich, wenn der Anfang und das Ende eines div-Blocks durch Kommentare gekennzeichnet ist. Sinnvoll ist es, wenn ein Kommentar auf etwas hinweist, was eben nicht intuitiv aus dem Quelltext hervorgeht.

Das gilt nicht nur für HTML, sondern für alle Quelltexte. Ob eine PHP-Funktion mit dem Funktionsnamen getZipCodeOfUser() wirklich mit den Worten »liefert die Postleitzahl des Nutzers« kommentiert sein muss, stelle ich persönlich in Frage.

Hurra, wir haben die divititis besiegt!

Tabellen-Layouts waren vorgestern, div-Layouts waren gestern, das ist zum Glück vorbei! Wir haben jetzt HTML5 und können unsere Quelltext endlich mit einer modernen, fortgeschrittenen Technologie und einer sinnvollen Semantik bereichern. Sehr gut, das gefällt mir! Ich stehe in der nächsten Agentur uns stoße auf dieses HTML:

Aua. Zugegeben. Für neue HTML5-Struktur-Elemente wie section oder article hat sich noch kein Standardeinsatz durchgesetzt. Der gezielte Einsatz ist schwer und wird in der Regel nach dem persönlichen Empfinden eingesetzt. So lässt sich darüber streiten, ob man für den Haupt-Seiten-Wrapper ein section einsetzt, oder das section-Tag lediglich als Strukturelement für den Hauptinhalt der Seite einsetzt.

Ich wage aber zu behaupten: Spätestens wenn du drei section-Elemente ineinander verschachtelt hast, stimmt hier was nicht. Das entspricht nicht dem, was sich das W3C dabei gedacht hat. Also: Wenn du ein zusätzliches Element benötigst, um eine spezielle Layout-Anforderung umzusetzen, dann nimm ein div. Genau dafür ist es gedacht und ist gar nicht so schlimm, wie allgemein sein Ruf. Das ist auf jeden Fall besser, als ein semantisch relevantes HTML-Tag zweckzuentfremden. Wahrscheinlich hat sich das Wort sectionitis noch nicht durchgesetzt, weil es nicht so leicht von der Zunge geht wie divititis.

Und, und, und…

Ich weiß, manche von euch werden jetzt die Augen verdrehen. Ich vermute aber auch, dass vielen von euch ein »ja, genau« von den Lippen geht. Und dass ihr solche oder ähnliche Erfahrungen in der täglichen Arbeit schon gemacht habt. Ich würde mich freuen, wenn ihr eure Anekdoten hier teilt. Ich bin mir sicher, am Ende wird hier ein schönes Sammelsurium zu lesen sein, bei dem sich viele wiederfinden und sich auch der ein oder andere ertappt fühlt.

Und bitte: Schiebt den bitteren Ernst etwas zu Seite. Viele Dinge, die ich selber in meinen langen Jahren als Entwickler gemacht habe, waren nicht immer sinnerfüllt, und manche würde ich selber ebenso belächeln.Nichts ist persönlich gemeint und wenn man alles mit einem Augenzwinkern betrachtet, ist auch alles halb so schwer ;-).