Defensive Software bauen
· Matt Senter
Vor Kurzem ging meinem Laptop der Akku aus und er schaltete sich ab. Nachdem ich ihn eingesteckt und neu gestartet hatte, funktionierte Comoji nicht mehr. Ich tippte ein Emoji-Kürzel, und nichts passierte. Keine Erklärung, kein Hinweis darauf, dass sich irgendetwas geändert hätte. Nur eine App, die vor dem Herunterfahren funktioniert hatte und jetzt offenbar nicht mehr.
Comoji ist meine kleine Mac-App, die Emoji-Autovervollständigung in den Textfeldern bietet, die du ohnehin schon benutzt. Ihre Aufgabe ist simpel: ein Kürzel erkennen, passende Emojis anbieten und dir nicht im Weg stehen. Wenn das ausbleibt, ist von dem Produkt nicht mehr viel übrig, womit man interagieren könnte.
Nur war Comoji gar nicht kaputt. Es respektierte eine Sicherheitsgrenze, hinter der etwas anderes auf meinem Rechner stecken geblieben war.
Warum kann das Richtige zu tun so aussehen, als würde man nichts tun?
macOS hat eine Funktion namens Secure Input (sichere Eingabe), die sensible Tastatureingaben davor schützt, von anderen Prozessen abgefangen zu werden. Das ist wichtig für eine App wie Comoji, die erkennen muss, was du tippst, um eine Autovervollständigung anzubieten. Ein Emoji-Werkzeug hat nichts dabei verloren, dir bei der Eingabe eines Passworts zuzusehen, also hält sich Comoji bewusst zurück, solange Secure Input aktiv ist.
In diesem Fall tauchte Chrome als der Prozess auf, der Secure Input hielt, obwohl ich gar kein Passwort mehr eingab. Ich beendete Chrome zwangsweise und erwartete, dass sich die Sache damit erledigt. Stattdessen blieb Secure Input aktiv, und nun war es dem Anmeldeprozess von Apple zugeordnet. Was auch immer nach dem Neustart schiefgelaufen war, das Schließen des Browsers hatte nicht gereicht, um es zu beheben.
Das ist eine Klasse von Problemen, die Apple selbst dokumentiert hat. Eine Anwendung, die Secure Input aktiviert lässt, wenn es nicht mehr gebraucht wird, kann andere Anwendungen stören, die auf Tastaturereignisse angewiesen sind, selbst nachdem die verursachende Anwendung in den Hintergrund gewechselt ist. Der Sicherheitsmechanismus tut weiter seine Arbeit, aber Software an anderer Stelle auf dem Rechner trägt die Folgen.
Genau in dieser Lage war Comoji. Es weigerte sich zu Recht zu arbeiten, solange das System sagte, dass Tastatureingaben geschützt werden müssen. Aber nichts davon war für mich sichtbar. Ich hatte die App geschrieben, und selbst ich sah zunächst nur, dass sie nicht mehr funktionierte.
Ein Nutzer sollte nicht den Zustand des Betriebssystems untersuchen müssen, um zu verstehen, warum seine Emoji-Kürzel plötzlich nichts mehr tun.
Warum ist „nicht mein Bug“ keine vollständige Antwort?
Die Versuchung ist verständlich, mit dem Nachforschen aufzuhören, sobald feststeht, dass ein Problem außerhalb des eigenen Codes entsteht. Chrome hielt Secure Input. Dann war Apples Anmeldeprozess beteiligt. Comoji verhielt sich genau wie vorgesehen. Fall abgeschlossen, oder?
Nicht wirklich. Das erklärt, wer das Problem verursacht hat, aber es hilft der Person nicht, die meine App benutzen will. Sie schaut nicht darauf, welchem Prozess was gehört, und entscheidet nicht, welches Unternehmen einen Fehlerbericht verdient. Sie schaut auf Comoji und fragt sich, warum es nicht funktioniert.
Das zugrunde liegende Eingabeproblem lag außerhalb von Comoji. Die fehlende Erklärung war etwas, das ich beheben konnte.
Hier geht defensive Softwareentwicklung über das Prüfen ungültiger Argumente und das Abfangen von Ausnahmen hinaus. Man muss auch darüber nachdenken, wie die eigene Anwendung aussieht, wenn die Umgebung um sie herum aufhört, sich korrekt zu verhalten. Kann der Nutzer eine bewusste Pause von einem Absturz unterscheiden? Weiß er, was die App am Funktionieren hindert? Hat man ihm einen sinnvollen nächsten Anlaufpunkt gegeben?
Technisch im Recht zu sein ist wenig Trost, wenn das eigene Produkt kaputt aussieht.
Was habe ich geändert? Ein kleines Schloss statt eines Rätsels
Ich habe dem Menüleistensymbol von Comoji einen kleinen Schloss-Indikator hinzugefügt, der erscheint, sobald Secure Input aktiv ist. Jetzt gibt es einen sichtbaren Grund für die fehlende Autovervollständigung: Comoji pausiert, weil Tastatureingaben geschützt sind. Die App präsentiert nicht mehr stillschweigend eine nicht verfügbare Funktion, als müsste sie funktionieren.
Außerdem habe ich das Tray-Menü mit einem Hilfeartikel verknüpft, der erklärt, was Secure Input ist und warum Comoji es respektiert. Wer feststeckt, erreicht diese Erklärung direkt aus der App, statt die richtigen Suchbegriffe erraten oder mich kontaktieren zu müssen, um überhaupt zu erfahren, dass es diese Systemfunktion gibt.
Entscheidend ist, was ich nicht zu lösen versucht habe. Die Antwort bestand nicht darin, den Passwortschutz zu umgehen, nur damit die Emoji-Autovervollständigung läuft. Dass Secure Input aktiv ist, ist für sich genommen kein Fehler. Es gibt es aus gutem Grund, und Apple warnt ausdrücklich, dass das Aktivieren der sicheren Tastatureingabe andere Apps beeinträchtigen kann, die diese Tastenanschläge brauchen.
Das Schloss vermittelt also einen Zustand, keine Krise. Bei einer normalen Passworteingabe erklärt es, warum Comoji vorübergehend nicht verfügbar ist. Wenn dieser Zustand unerwartet anhält, gibt es dem Nutzer einen Ausgangspunkt, um zu verstehen, was passiert ist.
Ich habe Chrome oder macOS nicht davor bewahrt, sich aufzuhängen. Ich habe ihr Aufhängen für jemanden, der Comoji benutzt, weniger verwirrend gemacht, ohne den Schutz zu schwächen, den Comoji respektieren sollte.
Warum bleiben große Unternehmen externe Abhängigkeiten?
Es hat etwas Ärgerliches, ein winziges Werkzeug gegen Probleme abzusichern, an denen Googles Browser und Apples Betriebssystem beteiligt sind. Das sind keine obskuren Komponenten, die ich unbedacht ins Projekt geschleppt hätte. Es sind Produkte zweier riesiger Technologiekonzerne, und trotzdem hat ihr Verhalten es geschafft, meine kleine App defekt aussehen zu lassen.
Aber ihre Größe ändert nichts an der technischen Entscheidung. Ich kann Comoji nicht auf der Annahme aufbauen, dass sich alles, was ein größeres Unternehmen als meines herstellt, immer korrekt verhält. Ich kann einem frustrierten Nutzer auch nicht sagen, das Problem gehöre einem hinreichend beeindruckenden Unternehmen, und meine Arbeit damit als erledigt betrachten.
Ich weiß nicht, wie häufig genau diese Abfolge vorkommt. Vielleicht ist sie ungewöhnlich. Aber ich habe sie erlebt, und das Ergebnis hat eine nützliche Unterscheidung offengelegt: Comoji ging mit der Sicherheitsbedingung bereits sicher um; mit der daraus entstehenden Verwirrung ging es noch nicht gut um.
Das heißt nicht, dass jeder hypothetische Fehler eine neue Einstellung, einen Warndialog oder ein Wiederherstellungs-Subsystem verdient. In diesem Fall war die Antwort klein und bezog sich direkt auf das Problem. Ein Schloss-Symbol machte den Zustand sichtbar. Ein Hilfeartikel machte ihn verständlich. Keines von beidem verlangte, so zu tun, als könnte ich eine fremde Anwendung aus meiner eigenen heraus reparieren.
Für mich ist das ein wichtiger Teil davon, defensive Software zu bauen. Die eigene Verantwortung endet nicht damit sicherzustellen, dass der Code funktioniert, wenn alles um ihn herum funktioniert. Man muss auch entscheiden, was passiert, wenn er seine Aufgabe nicht erfüllen kann, auch dann, wenn der Grund der Fehler von jemand anderem ist.
Manchmal ist das richtige Verhalten, anzuhalten. Gute Software sollte dir sagen können, warum.