Professionelle Webentwicklung und Wartbarkeit (webinale, Berlin)

Vortrag vom 27. Mai 2009, exklusiv für die webinale, Berlin. Schwerpunkt: Webentwicklung (RSS-Feed für alle Themen).

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

Inhalt

1. Definition von Wartbarkeit
2. Aber
3. Annahmen
4. Populäre Wartungsprobleme
   • Aufgeblähter Code
   • Präsentationsbezogene Elemente und Attribute
   • Präsentationsbezogene ID- und Klassennamen
   • Zuviele aus dem Markup referenzierte Stylesheets und Skripte
   • Ungeschickte Stylesheet- und Skriptnamen
   • Medientypdefinitionen im Markup
   • Schwer erweiterbares Markup

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 (lang: Jens Oliver Meiert), und ich bin ein Frontend-Engineering-Leiter und technischer Autor/Verleger. Ich habe als technischer Leiter für Firmen wie Google und als Engineering Manager für Firmen wie Miro gearbeitet, bin W3C und WHATWG verbunden und schreibe und prüfe Fachbücher für O’Reilly und Frontend Dogma.

Ich experimentiere gerne, nicht nur in der Webentwicklung (und im Engineering Management), sondern auch in anderen Bereichen wie der Philosophie. Hier auf meiert.com teile ich einige meiner Ansichten und Erfahrungen.

Wenn du mir einen Gefallen tun magst, interpretiere wohlwollend (ich spreche drei Sprachen, und die kommen sich manchmal in die Quere), aber hinterfrage meine Arbeit und teile Feedback, damit ich Inhalte verbessern kann. Danke!