Die etwas andere Sicht auf das Schreiben von Quellcode

Usability Engineering von und für Entwickler
Kommentare

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 Website. 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. B. durch entsprechende Reviews oder Checklisten erfolgen.

Die magische 7

Oft ist die magische Zahl 7 schon bekannt. So weiß ich als Backend-Entwickler bereits, dass es in einem Menü nicht ratsam ist, mehr als sieben Punkte anzuzeigen, da das menschliche Gehirn nicht mehr als sieben Elemente gleichzeitig erfassen kann. Um es nicht ganz so hart zu machen – zumal jeder Mensch auch etwas unterschiedlich ist – wird auch oft von 7 +/- 2 gesprochen, die maximale Anzahl liegt also zwischen fünf und neun. Selbst als Backend-Entwickler wenden wir diese Regel also bereits meist für die Besucher unserer Website an.

Allerdings tritt dieses Prinzip, dass Informationen gleichzeitig aufgenommen werden müssen, auch sehr häufig im Quellcode auf. So sollte man auf eine maximale Anzahl Elemente auch z. B. in folgenden Bereichen achten:

  • Zeilen in einer Funktion
  • Methoden in einer Klasse
  • Dateien in einem Verzeichnis

Explizit herausnehmen möchte ich hier die Anzahl der Parameter für eine Funktion. Meiner Meinung nach sind fünf Parameter bereits zu viel. Und zwar nicht weil diese fünf Parameter nicht entsprechend aufgenommen werden können, sondern weil der Nutzen der Funktion extrem verwässert wird und auch einem Code-Smell entspricht, der auf eine zu enge Kopplung der Funktion zu externen Abhängigkeiten hindeutet.

Personas

Denken wir mal an unser letztes großes Projekt zurück: Wurde hier entsprechend über weitere Entwickler nachgedacht, diese evtl. sogar einbezogen? Wurden bestimmte Entwicklerkreise (z. B. Juniors) ausgeschlossen?

Ein übliches Mittel zur Verbesserung der Usability ist die Definition von Personas. Dabei wird der typische User (in unserem Fall ein Entwickler) und ein Szenario definiert. Hierbei handelt es sich um fiktive Personen, deren Profil aber einem zukünftigen Entwickler entspricht. Ein Beispiel:

  • Ben
  • 25 Jahre alt
  • Ausbildung als Informatiker
  • Zwei Jahre Erfahrung mit PHP
  • Ein Jahr Erfahrung mit JavaScript
  • Keine Erfahrung mit AOP

Die Profile dürfen ruhig einen Namen bekommen, sodass man besser über sie diskutieren kann; gerne sogar mit Bild. Jedem Profil sollten auch mehrere Szenarien zugeordnet sein, welche Aufgaben der User später zu erfüllen hat: „Ben soll zukünftig regelmäßig in der Lage sein, neue Landing Pages in das System zu integrieren.“ Sollte sich nun der Softwarearchitekt dazu entscheiden, eine AOP-Lösung zu implementieren, wird er Ben und alle andere Kollegen, die auf dieses Profil passen, aufwändig schulen müssen oder sich evtl. vorab für eine andere Lösung entscheiden. Das mag dann zwar auf den ersten Blick nicht dem State-of-the-art-Wissensstand des Architekten und der Seniorentwickler im Team entsprechen, allerdings ist eine benutzerfreundliche Software zu schreiben u. U. eine noch viel herausforderndere Aufgabe.

Hier sollte ggf. aber mehr als ein Profil bedacht werden. Oft gibt es die verschiedensten Arten von Usern, die auch unterschiedliche Anforderungen haben. Manchmal ist es sogar sinnvoll, einige Features mehrfach zu implementieren, um dem Junior z. B. ein abgespecktes Webinterface anzubieten, während der etwas erfahrenere Entwickler ein ausführliches CLI-Tool mit allen möglichen Optionen zur Installation der Software bekommt.

Eindeutige Sprache

Einer der wichtigsten Punkte, der auch immer wieder vernachlässigt wird, ist das Herbeiführen einer eindeutigen Sprache. Während evtl. noch jeder im Team die benutzten Design Patterns eindeutig identifizieren kann, wird es spätestens bei der Domänensprache des Businessprozesses oft sehr schwammig und zweideutig. Hier finde ich den Ansatz vom Domain-driven Design von Eric Evans großartig, eine eindeutige Sprache über alle Projektbeteiligten zu finden. Während Entwickler unter sich schon gerne aneinander vorbeireden, kommt das noch viel häufiger vor, wenn gleichzeitig Projektmanager und auch noch der Kunde am Tisch sitzen, die alle einen komplett unterschiedlichen Hintergrund haben. Die Einführung eines Glossars, der die wichtigsten Begriffe eindeutig klärt, ist ein sehr gutes Mittel. Darüber hinaus kann das auch jederzeit erweitert und aktualisiert werden. Die Erstellung des Glossars sollte aber nicht die Aufgabe eines Einzelnen sein, sondern gemeinsam definiert und auf die Einhaltung geachtet werden. Das führt im Idealfall dazu, dass auch der Kunde einfacher mit dem Entwickler über Geschäftsprozesse oder aber auch Softwarearchitektur sprechen kann. Die Begrifflichkeiten dieses Glossars sollten sich dann auch im Quellcode wiederfinden und dort keine eigene Entwicklersprache herrschen.

Die Softwareentwicklung an einen günstigeren Standort zu verlagern, ist hier übrigens äußerst kontraproduktiv. Nicht nur erschwert die Distanz die Kommunikation, so ist auch in Zeiten von zuverlässiger Videotelefonie das Sitzen an einem gemeinsamen Tisch immer noch der beste Weg, um sich auszutauschen und kennenzulernen. Auch darf der unterschiedliche kulturelle Hintergrund nicht unterschätzt werden: So sind im indischen Raum übliche Gepflogenheiten hier oft absolut unbekannt und sorgen für Missverständnisse oder sogar Abwehrhaltungen.

Einbindung von Usern

Die frühe Einbindung von zukünftigen Usern und damit auch Entwicklern ist eine sehr gute Methode, um für eine gute Usability zu sorgen. Das kann z. B. durch das Ausfüllen von Fragebögen oder das Erfüllen einer Testaufgabe erfolgen. Wichtig ist dabei aber, dass die Ergebnisse entsprechend messbar sind, um über die Zeit des Entwicklungsprozesses sehen zu können, ob die Usability besser oder schlechter geworden ist.

Sofern es keine Möglichkeit gibt, auf evtl. zukünftige Entwickler zuzugreifen, so kann man sich auch zunächst die Konkurrenzprodukte ansehen, wie diese mit dem Thema umgehen und wie einfach die Arbeit mit deren Software ist. Ansonsten trifft man Entwickler am besten auf Konferenzen, Hackathons oder User Groups. Um die Motivation zu steigern, funktioniert auch hervorragend ein Gewinnspiel, bei dem eine bestimmte Aufgabe zu lösen ist.

Denken wir noch mal an unser letztes großes Projekt zurück:

  • Auf welchem Weg gelangen denn die Anforderungen von Entwicklern in das System?
  • Wie gerne arbeiten die Entwickler heute noch mit dem System?
  • Welche Prozesse und Richtlinien müssen eingehalten werden? Geschieht dies immer?
  • Wie können Entwickler entsprechendes Feedback geben?

Prototyping

Ich hoffe, dass die meisten von uns regelmäßig das Glück haben, einen Prototyp entwickeln zu dürfen, dessen Code danach auch wirklich weggeschmissen wird. Denn auch mit der Code-Usability sollte man nicht dogmatisch umgehen; erst recht nicht, wenn der Quellcode danach nicht mehr gebraucht wird. Doch erfüllt der Zweck eines Prototyps zumeist die Validierung der primären Kundenwünsche, z. B. der Anbindung eines externen API oder aber der Präsentation eines User Interfaces.

Moment, User Interface! Auch hier können wir wieder an den Entwickler denken und z. B. Hierarchien, Datenbank, Klassenstrukturen und Schnittstellen vorab als Prototypen testen. Ich denke, hier kann man am besten zwischen drei Arten von Prototypen unterscheiden.

Zunächst wäre da die bloße Skizze, die am besten wirklich mit Papier und Bleistift gemacht wird. Das geht nicht nur sehr schnell, fördert das Teamwork und kann jederzeit geändert werden, sondern vermittelt vor allem auch den Eindruck, dass hier noch etwas geändert werden kann.

Die zweite Art von Prototyp geht dann schon ins Wireframing, in dem die Idee zumindest durch den Computer gezeichnet wird. Zum Beispiel ein Diagramm, das durch ein entsprechendes Programm generiert wurde. Auch wenn noch keine Zeile Quellcode geschrieben wurde, wirkt diese Art von Prototyp schon sehr viel festgefahrener und kann, wenn andere Entwickler nicht eingebunden wurden und die Beziehung zwischen dem Junior und Senior sowieso nicht die beste ist, schon zu Abwehrhaltungen führen.

Die dritte Art ist dann sicherlich die Implementierung eines Mocks, in dem die Funktionalität schon mal getestet werden kann.

Zunächst mag es nicht allzu logisch erscheinen, einen weniger erfahrenen Entwickler in dieser Phase mit an Bord zu nehmen, dennoch wird das zu Hinweisen – und damit Änderungen – führen, die später viel Zeit und Geld sparen können. Das Problem ist, dass die älteren Entwickler mit ihrer Erfahrung leider auch schnell einen Tunnelblick bekommen können und ein unerfahrenes Auge auf das Ganze sehr hilfreich sein kann.

Coding Styles

Durch entsprechende Vorgaben, die am besten im ganzen Unternehmen dieselben sind, kann die Usability von Quellcode langfristig verbessert werden. Insbesondere empfiehlt es sich, auf bestehende Standards wie z. B. die PSR-Reihe aufzusetzen. Da diese nicht nur bis ins Detail durchdacht und weit verbreitet ist, sondern auch von bestehender Software unterstützt wird und die Regeln automatisch einhält, prüft und ggf. korrigiert. Neben dem, dass z. B. PhpStorm mit Leichtigkeit den Quellcode entsprechend formatieren kann, gibt es auch SaaS-Lösungen wie Scrutinizer oder Code Climate, die auf die Einhaltung achten und Verbesserungsmöglichkeiten aufzeigen.

Aber auch hier gilt: Coding Styles sollten keinesfalls dogmatisch und blind verfolgt werden, sondern einen Mehrwert für das Gesamtprojekt bringen. Gute Coding Styles helfen dabei, dass Software schneller und einfacher erstellt werden kann. Sie sollten vom gesamten Team akzeptiert sein und gute Beispiele liefern.

Plant man die Entwicklung eines Coding Styles, sollte man sich folgende Fragen stellen:

  • Lohnt sich die Entwicklung eines eigenen Coding Styles wirklich?
  • Ist die Beschreibung ausreichend?
  • Können der Entwicklungsprozess und die Kommunikation weiter verbessert werden?

Definition von Schnittstellen

Insbesondere die Definition von Schnittstellen ist meiner Meinung nach die hohe Kunst der Usability für Entwickler. Dabei meine ich nicht nur öffentlich verfügbare Web-APIs, sondern der Aufruf von Methoden, Ausführen von bestimmten Prozessen und Handling von Objekten. Eins spielt mit dem anderen zusammen. Es gibt oft sehr viele Optionen, die definiert werden können – auf Funktionalität verzichten möchte man aber auch nicht. Dies fängt schon damit an, welche Methoden man private, protected, public oder vielleicht auch final definiert. Während man genug Möglichkeiten zur Verfügung stellen möchte, um die aktuelle Funktionalität auch entsprechend erweitern zu können, kann zu viel Freiheit und Information auch schädlich sein und sollte vermieden werden.

Bei GUIs wird beispielweise darauf geachtet, dass kritische Felder keinen Standardwert bekommen, sodass der User sich hier aktiv für eine Option entscheiden muss. Auch das kann im Quellcode angewendet werden, indem Parameter keine Default-Werte bekommen und evtl. sogar schon bei der Initialisierung des Objekts im Constructor benötigt werden. Aber Vorsicht, auch hier muss man abwägen: Zu viel notwendige Konfiguration erhöht den Lernaufwand und verhindert gleichzeitig gute Usability. Die Mehrfachbelegung von Parametern ist zu vermeiden und zudem auch als Code-Smell bekannt.

Auch Ausnahmen sollten behandelt werden. Was passiert, wenn ein unerwarteter Fehler auftritt? Erzeugt dieser eine Exception oder ändert sich der Rückgabewert? Wo bekommt man detaillierte Informationen über den aufgetretenen Fehler und wohin werden diese geloggt?

Mehr als nur Quellcode

Auf den Code alleine zu achten, genügt aber nicht. Ist ein Stück Software erst einmal im Einsatz, kann man aktiv durch das Anbieten von Trainings und Zertifizierungen die Erfahrung mit dem System verbessern.

Auch das Schreiben einer Dokumentation ist ein Punkt, der nicht vernachlässigt werden sollte –hier trennt sich sehr schnell die Spreu vom Weizen. Die Dokumentation muss wiederum für mehrere User zugänglich sein, sowohl für den Einsteiger als auch für den erfahrenen Experten.

Nun kann des Weiteren aktiv Feedback von den Usern eingeholt werden. Was funktioniert gut und was weniger gut? Vorfälle, die aufgetreten sind, sollten nicht nur aufgenommen sondern auch analysiert werden.

Fazit

Sollten wir wieder einmal das Problem haben, dass unser so lieb gewonnener Quellcode auf Abneigung stößt, liegt das evtl. nicht nur daran, dass der Kollege einfach keine Ahnung hat, sondern dass wir evtl. auch nicht entsprechend über die Usability für unseren Kollegen nachgedacht haben. Nicht jeder ist auf demselben Wissenslevel, und dennoch sollten wir zusammen arbeiten. Hier hilft es, einen Schritt aufeinander zuzugehen und die Erwartungen frühzeitig einzusammeln.

Damit unsere Software verwendet wird, muss sie auch einfach und effizient zu bedienen sein, ansonsten landen wir bald selbst in der Schublade Legacy-Code, und man wird einen großen Bogen darum machen. Der Faktor Mensch spielt auch bei der Softwareentwicklung eine zentrale Rolle.

Ich selbst bin beim Versuch, über den Tellerrand zu blicken und etwas über GUI-Usability zu lernen, auf das Buch „Usability Engineering kompakt“ gestoßen. Wer also mehr über Usability Engineering im Allgemeinen wissen möchte, dem kann ich das Buch als Einstieg nur empfehlen.

Windows Developer

Windows DeveloperDieser Artikel ist im Windows Developer erschienen. Windows Developer informiert umfassend und herstellerneutral über neue Trends und Möglichkeiten der Software- und Systementwicklung rund um Microsoft-Technologien.

Natürlich können Sie den Windows Developer über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist der Windows Developer ferner im Abonnement oder als Einzelheft erhältlich.

Aufmacherbild: Designing mechanical parts by engineer via Shutterstock.com / Urheberrecht: Shaiith

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -