© saicle/Shutterstock.com
PHP Magazin
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?

Tobias Zander


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 nu...

PHP Magazin
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?

Tobias Zander


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 nu...

Neugierig geworden?


   
Loading...

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