Webentwickler müssen häufig an Projekten arbeiten, die andere begonnen oder erstellt haben, was nicht selten zu Bemerkungen wie: „Was zum … soll das?!?“ führt. Mit anderen Worten: Als Webentwickler verwenden Sie wesentlich mehr Zeit darauf, den Code anderer Leute aufzuräumen oder sich mit den Folgen unglücklicher Designs herumzuschlagen, anstatt selbst großartige Dinge zu programmieren und das Leben der Anwender leichter zu machen.
Fast noch schlimmer ist es, wenn Sie feststellen, dass Sie den als Müll eingestuften Code in grauer Vorzeit selbst verfasst haben. Ich bin diesem Thema im Laufe meines Arbeitslebens beziehungsweise in einschlägigen Foren immer wieder begegnet. Mich damit kritisch auseinander zu setzen, hat mir sehr geholfen, besseren Code zu schreiben.
Gründe, warum Code schlecht wird
Die folgenden Aussagen sind nicht wirklich überraschend. Das Hauptthema, mit dem wir Entwickler uns herumzuschlagen haben, ist die Tatsache, dass unsere Welt sehr fragmentiert ist, dass es zahlreiche Missverständnisse und permanente Änderungen gibt. Was vor fünf Jahren gängige Praxis war, ruft heute verständnisloses Kopfschütteln hervor. Andererseits werden inzwischen als Fehler eingestufte Praktiken zugunsten möglichst cooler Effekte und der Verwendung neuer Technologie trotz besseren Wissens weiter eingesetzt. Meistens sind jedoch nicht die Entwickler, sondern eher die Produktionsbedingungen und andere Gründe für schlechten Code im Internet verantwortlich:
- Nicht für diese Aufgabe qualifizierte Personen werden damit beauftragt, Code fürs Web zu schreiben, da es ja nur „Software-Programmierung“ sei.
- Entwicklern wird nicht genügend Zeit für Aufbau, Bereinigung und Dokumentation des Codes eingeräumt – meistens müssen wir uns halbwegs durchmogeln.
- Entwicklung ist Teil eines größeren Projekts, das häufig an den falschen Stellen beschnitten wird (beim Testen, der Dokumentation, Entwicklung einer Infrastruktur zum Warten und weiteren Entwickeln).
- Entwickler sind eher schlecht darin, den Zeitaufwand und die benötigten Ressourcen für die Entwicklung eines Produkts zu schätzen.
- Falscher Stolz: Anstatt bereits vorhandene Lösungen zu verwenden, ziehen Entwickler es vor, wieder und wieder alles selbst zu programmieren.
- Der Markt – vor allem Software-Firmen haben uns jahrelang suggeriert, dass es keinen Bedarf für handgemachtes Webdesign und -entwicklung gibt: Gute Software-Tools seien völlig ausreichend. Tatsächlich liefern all die schlauen WYSIWYG-Editoren und Integrierten Entwicklungsumgebungen (IDE) jedoch nicht das, was tatsächlich benötigt wird.
Ungeachtet dessen, gibt es ein paar Dinge, die ganz offensichtlich nicht gut sind, aber dennoch ständig wiederholt werden. Dazu gehört ein grundlegendes Missverständnis darüber, was Webentwicklung eigentlich ist.
Sie entwickeln nicht für sich selbst
Sie entwickeln weder für sich noch für Ihre Kunden – denn in den meisten Fällen haben Kunden keinen blassen Schimmer von Webtechnologien. Meistens wollen Kunden eine Website oder eine Anwendung, weil ihr Mitbewerber das auch hat. Im Prinzip entwickeln Sie für die folgenden beiden Gruppen:
- die Endanwender des Produkts
- diejenigen Personen, die nach Ihnen an dem Projekt arbeiten.
Sie schulden es den Endanwendern, eine Website oder App zu entwicklen, die unabhängig vom Grad der jeweiligen Professionalität, der Umgebung und dem Geschick gut funktioniert. Den nach Ihnen kommenden Entwicklern sollten Sie einen Code überreichen, der verständlich ist und ohne ihre Beteiligung erweitert oder geändert werden kann.
Dass ich diesem Prinzip gefolgt bin und in der Regel die einfachst mögliche Lösung mitsamt einer guten Dokumention geliefert habe, hat entscheidend zu meiner Karriere beigetragen. Ich hätte natürlich Jahre damit verbringen können, möglichst tolle Dinge mit brandneuen Techniken zu entwickeln und einen Haufen überkommener Produkte hinter mir zu lassen. Vielleicht hätte ich damit auch mehr Geld verdienen können. Allerdings kann ich jetzt sagen, dass sich die vergangenen sechs Jahre nicht wie Arbeit angefühlt haben – vielmehr habe ich das getan, was ich wollte, und bin dafür bezahlt worden.
Wenn Sie ein professioneller Webentwickler oder -designer sein wollen, der von seinen Fachkollegen und Vorgesetzten respektiert wird, sollten Sie auf Ihre Designs und Entwicklungen etwas halten.
Seien Sie sich vor allem darüber bewusst, dass die Leute, die Ihre Produkte später pflegen müssen, nicht über Ihre Fähigkeiten und Ihr Wissen verfügen. In den meisten Fällen wird man Ihr Produkt durcheinander bringen, da Firmen in der Regel nicht genügend Personal für die Pflege engagieren – schnelle Umsätze sind meist wichtiger. Behalten Sie diesen Gedanken im Hinterkopf, um sicherzustellen, dass Sie ein Produkt liefern, das nicht Gefahr läuft, innerhalb kürzester Zeit zu einem Chaoshaufen zu verkommen.
Genug Theorie – lassen Sie uns nun die verschiedenen Webtechnologien und deren kritische Punkte anschauen.
HTML
Technisch gesehen ist HTML keine Programmier-, sondern eine Auszeichnungssprache. Der Unterschied besteht darin, dass HTML keine Logik beschreibt, sondern definiert, was ein bestimmter Textabschnitt ist oder Sie verweisen damit auf andere Daten, die dem Browser vorgeben, was er zu tun hat (ein Bild anzeigen, die Regeln des CSS-Stylesheets laden und ausführen, eine Video- oder Audio-Datei hinzufügen und so weiter). Das heißt nicht, dass man bei HTML nichts falsch machen kann – leider.
Ich bin ein Programmierer, ich mag es, wenn Code funktioniert. Bei HTML schieben wir jedoch häufig Dinge irgendwo hin und hoffen, dass es läuft. Der kreative und laxe Umgang von Browsern mit HTML hat zu einem ebenfalls sehr laxen Herangehen diverser Menschen geführt.
Die häufigsten Probleme in Bezug auf HTML lassen sich sich auf die folgenden Dinge reduzieren:
- „Malen“ mit HTML,
- übermäßiger Einsatz von Klassen,
- Verwendung visueller Klassen- und ID-Namen,
- der Einsatz nicht-semantischen HTMLs,
- das Schreiben von skriptabhängigem HTML.
Warum das problematisch ist, erläutern die folgenden Passagen.
Malen mit HTML
Diese ungeeignete Methode hat uns jahrelang verfolgt – vor allem zu den Zeiten, als die Browser noch keine CSS-Unterstützung boten. Wir verwendeten font-Tags, zentrierten Elemente via center auf dem Monitor, benutzten das HR-Tag, wenn wir eine Linie darstellen wollten, setzten fleißig <b> und <i> zum Auszeichnen von Dokumenten ein oder verwendeten table fürs Layout.
Das alles führte dazu, dass bei späteren Änderungen des Aussehens jedes einzelnen HTML-Dokument der Website überarbeitet werden musste, anstatt ein einziges Stylesheet zu ändern. Das ist weder wartungsfreundlich noch sehr hilfreich für eine gute Leistung der Website.
Während visuelle HTML-Elemente relativ rar geworden sind, wird nach wie vor mit HTML „gemalt“. Eine ganze Reihe cooler HTML5-Lösungen fallen in älteren Browsern auf eine Sammlung nutzloser Elemente – meistens jede Menge mit IDs versehene DIVs – zurück. Das ist völlig sinnlos. Wenn Sie ein Element nur deshalb verwenden, um einen visuellen Effekt zu erzielen, verwenden Sie dafür lieber JavaScript oder CSS3. Wenn Sie das Dokument wahllos mit HTML-Elemente bestücken, um ein bestimmtes Aussehen zu erreichen, kann es bei der Pflege der Seiten zu Problemen kommen – etwa dann, wenn Content-Management-Systeme bei Verwendung eines WYSIWYG-Editors die HTML-Elemente rausschmeißen.
HTML ist keine Leinwand, auf der Sie malen können. Es ist eine Methode, um Text zu beschreiben und festzulegen, wie interaktive Elemente wie Formulare, Videos oder Audio-Content gerendert werden sollen.
Inflationärer Gebrauch von Klassen
Klassitis, wie es auch genannt wird, ist ein verbreitetes Problem. Anstatt ein Element mithilfe einer Klasse von anderen Elementen abzuheben, neigen viele Leute dazu, alles und jedes mit Klassen zu versehen.
Das lässt sich zwar einfach bewerkstelligen, birgt aber ähnliche Wartungsprobleme wie das Malen mit HTML. Soll der Klassen-Name später geändert werden, müssen sämtliche Notationen der Klasse per Suchen und Ersetzen in verschiedenen Dokumenten aktualisiert werden. Unter CSS-Gesichtspunkten ist das Vorgehen wenig sinnvoll – im Gegenteil, eine Liste wie die folgende ist reiner Ballast:
<ul class="shopping-list first"> <li class="list-item">Cucumbers</li> <li class="list-item">Bananas</li> <li class="list-item important">Toilet Paper</li> <li class="list-item">Deodorant</li> <li class="list-item">Q-Tips</li> <li class="list-item">Duct Tape</li> <li class="list-item">Screwdriver</li> </ul>
Verwenden Sie Klassen nach dieser Faustregel: Nutzen Sie Klassen, um besondere Elemente hervorzuheben und um Elemente zu gruppieren, die noch nicht durch eine logische Ordnung gruppiert sind. Alles andere ist falsch. Das obige Beispiel könnte nach dieser Faustregel so aussehen:
<ul class=“shopping-list first“>
<li>Cucumbers</li> <li>Bananas</li> <li class="important">Toilet Paper</li> <li>Deodorant</li> <li>Q-Tips</li> <li>Duct Tape</li> <li>Screwdriver</li> </ul>
Statt der Klassen .shopping-list .list-item{} zum Gestalten der Elemente, reicht diese Notation: .shopping-list li{}. Den hervorzuhebenden Punkt deklarieren Sie demnach über .shopping-list li.important{}und Sie müssen sich keine Gedanken über die Unterscheidung zwischen important und list-item machen. Das gleiche gilt für Ihre JavaScript-Selketoren. Auf diese Weise schreiben Sie wesentlich weniger und schnelleren Code.
Wenn Sie CSS verwenden, sollten Sie unbedingt lernen – falls Sie es nicht schon beherrschen – wie Sie die semantische Hierarchie des Dokuments nutzen können, um möglichst pfiffigen und schlanken CSS-Code zu erstellen. Machen Sie HTML nicht zum Vehikel für Ihr CSS, da andere Personen, die später mit Ihrem Code beziehungsweise Markup klarkommen müssen, möglicherweise nicht verstehen, worauf Sie hinaus wollten.
Visuelle Klassen- und ID-Namen
Wer visuelle Klassen- und ID-Namen verwendet, hat den Sinn von CSS nicht ganz verstanden oder ist sich der Tatsache nicht bewusst, dass CSS-Stylesheets Änderungen unterliegen. Wer Namen wie die folgenden verwendet, hat es möglicherweise auch aufgegeben, verständlichen Code zu schreiben oder möchte einfach schnell eine Änderung einfügen, um die Bug-Tracking-Liste abzuarbeiten. Schauen Sie sich einmal diese Namen an:
greenMessagelargeBoxRightboldHeadlineArial14px663366right(dieses Beispiel habe ich allen Ernstes in einer Produktionsumgebung gefunden!)orangeHeadingredIntroText
Namen wie diese machen es schwierig, Ihren Code zu pflegen und können für erhebliche Verwirrung sorgen, wenn bei einer künftigen Überarbeitungen des Designs statt orangener Überschriften grüne gewünscht sind. Dann müssen Sie nach Orange suchen, um die grüne Farbe zuzuweisen – was ein wirklicher Wahnsinn ist.
Klassen- und ID-Namen sollten logisch beschreiben, worum es sich handelt – nicht wie etwas aussieht. So wäre es sinnvoller, die largeBoxRight als leanSideBar zu deklarieren, während die Überschrift in der nächsten Version der Website vermutlich anders formatiert wird und daher besser mit einer Funktionsbeschreibung wie breakout oder instructions bezeichnet würde. Bei der greenMessage handelt es sich vermutlich um eine Bestätigung beziehungsweise confirmation und der redIntroText hätte demnach als warning oder error mehr Informationswert. Es sei denn, Ihr Webdesign hat tatsächlich einen roten Einleitungstext, bei dem es sich nicht um eine Warnung handelt. In dem Fall wäre intro jedoch völlig ausreichend.
Der Grund liegt auf der Hand – wenn das Design geändert wird, müssen Sie an Ihrem HTML-Dokument nichts tun. Lediglich die Werte der CSS-Eigenschaften müssen angepasst werden. Mit generischen und semantisch sinnvollen Klassennamen machen Sie Ihren Code fit für künftige Änderungen. Was nicht heißt, dass Sie gar keine visuellen Klassennamen verwenden dürfen.
Sinnvolle Ausnahmen: Wenn Sie einem Element beispielsweise abgerundete Ecken zufügen möchten und zudem wünschen, dass dieses HTML-Element später wahlweise mit oder ohne abgerundete Ecken verwendet werden kann, ist eine Klasse namens rounded durchaus sinnvoll. Sie können Sammlungen visueller Effekte via CSS definieren und sie per CSS anwenden oder deaktivieren.
Nicht-semantisches HTML
Ein anderes großes Problem ist die Verwendung nicht-semantischen HTMLs – sprich dem Verwenden individuell benannter Elemente, für die es in HTML eigene Attribute gibt. Darunter fallen merkwürdige Konstruktionen wie diese hier:
<span class="link">Click here to continue</span><div id="mainheading">Welcome to our awesome web site</div><span class="label">Enter name:</span><input type="text" name="name" id="name"><div class="button rounded gradient" id="but1">Send form</div><span class="headline">Pachyderms</span><span class="sub-headline">Elephants</span>
Für solche Kuriositäten gibt es mehrere Gründe:
- HTML wird von Menschen geschrieben, die nichts davon verstehen.
- Es wird ein Framework oder System verwendet, das von HTML-Unkundigen erstellt wurde.
- Menschen schreiben HTML ohne zu wissen, wo es eingesetzt wird (wiederverwendbare Komponenten).
Für den ersten Punkt gibt es keine Entschuldigung. Es gibt genügend Entwickler am Markt, die HTML schreiben können und das wirklich gerne tun. Wenn Sie eine Webanwendung wollen, sollten Sie auf jeden Fall so jemanden engagieren. Wenn Ihre Toilette repariert werden muss, rufen Sie ja auch nicht den Maurer, sondern einen Sanitärfachmann. Andernfalls enden Sie knietief in – na, Sie wissen schon – und genau so verhält es sich mit Ihrem Webprodukt.
Der zweite Punkt, schlechter von Frameworks generierter Code, ist zwar verständlich, aber ebenfalls eine Schande. Framework-Entwickler sollten mit guten Frontend-Entwicklern zusammen arbeiten, um Komponenten mit vernünftigem HTML zu erstellen. Ein span– anstelle eines label-Elements ist ineffizient, weil Sie die spezifischen Vorteile nicht nutzen können (klickbarer Text, um aufs Formularsteuerelement zu fokussieren; Unterstützung von Eingabehilfen beziehungsweise behinderungskompensierender Technologien).
Der dritte Punkt ist der verständlichste – und hier kommt HTML5 ins Spiel. In der jetzigen Version ist HTML eine schreckliche Sprache, um Dokumente aufzuteilen und daraus wiederverwendbare und beliebig anzuordnende Komponenten zu erstellen. Die hierarchische Ordnung der Überschriften macht das nahezu unmöglich. Zudem ruinieren die entlang der Dokumentensyntax vererbten CSS-Regeln die Darstellung von Widgets, wenn Sie diese Komponenten nicht übermäßig genau spezifizieren oder in iFrames einbetten.
Es gibt jedoch keinerlei Entschuldigung für HTML-Grausamkeiten wie im Beispiel oben, wenn Sie solches Markup bewusst schreiben. HTML hat eine äußerst logische Struktur und nützliche Elemente für bestimmte Aufgaben: Überschriften unterteilen Dokumente in logische Einheiten, Schaltflächen rufen Funktionen im Backend auf oder lösen Skripte und Formularelemente aus (etwa FIELDSET oder LEGEND), strukturieren Formulare und machen sie für alle möglichen Eingabegeräte zugänglich.
Mit JavaScript verwandeln Sie jegliches Element in einen Button oder lassen es Aktionen ausführen, wenn der Anwender damit interagiert. Allerdings – warum sollte man sich damit herumschlagen, wenn HTML selbst etwas entsprechendes bietet, das funktioniert? In den meisten Fällen, liegt das Problem darin, dass der Autor des Codes es versäumt hat, eine HTML-Referenz einzufügen und das richtige Element zu finden.
Script-abhängiges Markup
Dieser Ursache für „verdorbenen“ Code begegnet man in jüngster Zeit sehr häufig. Dennoch erstaunt es mich immer wieder, warum HTML-Autoren das tun. Sofern ein bestimmtes HTML-Element nur dann sinnvoll ist, wenn es eine bestimmte JavaScript-Funktion auslöst, sollte man das komplett mit JavaScript umsetzen. Das gleiche gilt für Elemente, die nur gut aussehen, wenn man bestimmtes CSS auf sie anwendet. Mit JavaScript ist es kinderleicht, in ein Dokument Code einzufügen – auch via CSS können Sie das erreichen.
Es gibt keine logische Erklärung dafür, jede Menge DIVs und SPANs mit bestimmten Klassen von Hand zu schreiben und diese dann so zu erweitern, dass sie etwas anderes darstellen. Wenn Sie so vorgehen, verteilen Sie die spätere Pflege des Codes auf das HTML-Dokument und Ihr Script. Das bedeutet wiederum, das früher oder später irgend jemand sich nicht an diese Form der Notation hält. Sofern Sie HTML verwenden, das nur bei verfügbarem Scripting sinnvoll ist, dann gewährleistet das Erstellen mit JavaScript, dass Änderungen am HTML-Code dazu führen, dass man zumindest auch einen Blick auf das JavaScript wirft.
HTML is the lowest common denominator – it should work for everybody. When I look at a web site on my company Blackberry and I click a button without something happening I get frustrated. When I use my Smartphone and your input fields aren’t input fields I can’t use your web site. If there is any kind of error and JavaScript stops and your interface becomes not usable you frustrate and confuse your end users – the people who bring you money and tell other people about your great product. If you generate all that is dependent on JavaScript and an error occurs end users will still get a usable – albeit not as pretty and cool – interface and will not leave frustrated and annoyed. This is a no-brainer when it comes to providing a service.
HTML ist der kleinste gemeinsame Nenner – es sollte für jeden funktionieren. Wenn ich mit meinem Firmen-Blackberry Webseiten aufrufe, auf einen Button klicke und nichts passiert, bin ich frustriert. Wenn Ihre Eingabefelder beim Aufruf mit meinem Smartphone keine Eingabefelder sind, kann ich Ihre Website nicht benutzen. Falls es irgend einen Fehler gibt, so dass das JavaScript stoppt und Ihre Benutzeroberfläche damit außer Funktion setzt, verwirren und frustrieren Sie die Anwender – also die Leute, die Ihnen Geld bringen und anderen Leuten von Ihrem tollen Produkt erzählen sollen. Wenn Sie jedoch alles generieren lassen, was von JavaScript abhängig ist, werden Endanwender bei einem auftauchenden Fehler dennoch eine brauchbare Schnittstelle sehen – vielleicht nicht ganz so schick und cool – jedenfalls werden die Anwender nicht verärgert und frustriert die Anwendung verlassen. Das sollte jedem, der einen Service anbietet, klar sein.
Es ist keine Schande, HTML für Ihre JavaScript-Lösung während der Entwicklung von Hand zu schreiben. Bevor Sie die Lösung installieren, sollten Sie den HTML-Code jedoch in ein einfaches Generator-Script in Ihrem JavaScript schieben – und wir werden alle viel glücklicher mit dem Ergebnis sein.
Writing invalid HTML because you can
HTML validation is holy war material – so let’s not go too deep into it. The main point about validating code is that you have a good starting point: you know it should work and if there is something going wrong then there must be a different reason than your code for it. The reason to write invalid HTML is normally to use functionality that browsers provide that makes a lot of sense but is not part of the normal HTML spec. WAI-ARIA is a good example – you add a few extra attributes to your elements and out of a sudden you have a much more accessible document as the browser tells assistive technology like Screen Readers that there is more to this document than meets the eye.
Nicht-valides HTML schreiben, nur weil es möglich ist
You will find however that people write invalid HTML because it can be done. As browsers do not complain about invalid HTML (they do not show invalid XML though which actually makes them inconsistent) but instead try to repair wrong nesting and ignore invalid attributes people use their own attributes and leave invalid elements in the document. Sometimes you find people deliberately writing wrong HTML as some browser in one configuration or another does things right only when you do it wrong. This means a few things though:
Leider kommt es vor, dass manche nicht-valides HTML schreiben, weil das technisch möglich ist. Da Browser nicht-valides HTML ohne zu „Meckern“ verarbeiten (nicht-valides XML wird allerdings nicht angezeigt, was Browser inkonsistent macht) und sogar versuchen, falsche Verschachtelungen zu reparieren oder ungültige Attribute zu ignorieren, benutzen diverse Leute ihre eigenen Attribute und lassen nicht-valide Elemente im Dokument. Zum Teil wird absichtlich mit falsches HTML benutzt, da einige Browser in einer bestimmten Konfiguration Dinge richtig darstellen, wenn Sie falschen Code verwenden. Das hat diverse Folgen:
- Sie verlassen Sich darauf, dass Browser Ihre Fehler bereinigen – viel Glück.
- Sie müssen Leuten, die Ihren Code später pflegen, erklären, warum Sie was wie geschrieben haben.
- Höchstwahrscheinlich müssen Sie den Code für andere Browser ändern und für jeden neu auf den Markt kommenden Browser erweitern.
- Sie sollten sich nicht wundern, wenn ein anderer Entwickler Ihren Code später überarbeitet, weil Ihr Markup einfach falsch aussieht.
Das lesen Sie in den nächsten Teilen der Artikelserie:
- CSS-Code haltbar machen
- Typische Schwachstellen bei JavaScript umgehen
