Professionelle Webentwicklung und Wartbarkeit
Jens O. Meiert, 27. Mai 2009.
Vortrag anlässlich der webinale 09, Berlin.
Vorträge werden inhaltlich nicht aktualisiert. Der vorliegende Vortrag wurde jedoch in einer Einführung in Wartbarkeit durch weitere Informationen und Beispiele ergänzt und wird dort weitergepflegt.
Inhalt
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 Web-Statistiken 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 Web-Statistiken.
-
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 O. 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 O. 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
locationin hCalendar oderlogoin hCard). - Lösungen: Verwenden Sie »Pseudo-Namensräume« – wenn Ihr Projekt mit hoher Wahrscheinlichkeit komplex und umfangreich wird.
Ähnliche Themen
Das könnte Sie ebenfalls interessieren:
- Conditional Comments, Resets, Frameworks
- Schlechtes HTML ist teuer (und weitere Weisheiten)
- Anforderungen an Website-Prototypen
Schwerpunkt: Webentwicklung.