Professionelle Webentwicklung und Wartbarkeit (webinale, Berlin)

Vortrag vom 27. Mai 2009, exklusiv für die webinale, Berlin.

Der Vortrag wurde in einer Einführung in Wartbarkeit durch weitere Informationen und Beispiele ergänzt und wird dort weitergepflegt.

Inhalt

Definition von Wartbarkeit
Aber
Annahmen
Populäre Wartungsprobleme

Definition von Wartbarkeit

Die Leichtigkeit, mit der ein System – Website oder Webapplikation – verändert oder erweitert werden kann.

Aber

… manche Dinge sollten sich nicht ändern müssen; die Ziele lauten »Separation of Concerns« und Orthogonalität:

Die grundlegende Idee hinter Orthogonalität ist es, dass Dinge, die konzeptionell nichts miteinander zu tun haben, in einem System ebenfalls nichts miteinander zu tun haben sollten.

Dieses Prinzip wird im Bereich der Webentwicklung oftmals verletzt, und ist dementsprechend Kernpunkt dieser Präsentation.

Annahmen

Webentwicklung dreht sich um Wahrscheinlichkeiten. Wartbarkeit zu verbessern, beinhaltet, die Wahrscheinlichkeit von Änderungen zu minimieren.
Veränderungen bedeuten Kosten. Diese Kosten sind die Motivation, Wartbarkeit zu verbessern.
- Ein System, bei dem Veränderungen teuer oder riskant sind, bedeutet »Gelegenheitseinbußen«.
Veränderungen sind unvermeidbar, und dennoch gibt es vermeidbare Veränderungen. Das ist das Geheimnis, um Wartbarkeit zu verbessern.
Im Bereich der Webentwicklung sind HTML-Änderungen am teuersten.
- Das meiste Wartungspotential liegt im HTML.

Populäre Wartungsprobleme

Aufgeblähter Code

Problem: Markup, das bereits jetzt oder demnächst überflüssig ist.
Beispiele: »Divitis« und »Classitis«.
Lösungen: »Keep it simple.«

Präsentationsbezogene Elemente und Attribute

Problem: Markup, das die Darstellung bestimmt oder dazu verwendet wird, die Darstellung zu kontrollieren.
Beispiele: center, font, u; Layout-Tabellen.
Daten: Googles 2005er Webstatistiken sowie Philip Taylors HTML-Stichproben.
Lösungen:
- Ziehen Sie »Strict«- »Transitional«-DTDs vor (und validieren Sie).
- Verschieben Sie darstellungs- und verhaltensbezogenen Code in externe Stylesheets und Skripte.

Präsentationsbezogene ID- und Klassennamen

Problem: ID- und Klassennamen – Markup –, die Darstellung, nicht Funktion widerspiegeln.
Beispiele: rot, right, clearfix, w1024.
Daten: Googles 2005er Webstatistiken.
Lösungen:
- Beschränken Sie den Einsatz von IDs und Klassen auf ein Minimum.
- Verwenden Sie funktionsbezogene ID- und Klassennamen.
- Verwenden Sie neutrale ID- und Klassennamen.
- Allgemein: Bevorzugen Sie Namen, die so kurz wie möglich, aber so lang wie nötig sind.

Zuviele aus dem Markup referenzierte Stylesheets und Skripte

Problem: Stylesheets und Skripte, die aus dem HTML verlinkt werden, und die sowohl Performance (höhere Zahl von HTTP-Requests) und Wartbarkeit beeinträchtigen.
Beispiele: style.css und print.css und wasauchimmer.css; »Conditional Comments«.
Daten: Jens Oliver Meierts Alexa-CSS-Analyse und Andy Kings Weblog-Performance-Analyse (durchschnittlich 4 externe CSS-Dateien, wenn auch einschließlich @imports).
Lösungen: Verlinken Sie nur ein Stylesheet aus dem HTML; beschränken Sie die Anzahl der Skripte.

Ungeschickte Stylesheet- und Skriptnamen

Problem: Stylesheet- und Skriptdateien, die Darstellung oder Verarbeitung widerspiegeln.
Beispiele: style.css, screen.css, 9234930.css; »versionierte« Stylesheets (speziell nicht-automatisiert).
Daten: Jens Oliver Meierts Alexa-CSS-Analyse.
Lösungen: Verwenden Sie funktionsbezogene oder generische Stylesheet- und Skriptnamen.

Medientypdefinitionen im Markup

Problem: Stylesheets, die Layout- oder Geräteabhängigkeiten ans Markup ketten.
Beispiele: <link rel="stylesheet" href="standard.css" media="screen">.
Lösungen: Geben Sie Medientypen innerhalb von Stylesheets an.

Schwer erweiterbares Markup

Problem: Zu generische ID- und Klassennamen, die in Großprojekten zu Mehrfachverwendung neigen und damit die Verständlichkeit und Wartbarkeit reduzieren.
Beispiele: Mikroformate (wie location in hCalendar oder logo in hCard).
Lösungen: Verwenden Sie »Pseudo-Namensräume« – wenn Ihr Projekt mit hoher Wahrscheinlichkeit komplex und umfangreich wird.

Über mich

Ich bin Jens Oliver Meiert, und ich bin ein Engineering Lead und Autor. Ich habe als technischer Leiter für Google gearbeitet, bin dem W3C und der WHATWG verbunden und schreibe und begutachte Bücher für O’Reilly. Ansonsten experimentiere ich gerne, mitunter auch in den Bereichen Philosophie, Kunst und Abenteuer. Hier auf meiert.com teile ich einige meiner Ansichten und Erfahrungen.

Wenn du Fragen oder Anregungen zu dem hast, was ich schreibe, sende mir gerne eine Nachricht.