© saicle/Shutterstock.com
Die etwas andere Sicht auf das Schreiben von Quellcode

Usability Engineering von und für Entwickler


Usability ist eigentlich ein Thema für Designer, UX-Experten und vielleicht noch Projektmanager. Außer der Implementierung von Usability-Features haben wir als Entwickler meist wenig Kontakt mit Usability und dementsprechend auch wenig Erfahrung darin. Wozu auch? Schließlich gibt es Experten auf diesem Gebiet, die genau wissen, wie das Produkt zu funktionieren hat. Doch was passiert, wenn wir den Begriff „User“ an sich einmal überdenken?

Wer ist denn alles ein User unserer Software? Natürlich der Endanwender; häufig also der Besucher einer Web­site. Oft wird auch noch an den Redakteur oder Adminuser gedacht, der die Seite dann über ein entsprechendes Interface pflegen darf. Aber auch hier wird schon sehr häufig der Entwickler selbst zum einzigen, der für die Usability verantwortlich ist. Wer denkt aber daran, dass der Quellcode auch über den Launch hinaus gepflegt werden muss? Vielleicht sogar eine Zeit übersteht, in der der aktuelle Entwickler gar nicht mehr abrufbar ist? Meiner Meinung nach sind alle zukünftigen Entwickler, die mit meinem Code arbeiten müssen, eindeutig User meines Quellcodes.

Clean-Code, SOLID, KISS, DRY, TDD und viele weitere Prinzipien und Techniken sind inzwischen gut in der PHP-Welt angekommen. Viele Entwickler beten sie herunter, und es scheint so, dass PHP endlich erwachsen geworden ist. Dennoch haben wir weiterhin große Probleme, dass unser jetzt „cleaner“ Code von anderen Entwicklern angenommen wird. Zu kompliziert, nicht gut strukturiert oder auch einfach eine fehlende Dokumentation sind die typischen Themen, mit denen fast jeder zu kämpfen hat. Manchmal mehr oder weniger nachvollziehbar, aber wer hat denn noch nie über den Legacy-Code in der Firma gemeckert? Folgen von schlechter Code-Usability sind z. B.:

  • Die Entwickler arbeiten nicht so effektiv wie geplant.

  • Es gibt viele Rückfragen an die erfahreneren Kollegen.

  • Die Qualität der neuen Features wird immer schlechter.

  • Das Training von neuen Entwicklern dauert sehr lang.

  • Entwickler, die neu im System sind, erzeugen immer wieder „Fehler“.

  • Das System läuft nur unter ganz bestimmten Voraussetzungen (z. B. nur unter einer PHP-Version).

Im schlimmsten Fall wird das bestehende System auch einfach umgangen, um neue Features zu implementieren.

Jetzt kann man sich natürlich zurücklehnen und auf die – falls überhaupt vorhandene und noch aktuelle – Dokumentation verweisen und den Kollegen raten, sich entsprechend fortzubilden und in das System einzuarbeiten. Sicherlich ist der kontinuierliche Lernprozess in unserem Beruf ein sehr wichtiger Faktor, allerdings passiert so viel in diesem schnelllebigen Umfeld, dass es unmöglich ist, immer über alle neuen Techniken Bescheid zu wissen. Auch wenn ich selbst ein Technik-Geek bin und in meiner Freizeit sogar gerne auf Hackathons und User Groups gehe, muss ich auch akzeptieren, dass nicht jeder dazu bereit ist, all seine Zeit dafür zu opfern. Für manchen ist das Programmieren einfach nur ein Beruf und keine Berufung. Ich möchte, dass jeder User und auch Juniorentwickler sich in meinem Code zurechtfinden kann und es ihnen einfach gemacht wird, damit arbeiten zu können.

Wer ist denn jetzt aber dafür verantwortlich, dass der Quellcode auch für meinen Nachfolger benutzbar ist? Meist leider niemand, dann kümmert sich jeder Entwickler ein bisschen selbst darum. Manchmal gibt es entsprechende Softwarearchitekten im Team, die auch diesen Bereich zu verantworten haben. Sie sind dann aber ständig dabei, alle Bälle in der Luft zu halten und müssen auch weiterhin dafür sorgen, dass der detailverliebte Entwickler zufrieden ist, die Kosten nicht steigen, der Zeitrahmen nicht gesprengt wird und dennoch regelmäßig neue Features implementiert werden.

Ziele

Eigentlich ist es selbstverständlich, dass der Quellcode gut verständlich sein soll. So, dass man sich leicht darin einarbeiten kann. Oft fehlt es aber leider an konkreten Maßnahmen, die ergriffen werden können, um dieses Ziel wirklich zu erreichen.

Zudem sollten die Ziele klar definiert und im Idealfall messbar sein. Das könnte z. B. sein:

  • die Anzahl der notwendigen Schritte für die Integration eines Features minimieren

  • den Trainingsaufwand verringern

  • die Entwicklungsgeschwindigkeit erhöhen

Ein iteratives Vorgehen ist dafür übrigens ideal geeignet, denn oft werden Probleme in der Usability erst spät erkannt und können so auch nach der Entwicklung eines Moduls durch Refactoring optimiert werden.

Auch als Kunde einer Agentur sollte man darauf achten, dass das Thema Code-Usability entsprechend im Vertrag definiert wurde und messbar ist. Dies kann z....

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang