Aus der Berufspraxis: Fehlentscheidungen der Webentwickler

Seit nun über 10 Jahren entwickle ich Web Apps. In diesem Zeitabschnitt hatte ich mit Entwicklern unterschiedlicher Schichten zu tun: Von blutigem Anfänger bis zum Vollprofi, Freelancer und Festangestellte. Die Zusammenarbeit im Team hat viele nützliche Dinge offenbart, darunter auch die amateurhafte Vorgehensweise an bestimmte Worklflow-Abschnitte, die am Ende für mehr Komplexität, Zeitaufwand und Durcheinander im Projekt gesorgt haben. Ein paar Beispiele anbei.

1. Schnell, Hauptsache online
Anstatt nach der Fehlerursache im Quelltext zu suchen, wird gern drumherum gebastelt, um das “(Bohr)Loch” abzudichten. Handelt es sich um einen kritischen Fehler mit hoher Priorität, so mag ein rascher Workaround in der Tat eine wirkungsvolle Notlösung sein. Andernfalls soll die Zeit genommen und dem Bug auf den Grund gegangen werden. Erst dann können Aspekte wie Sicherheit, Performance, Kompatibilität, Codearchitektur, Tests und Dokumentation ausreichend berücksichtigt und tatkräftig umgesetzt werden. Fehlt aktuell die eingeschätzte Zeit für eine vollständige Fix-Implementierung, gehört der Punkt zur späteren Erledigung auf die Todo-Liste gesetzt und sollte schnellstmöglich nachgeholt werden.

2. Fehlender Vorschaubereich für den Kunden
Ein Dev(eloper)-Server (gern eine Virtualisierung auf lokalem Rechner) dient ausschließlich der internen Entwicklung. Der Kunde hat nie den Zugang zum Entwicklungssystem und wird somit fern von der “Kochstube” gehalten. Auf der Test- bzw. Stage- bzw. Preiview-Umgebung bekommt die Kundschaft dagegen einen Stand des Fortschritts zur Verfügung gestellt, der letztendlich auf dem Live-Server automatisiert oder manuell gespiegelt wird. Der Zwischenschritt, sozusagen.

Vorteil dieser Vorgehensweise: Auf Dev kann unbesorgt weitergeschraubt werden, um weitere Meilensteine im Hintergrund zu erreichen. Der Kunde wiederum prüft das Projekt samt Neufunktionen in aller Ruhe auf Stage. Bei Freigabe erfolgt eine direkte Beförderung des kontrollierten Zustandes auf Live.

3. Mangelhafte Aktualität der Entwicklungsumgebung
Die Entwicklungsumgebung (Dev) wird – Dank dem nicht wegzudenkenden Stress und enormen Zeitdruck seitens Kunde – öfters stiefmütterlich behandelt. Vor allem bei der Pflege des Inhalts ist Faulheit der Programmierer zu beobachten. Auch wenn der Content der Webseiten dynamisch aus der Datenbank generiert wird (das ist zum Beispiel bei CM- und Shop-Systemen der Fall), soll dieser stets fleißig gepflegt werden. Ausreden wie “Live sind die notwendigen Bilder ja da, wird schon passen.” dürfen unter Entwicklern keine Akzeptanz und Gültigkeit finden.

Bestenfalls bedient man sich der Live-Umgebung mit – hoffentlich – aktuellem Stand, schnappt sich ein paar Artikel und pflegt sie auf der Entwicklungsplattform nachträglich ein. Automatisiert per Datenbank-Synchronisierung oder manuell nach Bedarf. Es muss nicht unbedingt der inhaltliche Gesamtumfang der Live-Umgebung kopiert werden, wenige Einträge samt Medien reichen vollkommen. Hauptsache man arbeitet unter realen Bedingungen mit z.B. Texten in richtiger Länge, Grafiken korrekter Größe. So kann jede so unwichtige Fallunterscheidung auf ihre Richtigkeit und Vollständigkeit getestet und spätere Überraschungen auf der Produktivumgebung vermieden werden. Ordnung muss sein!

4. Aktualisierungen am letzten Arbeitstag
Unprofessionel und verantwortungslos: Kurz vor dem Wochenende oder Urlaub eine Aktualisierung der Website durchführen. Nicht selten decken ausgeführte Tests nur einen Bruchteil potentieller Fehler auf. Selbst zusätzliche Prüfvorgänge durch den Kunden lassen Mängel im Funktionsumfang unentdeckt verbleiben. Eventuelle Besucherhinweise auf vorhandene Ungereimtheiten können an den Wochenendtagen kaum wahrgenommen werden. Der kritische Fehler bleibt über mehrere Tage hinweg bestehen. Ärgerlich.