Tobias
Herzlich willkommen zur neuesten Folge vom Sandpapier-Podcast. Wir heißen euch herzlich willkommen zurück aus unserer Sommerpause. Wir haben jetzt schon Oktober und bald stehen die Herbstferien vor der Tür, aber für uns war noch ein bisschen Urlaubszeit. Deswegen gab es jetzt ein paar Wochen keine Sandpapier-Folge. Heute sind wir zurück und wollen jetzt auch wieder unseren regelmäßigen Rhythmus aufnehmen. Mal schauen, wie gut uns das gelingt. Die heutige Folge soll sich um das Thema Structured Debugging drehen. Also wieder mal eine technische Folge nach den nicht so technischen Folgen, die wir in letzter Zeit hatten. Wir hatten ja das Thema Agribora, das Projekt, was wir vorgestellt haben und auch das Thema Diversität in den letzten Folgen. Heute wird es mal wieder technisch. Ich habe zwei Gäste dabei. Ich, das ist der Tobias wieder heute für euch, der Moderator. Und als Gast, als Gäste habe ich den Christoph Dähne zur Gast. Hallo Christoph.
Christoph
Hallo Tobias!
Tobias
Und den Sebastian Kurfürst habe ich wieder mit dabei. Hallo Sebastian. Hi. Ihr seid ja zwei unserer, ja, ich sag mal, Techie-Techies. Ihr kennt euch gut aus und wir wollen ja heute vor allem über das Thema Debugging sprechen. Also was machen, wenn es nicht so läuft, wie es geplant war oder Dinge passieren, die, ja, überraschen. Nennen wir es mal freundlich. Der User würde vielleicht sagen, wenn die Anwendung kaputt ist und überhaupt nicht macht, was er soll. Lass uns doch vielleicht direkt mal dort einsteigen. Ich denke, die Hörerinnen und Hörer haben hoffentlich schon mal einen Podcast mit euch beiden gehört. Aber sag nochmal ganz kurz, wo euer technischer Fokus liegt zur Einordnung. Christoph, fang nochmal an. Wo liegt bei Sandstorm für dich der technische, also dein technischer Fokus in Sandstorm?
Christoph
Naja, bei Sandstorm, ich bin ja nun schon sehr lange dabei. Die fünf Jahre sind überschritten, das macht auch immer noch Spaß. Da liegt der Fokus natürlich auf dem ganzen großen Thema Web. Und ich habe meine Lieblingsprogrammiersprachen und ich habe auch meine Lieblingsaufgaben. Aber ich gebe mir natürlich trotzdem Mühe, dann auch so eine Web-Applikation im ganzen Blick zu haben. Wie wird das Aussehen gesteuert? Wie wird der Ablauf gesteuert auf dem Server und vielleicht auch in einem Bridge-Client im Browser? Und wie muss das Ganze dann installiert und deployed werden? Und was passiert, wenn das Ding mal ungeplant offline geht? Wie merkt man das überhaupt, das ganze Thema Monitoring? Und wir versuchen bei Sandstorm den ganzen Stack zu bedienen. Das läuft inzwischen manchmal unter DevOps, manchmal unter Full Stack. Das hat verschiedene Namen und da bin ich unterwegs. Am allerliebsten, also wenn ich es mir jetzt wirklich aussuchen kann, mache ich aber Sachen, die man nicht sieht. Also keine Oberflächen, sondern eher Komponenten, die ein bisschen im Hintergrund sind. Das ist einfach persönlicher Geschmack.
Tobias
Danke dir. Sebastian, wie sieht es bei dir aus?
Sebastian
Ja, bei mir ist es eigentlich sehr, sehr bunt gemischt. Es ist ähnlich wie bei Chris. Also ich bin ja sozusagen von der ersten Stunde von ZenStorm dabei. Und ja, ich habe mich eigentlich schon überall auch ziemlich lange und ziemlich intensiv getummelt. Und das ist immer ein bisschen unterschiedlich. Ja, in letzter Zeit mache ich gerade manchmal wieder Frontend relativ viel in React und React Native. Also Frontend und Mobile-Anwendungen, aber auch in letzter Zeit viel Infrastruktur und größere Backend-Konzepte und Sachen gemacht. Ich bin häufig nicht mehr so viel am entwickeln. Ich mache häufig, ich sage jetzt mal, Projekt-Start und Projekt-Landung, würde ich es mal nennen. Also ich bin häufig sozusagen am Anfang des Projekts besonders involviert, wenn es darum geht, welche Technologien wählen man aus, welche Trade-offs, also welche Abwägungen hängen damit dran und am Gegenende, wenn dann zum Beispiel halt produktive Probleme auftreten und man gucken muss, okay, wie kann man damit umgehen, was uns, denke ich, Richtung des Debuggings heute bringt.
Tobias
Du möchtest direkt schon die Brücke schlagen ins Thema rein. Dann lass uns doch mal anfangen. Debugging. Wenn du das Wort hörst, Sebastian, was passiert dann bei dir im Kopf? Worum geht's da?
Sebastian
Debugging, genau, das besteht ja aus zwei Teilen, also das Wort Bug, also Fehler ist da drin und die halt sozusagen den Fehler rausmachen, den Fehler finden, das ist also das, worum es geht. Das heißt, eine Anwendung oder ein Programm oder eine Web-Oberfläche verhält sich nicht so, wie der Nutzer es erwartet erstmal. Und jetzt geht es also beim Debugging darum, rauszufinden, was denn eigentlich das Problem dabei ist, also sozusagen von dem sichtbaren Effekt dorthin zu kommen, wo eigentlich die Ursache begraben liegt. Und das kann teilweise an ganz, ganz unterschiedlichen Stellen liegen. Also das heißt, das, was man sieht, hat nicht zwangsläufig was damit der Ursache zu tun, sondern es kann teilweise ein ganz, ganz weiter Weg sein von einem einen zum anderen Ort. Und es ist auch ein sehr spannender Weg im Übrigen, weil man da meistens sehr, sehr viel lernt.
Tobias
Okay. Jetzt hast du es ganz stark aus Nutzer-Sicht beschrieben. Der Nutzer stellt ein Problem fest. Ist Debugging schon ein Thema, wenn eine Anwendung entwickelt wird für uns?
Sebastian
Ja, schon. Also ich sag mal, ich würde sagen, es gibt so zwei Arten von Debugging. Also es ist sozusagen einmal, wenn ich eine Anwendung entwickle und ich baue was und ich baue eine kleinere Funktionalität und ich teste das und ich sehe, ah, das tut nicht das, was ich will, dann brauche ich auch eine Art von Debugging. Also da habe ich das schon auch. Also da muss ich mir quasi angucken, warum geht das nicht und muss irgendwie einen strukturierten Weg finden, schrittweise herauszufinden, woran es denn liegt, was jetzt nicht geht oder was aber gehen sollte und dann später, wenn die Anwendung halt produktiver ist oder produktiv ist, da wird es meistens komplizierter, das herauszufinden, weil es sozusagen mehr Stellschrauben gibt. Also ich habe teilweise ganz viele Nutzer auf dem System, ich habe eine hohe Last. Da gibt es sozusagen ganz viel mehr Faktoren noch, die eine Rolle spielen und die das unter Umständen sehr viel schwerer machenden Fehler einzuschränken.
Tobias
Jetzt müssen wir uns mal eins von diesen Themen rauspicken und damit anfangen. Christoph, kannst du dich an Debugging erinnern, was so in letzter Zeit bei dir passiert ist und mal kurz eine Situation beschreiben, wie ist das für dich so abgelaufen?
Christoph
Ja, da fällt mir ein Thema ein, was mich tatsächlich länger begleitet hat und das war auch ein etwas anspruchsvolleres Debugging aus verschiedenen Gründen, weil das ist nur auf dem Produktivsystem aufgetreten. Wenn ich irgendwas entwickle und ich starte das Lokal, habe ich ja extrem viel Kontrolle über die Applikationen und auch über die ganze Umgebung, das ist bei mir auf dem Rechner und ich kann in Anführungszeichen damit machen, was ich will und ich kann auch da richtig genau reingucken. Das geht natürlich nicht, wenn das Ding irgendwo auf dem System installiert ist, wo ich mich vielleicht einloggen kann, in dem Fall konnte ich nicht mal das und dann bleiben mir nur die Log-Ausgaben, die ich vorher selber eingebaut habe, um dort Informationen zu sammeln. Und da hat es halt entsprechend länger gedauert, dann den Fehler zu finden.
Tobias
Da sprichst du schon eine Herausforderung sozusagen an. Also ich habe jetzt verstanden, das eine ist das, was bei mir lokal auf dem System passiert, mit dem ich entwickle und was auf der Produktion passiert, auf dem Server vielleicht, wo die Web-Anwendung deployed ist, das kann was ganz anderes sein. Jetzt hast du den Fall angesprochen, du hast keinen Zugriff auf das System. Was hast du da gemacht? Du hast gesagt, du hast zwar Log-Ausgaben eingebaut, aber du kommst da nicht direkt ran.
Christoph
Ja, ja, das ist auch tatsächlich eine große Hürde an der Stelle. Also im Prinzip habe ich den Effekt gemeldet bekommen, den konnte ich auch beobachten, das funktioniert nicht. So, das habe ich auch selber so festgestellt, das ist ja schon mal das Erste und dann war natürlich die nächste Frage, ja, warum funktioniert das eigentlich nicht? Was passiert denn da, hat der überhaupt versucht, das zu machen oder ist der gescheitert und woran? Das sind die ersten Fragen und dann habe ich mir jemanden geschnappt, der auch freundlicherweise Zeit für mich hatte und habe ihn und habe nach bestimmten Ausschriften in den Logs gefragt. Also wenn ich eine Applikation habe auf dem Server und ich habe keine Oberfläche, wo ich Informationen darstellen kann, fallen Informationen natürlich trotzdem an und es ist auch gut und richtig, die irgendwo aufzufangen, genau für diesen Fall und da stand dann eine Fehlermeldung in den Logs, mit denen ich halt was anfangen konnte, da stand halt drin, es kann eine bestimmte Verbindung nicht aufgebaut werden, das andere System antwortet nicht.
Tobias
Okay, das heißt, erster Schritt ist, man bekommt irgendeinen Verhalten mitgeteilt, was nicht so ist wie erwartet und dann versucht man auszufinden, okay, kann ich das irgendwie nachstellen. Du hast gesagt, ja, ich habe selber mal aufs System geguckt und konnte sozusagen sehen, kann den Fehler nachvollziehen.
Christoph
Genau. Das Debugging besteht für mich aus zwei Schritten. Das erste ist die Diagnose von dem Fehler. Dann möchte ich quasi nur wissen, an welcher Stelle verhält sich das System anders als erwartet. Also wenn ich als Entwickler von meinem eigenen Programm überrascht werde, ist das meistens schlecht. Und danach ist die Erkenntnis aus der Diagnose Grundlage für den Fix.
Tobias
Okay, Diagnose und Fix. Sebastian, stimmst du Chris so weit zu? Ja.
Sebastian
Ja, ja, absolut. Was ich noch hinzufügen würde, wäre, dass dieses Hinterfragen oder dieses selber den Fehler sehen, was superwichtig ist. Weil, also Sprache ist ja etwas unscharf und wenn halt eine Aussage kommt, ja, etwas geht nicht, dann kann dieses geht nicht aus ganz vielen Dingen bestehen sozusagen, also in ganz verschiedenen Ausprägungen sein. Und deshalb ist es, und ein Endnutzer hat häufig andere Vorstellungen von, es geht was nicht, wie der Entwickler. Weil manchmal hat man auch den Fall der Entwicklerguck drauf und es verhält sich genauso, wie der Entwickler es gedacht hat, dann ist halt das Problem falsch formuliert gewesen sozusagen, haben wir das falsche entwickelt vielleicht. Und das heißt, dieser erste Schritt ist superwichtig, damit wir einen Einstieg haben in das Thema.
Tobias
Es kommt bestimmt auch vor, dass man ein Symptom gemeldet bekommt und wenn man sich sozusagen nur das Symptom anguckt, ist man an der völlig falschen Stelle, weil die eigentliche Ursache in einem ganz anderen Verhalten begründet liegt, was vielleicht zwei Schritte vorher in der Anbindung passiert ist. Okay, das kann das natürlich auch nochmal schwieriger machen. Also, die Diagnosephase, ganz wichtig, vorne ran stellen. Ich würde den Begriff Problem Space in den Raum werfen, das ist sozusagen, ich gucke mir erstmal das Problem an und versuche das nachzustellen. Jetzt haben wir die, Chris hatte ja auch gerade auf was Schönes hingedeutet, es gibt vielleicht ein Produktivsystem, wo der Fehler auftritt, das kann ich mir auch angucken, kann ich nachstellen sozusagen, also kann man den Fehler bewusst provozieren, um zu sehen, genau dieses Verhalten ist es, was zu diesem Fehlerbild führt, jetzt kann es ja sein, aber lokal funktioniert es, wenn es vor einem Entwicklungssystem…
Christoph
Ja, das kann passieren. Oh ja.
Sebastian
Das ist sogar auch recht häufig, muss man ehrlicherweise sagen. Und das liegt nicht daran, dass sich diese Systeme an sich so sehr unterscheiden. Also das Programm ist schon das Gleiche, was lokal läuft und was auf dem Zielsystem, auf dem produktiven System läuft. Sondern es ist häufig, dass sich halt die Umgebung unterscheidet. Also das kann halt sein, keine Ahnung, es ist eine andere Datenbank-Version verwendet. Es ist eine andere Linux-Version verwendet. Es gibt eine Firewall, also ein System, was sozusagen Netzwerkverbindungen unterdrückt, bestimmte und bestimmte durchlässt beispielsweise. Das sind alles mögliche Sachen, wie sich halt ein lokales System ganz intrinsisch von einem Produktivsystem unterscheidet, trotz aller Bemühungen, die man in den letzten Jahren hatte und auch hat. Stichwort Kontenarisierung und Docker. Das zu vereinheitlichen. Das hilft schon einen ganzen Schritt weit und einen großen Schritt weit, aber ganz weg wird das halt nicht gehen. Also das Produktivsystem wird halt immer irgendwie anders sein als das lokale System. Das ist auch, glaube ich, ganz normal.
Christoph
Ich würde da sogar noch einen Schritt weitergehen, die selbst, wenn man auf dem Produktivsystem selbst versucht, diesen Fehler auszulösen, klappt es oft nicht. Weil dort der Unterschied nicht in, das ist ja kein technischer Unterschied, aber es ist trotzdem ein Unterschied vom Verständnis, wo, wie man die Applikation benutzt, das kann ein Unterschied sein zu dem Zeitpunkt. Wenn ich jetzt lokal eine andere Datenbankversion habe, dann ist es, sage ich mal, etwas, das kann ich gut sehen und gut nachvollziehen, aber es kann schon einen Unterschied machen, dass ich der einzige Nutzer auf dem System bin oder dass der Rechner vielleicht aus anderen Gründen das Programm langsamer ausführt, weil ich halt im Entwicklungsmodus gestartet habe, weil ich halt an der Stelle mal Pause gemacht habe, man kann ja ein Programm mal kurz anhalten, also wenn man das entwickelt, kann man das, um mal zu gucken, so was ist denn jetzt hier so das Zwischenergebnis im Moment, das ist ja Teil der Fehlersuche, aber es hat natürlich Einfluss auf den späteren Ablauf manchmal und dann auch die ganz grundlegenden, sage ich, am Ende sind es ja Missverständnisse, ich als Entwickler höre mir quasi an, was möchten die Nutzer am Ende machen und entwickle ein Verständnis davon, von deren Bedürfnis und da können natürlich auch Unterschiede sein, wenn ich sage, na ja, ich fülle dann ein Formular aus und ich klicke auf absenden und dann ist es abgesendet, dann finde ich das erstmal, man macht das in meiner Welt Sinn und ich finde das total in Ordnung, aber dass ich jetzt hier total einen Blödsinn eingetragen habe und dass das Ergebnis vielleicht gar nicht zu verwenden ist und dass da irgendeine Validierung fehlt, das ist mir vielleicht nicht aufgefallen, das ist für alle selbstverständlich, aber ich bin ja, für mich ist das Thema ja neu gewesen.
Tobias
Da sprichst du was an, ich glaube, verschiedene Arten von Fehlerklassen. Wir haben wahrscheinlich alle schon mal persönliche Erfahrungen im Internet gemacht, in diesem Internet, was ja alles so schiefgehen kann. Also das eine, was du ansprichst, dass die Anwendung funktioniert grundsätzlich, verhält sich aber anders, als ich das erwarte, beispielsweise mit der Formularvalidierung. Ich würde erwarten, nicht, wenn ich ein Formular absende, dass ich dann als Antwort bekomme, ob es 500, hier ist etwas schiefgelaufen, sondern dass mir das Formular sagt, ich erwarte eine Zahl, du hast da ein String eingegeben, du hast da was nicht Valides eingegeben. Das ist, glaube ich, die eine Klasse, die andere Klasse ist, ich rufe eine Website auf und ich kriege irgendeine Fehlermeldung im Browser, weil das System ist gar nicht erreichbar oder ich kriege den klassischen hier 502 oder was ist es, service unavailable oder solche Geschichten. Irgendwie ist die Anwendung gar nicht da und ich glaube, da sind wir ja genau auf diesen unterschiedlichen Ebenen, was ihr vorhin schon angesprochen habt. Es kann ein Problem in der Anwendung selbst sein, in der Logik vielleicht oder in der Darstellung. Es kann die Laufzeitumgebung sein, wo die Anwendung läuft, auf dem Web-Server oder irgendwas auf dem Weg dorthin und jetzt bin ich in dieser Diagnosephase drin. Ich bin noch weit weg vom eigentlichen Fix und wir haben ja als Überschrift für diese Folge structured debugging genommen, also strukturiertes Debuggen. Was bedeutet denn für dich, Sebastian, dieses structured?
Sebastian
Ja, also, ähm, das ist eine gute Frage. Ähm, ich würd noch mal kurz einen kleinen Bogen ausholen und komm dann sofort zurück. Wenn man normal entwickelt und mehr Erfahrung hat, wird man immer schneller, weil man das Ökosystem besser kennt. Und man hat sozusagen die Annahme, wie sich das System verhält, im Kopf reicht immer weiter. Das ist wie ein Schachspieler, der drei Züge auf einmal vorberechnen kann im Kopf. Und, ähm, das ist sozusagen im Normalfall was total Gutes, wenn man halt entwickelt, weil man das am Ende, ne? Hat man dadurch eine höhere Geschwindigkeit. Das Blöde ist, wenn man jetzt in diesen Fehlerfall, in diesen Debugging-Fall kommt, da kann genau dieser Wesenszug, diese Idee, ich mach jetzt mal drei Schritte auf einmal, weil ich weiß ja, wie sich das System verhält, einen komplett lahmlegen, weil, ähm, man dann so viele Dinge auf einmal ändert. Ja, also, das ist sozusagen so, wie wenn ich jetzt sagen würde, ja, ich muss jetzt in den Jumbo landen, dann schau ich jetzt mal drei Knöpfe auf einmal und guck mal, was passiert. Ne? Und, ähm, das heißt, dass... Also, ich hab mir im Prinzip so eine Art, ich sag mal, wissenschaftliche Vorgehensweise, experimentelle Vorgehensweise angeeignet, ganz persönlich. Und zwar, ich hab im Kopf oder auf einem Zettel einen Haufen, da steht drüber what I know. Ähm, dann gibt's einen zweiten Haufen what I assume. Und, ähm, dann gibt's, äh, einen dritten Haufen what I expect. Also, was weiß ich? Genau. Was weiß ich, was nehme ich an und was erwarte ich?
Tobias
was weiß ich, was weiß ich.
Sebastian
So, und jetzt geht's darum, am Anfang ist dieser Was weiß ich-Haufen leer. Und das meine ich ganz im wirtlichen Sinne. Ich gehe wirklich, wenn ich anfange zu die Bank, gehe ich von keinerlei Vorwissen aus. Also ich denke mir, okay, hier passiert ein komisches Verhalten. Ich weiß nichts über das System. Und es ist ganz egal, ob ich das selber geschrieben habe oder nicht. So, und ich habe ganz viele Annahmen, wie sich das System verhalten sollte. So, und jetzt geht es darum, eine Annahme zu nehmen und auf diesen Was weiß ich-Haufen zu legen. Und zwar entweder, indem ich sozusagen weiß, diese Annahme ist jetzt richtig oder die Annahme ist falsch. Also ich muss die validieren oder falsifizieren. So, und wie mache ich das? Jetzt kommt der dritte Haufen sozusagen ins Spiel. Ich formuliere quasi ein Experiment. Also ich überlege mir, wie kann ich jetzt, also ich versuche die Annahme so klar zu formulieren, dass ich ein Experiment designen kann, was am Ende rausspuckt, ja, das hat funktioniert oder das hat nicht funktioniert. Also was eine ganz eindeutige Aussagekraft hat. Und damit messe ich sozusagen, gucke mir an, wie sich das System verhält für das Experiment durch. Wir können gleich ein praktisches Beispiel machen. Und dann habe ich eine Aussage. Dann habe ich sozusagen einen Punkt auf dem What I know, also was weiß ich-Stapel, mehr. Und das mache ich Schritt für Schritt für Schritt immer weiter. Und so weiß man immer mehr über das System und nähert sich hoffentlich immer weiter den Punkt an, wo eigentlich das Problem ist. So mal ganz abstrakt gesprochen erst mal.
Tobias
Genau. Das hilft, glaube ich, schon mal dieses Strukturierte. Also, du hast ja gesagt, angelehnt tatsächlich an die wissenschaftliche Methode. Ich habe Annahmen. Je bewusster ich diese Annahmen mache, du sagst, du schreibst dir die auf und designs dann Experimente, um diese Annahmen zu bestätigen oder zu widerlegen. Das passt für mich zu dem Wort strukturiertes Vorgehen. Das ist das, was ich darunter verstehe. Machst du das ähnlich, Chris? Hast du auch so eine Methodik, die du anwendest?
Christoph
Ja, ich habe tatsächlich ein ganz ähnliches mentales Modell entwickelt, wo ich auch im Kopf ganz doll trenne, was weiß ich, also was sind Fakten. Also wirklich Sachen, auf die ich meine Arbeit aufbauen kann. Also da auch nicht so, ja, das ist wahrscheinlich oder höchstwahrscheinlich, sondern es ist etwas, was ich weiß. Und das andere sind quasi entweder Schlussfolgerungen aus den Fakten, die ich möglicherweise überprüfen muss. Wobei, wenn das halt schlüssig ist, tue ich die manchmal in einen Topf und das andere sind quasi Annahmen, das sind Hypothesen. Und gerade beim Debugging muss man da ganz, ganz vorsichtig sein, weil ich schreibe ja kein Programm, von dem ich weiß, dass es nicht funktioniert und gebe das dann raus und warte, dass sich jemand meldet. Sondern meine Annahme war ja, das System verhält sich korrekt und die ist ja nun mal offensichtlich falsch. Sonst hätte ich ja nicht, sonst müsste ich ja gar nicht debuggen. Das heißt, irgendwas habe ich falsch verstanden. Das heißt, ich muss infrage stellen und zwar ganz kleinlich infrage stellen, was ich zu wissen glaube, um den Fehler dann zu finden. Und das fängt, also das ist jetzt auf keinen Fall böse gemeint, aber das fängt bei der Fehlerbeschreibung an. Zum einen, ich will halt versuchen, den Fehler nachzustellen. Da kommt als Anfrage vielleicht oder als Bugbeschreibung kommt rein, wenn man auf den Knopf drückt, dann stürzt es ab. Und dann ist der Fakt, jemand hat mir gesagt, dass das abstürzt, wenn man auf den Knopf drückt. Und ich überprüfe, ob das bei mir auch so ist. Weil vielleicht gehört da ein bisschen mehr dazu und das wäre halt eine gute Stelle, das rauszukriegen ganz am Anfang und selbst das nochmal zu überprüfen.
Tobias
Das heißt, in diesem Diagnoseschritt sammelst du auch Kontextinformationen, wenn du sagst, ich überprüfe das mal, ob ich dieses Verhalten nachstellen kann und unter welchen Bedingungen es auftaucht, baust du ganz viel Kontextwissen drumrum auf, was zu dem Fehler beispielsweise führt.
Sebastian
Genau, also ich nenne das häufig so ein bisschen Beifang. Also ich sag mal, man hat ja, man macht sozusagen diese Experimente, wo dann rauskommt, ist richtig oder ist falsch, aber man sieht natürlich, während man diese Experimente macht, ganz viele Dinge. Also man sieht zum Beispiel Log-Ausgaben, was Christoph vorhin erzählt hatte. Man sieht irgendwelche Übermittelungsprotokolle, was wird denn wie übermittelt oder wie nicht. Man sieht, gibt es Fehler, die vielleicht der Endnutzer übersieht, weil die für ihn erst mal gar nicht so einfach sichtbar sind beispielsweise. Und das sind alles Dinge, wo ich sozusagen versuche, ganz offen, also ganz aufmerksam durch die Welt zu gehen, wenn ich in diesem Modus bin, aber trotzdem das noch nicht zu werten. Also ich nehme das sozusagen alles auf möglichst und versuche es mir zu merken oder versuche es mir, Notizen zu machen, ah Moment, hier ist irgendwas komisch, gut, das lege ich mal auf diesen Haufen, das muss ich mir nochmal angucken. Und es ist halt nicht nur diese binäre Diagnose, okay, das ist jetzt richtig oder das ist falsch, sondern das ist sozusagen das Vehikel, bei dem man aber ganz viele Kontextinformationen mit erkennt.
Tobias
Okay. Jetzt nehmen wir uns mal ein Beispiel. Wir stellen fest, eine Anwendung verhält sich irgendwie seltsam und ihr bekommt das auf den Tisch. Nehmen wir mal, Christo hat hier von uns ein konkretes Beispiel im Kopf.
Christoph
Ja, wobei das, ich würde gerne ein anderes Beispiel nehmen, was leichter zu greifen ist.
Tobias
Was fällt euch spontan was ein, wo wir in letzter Zeit Debugged haben?
Christoph
Ja, es ist schon ein bisschen länger her, aber es ist ein Thema, wo ich immer mal wieder dran vorbeikomme und ich glaube, es ist auch ein Thema, mit dem viele Leute was anfangen können und zwar manchmal kommt es vor, gerade wenn jetzt Leute neuder sind, dass der Rechner eingerichtet ist und sie können keine E-Mails senden. Das passiert manchmal. Ja, und das ist ein ganz klassisches Problem. Ich frage sie, ob sie ihr Nutzernamen und Passwort und Server und so alles richtig eingegeben sind und natürlich ist die Antwort erstmal ja, weil sie natürlich das nicht absichtlich falsch gemacht haben. Also es wäre sonst wissentlich und da muss man halt, dann frage ich mich halt, ok, warum kriegen die keine E-Mails? Ich drücke auf E-Mails abrufen und es kommen keine an oder ich möchte die schicken, das ist sage ich mal das, was man als Endnutzer sofort sehen kann, aber was die erste Ursache ist, ist schon wieder unklar, das erste, was ich überprüfe, sind die Leute überhaupt im Netz? Haben die überhaupt Internet, also können die auf irgendeine Webseite raufgehen und dann ist der erste Schritt, können die überhaupt mit dem E-Mails Server kommunizieren und das kann man dann wiederum dort in den Logs sehen und vielleicht sagt der E-Mails Server schon, dass er den Nutzer nicht mag. Oder, das ist auch schon oft passiert, ja, der erkennt den Nutzer, aber der hat keine Lust mit dem zu sprechen, weil der hat sich schon so oft gemeldet, dass jetzt die ganze IP-Adresse als nicht vertrauenswürdig gilt und dann ist halt beim Einrichten kleiner Fehler gewesen und wenn es automatisiert ist, geht es ja schnell und dann hat er ganz oft versucht, sich zu verbinden und die IP-Adresse von dem ganzen Büro ist gerade gesperrt und das kann halt passieren und wenn ich auf dieser Kommunikationsstrecke diese Überprüfung machen will, da habe ich auch eine ganz bestimmte Reihenfolge, also es gibt bestimmte Sachen, die lassen sich sehr, sehr schnell überprüfen, die mache ich natürlich zuerst und es gibt Sachen, die mir ganz, ganz viele Informationen bringen und die mache ich auch zuerst. Zum Beispiel in den Serverlog schauen, ob da überhaupt ein Request ankommt, das geht schnell und ich lerne ganz viel oder zu gucken, ob ein Rechner im WLAN überhaupt verbunden ist, das geht schnell und ich lerne auch ganz, ganz viel und an den Stellen fange ich dann an.
Tobias
Da steckt ja jetzt schon ganz viel drin in dem, was du gesagt hast, nämlich du fängst sozusagen erstmal an, dir den Kontext anzugucken, ist der Rechner überhaupt mit dem Internet verbunden? Also ist das ein Problem, was spezifisch ist sozusagen für das Mail-Thema oder hat der Rechner ein grundsätzliches Problem mit dem Internet? Das heißt, du bist ja schon mal vom Gedanken her ganz weit rausgezoomt und nicht nur bei – in dem Mail-Programm sind keine E-Mails, wo kann ich denn jetzt hier klicken, um diesen Fehler zu beheben?
Sebastian
Ich glaube, das Wichtige dabei ist, genau, was du gerade meintest, dass man das Problem als in seiner Vollständigkeit begreift, also sozusagen, man muss sozusagen eine Vorstellung dafür haben. Erstmal, wie wäre denn der Weg, wenn es richtig funktionieren würde? Also in dem Beispiel E-Mail, aha, die E-Mail wird also über einen Mailserver geschickt oder empfangen, beispielsweise, da wird über bestimmte Ports kommuniziert, da muss ich mich irgendwie mal authentisieren mit einem Nutzer und einem Passwort und dann gibt es bestimmte Protokolle, die muss mein Mailprogramm sprechen und der Mailserver sprechen und das muss sozusagen richtig vertratet sein und dieses Grundverständnis sozusagen ist ein ganz wichtiger Aspekt, weil das sozusagen die Landkarte ist, auf der man navigiert. Das ist sozusagen, wir wissen irgendwas, das stimmt nicht, aber wir müssen trotzdem erstmal im Kopf haben, wie müsste es denn eigentlich sein oder es hilft auf jeden Fall enorm, wenn wir das im Kopf haben. Also es ist nicht in allen Fällen der Fall, manchmal hat man auch Probleme vor sich, wo man erstmal denkt, das kann ich mir gerade gar keine Reime ausmachen, das ist schwieriger als wenn man eine konkrete Idee hat, wo man schon mal anfangen kann zu suchen oder wenn man diesen Farbplan im Kopf hat, wie müsste es denn gehen, theoretisch, nach meiner Vorstellung, alles unter Vorbehalt, weil dann kann man quasi genau diese sinnvollen Fragen stellen, diese Experimente designen, die Chris besprochen hat. Was für mich immer wichtig ist, ist, dass diese Experimente nicht, also das ist nicht so, ich stehe da rum und gucke mich nur so ein bisschen um der Gegend um, sondern es ist sehr, sehr fokussiert und sehr, sehr zielgerichtet auf diese ganz konkrete Frage, die ich gerade habe, also wie Chris jetzt gesagt hat, kann der zum Beispiel überhaupt mit der Gegenstelle kommunizieren und dann ist das die zentrale Frage, auf die ich meine gesamte Energie darauf ausrichte, dort eine klare eindeutige Antwort rauszukriegen.
Christoph
Ich versuch das mal in dieses, ich hab meine Annahme und ich hab mein Experiment, was du meintest, von zu übersetzen. Meine Annahme ist, dass der E-Mail-Server diesen Request überhaupt empfängt. Also dieser Wunsch nach E-Mails kommt überhaupt an. Das ist meine Annahme. Und das Experiment, um das zu überprüfen, wäre zum Beispiel zu schauen, ob in den Logs drinsteht, dass dieser Nutzer versucht hat, sich anzumelden. Das wäre dann das Experiment. Aber dieses Rauszoomen, da kann ich nur noch mal Sebastian beipflichten, das ist so, so wichtig. Und so entstehen auch diese komischen Fragen, also komisch aus Nutzer-Sicht, die auch in zwischen ein bisschen schon verölgt werden. Ich habe ein Problem, mein Rechner funktioniert nicht. Na, ist er denn eingeschaltet? Naja, das ist ja schon legendär, sage ich mal, diese Frage, aber die ziehe ich genau darauf ab. Da steckt keine Annahme drin über den Nutzer und auch kein böser Wille, aber es ist ein ganz, ganz, ganz wichtiger Teil davon, das System zum Funktionieren zu bringen. Dieses eingeschaltet sein, das ist erstens essentiell wichtig und es ist sehr leicht zu überprüfen und dann fragt man das halt am Anfang ab.
Tobias
Ich würde mal in zwei Richtungen euch noch ein bisschen ausfragen. Und zwar seid ihr jetzt zwei Leute, haben wir am Anfang in eurer Vorstellung gehört. Ihr habt schon ein paar Jahren an Erfahrung und ihr kennt euch durchaus mit einem recht breiten Spektrum aus, was Webentwicklung angeht. Also wirklich runter bis zum Betriebssystem und Deployment und so weiter und so fort. Könnt ihr euch vielleicht daran erinnern oder habt ihr Tipps für Leute, die strukturiert debuggen wollen oder müssen, die vielleicht noch nicht diese Erfahrung haben, die genau dieses Wissen, was ihr jetzt gerade beschrieben habt, hey, ich weiß, wie grundsätzlich ein mentales Modell, wie eine Mailserver-Kommunikation funktioniert, die das nicht haben. Die sagen, hey, ich bin Anwendungsentwickler und ich baue hier vielleicht einen React oder so eine Anwendung und jetzt kriege ich hier irgendeinen Fehler und ich habe keine Ahnung, was für eine Datenbank dahinter läuft. Das ist weg abstrahiert, da kümmere ich mich nicht drum.
Sebastian
in Teilen kann ich das beantworten, weil wir natürlich auch ständig mit Fehlern konfrontiert werden, wo wir sozusagen keine Ahnung haben. Also wo es mir quasi genauso geht wie dem, sage ich mal, jüngeren Entwickler oder der jüngeren Entwicklerin. Aber klar, in einem anderen Problembereich vielleicht, aber dieses Thema hat man immer wieder, dass man sozusagen erst mal überhaupt nicht versteht, was da eigentlich passiert. Und ich glaube, das Wichtigste ist, don't panic. Also erst mal nicht verrückt machen, in Ruhe das Problem durchdenken. Sich möglichst fokussieren, alle Ablenkungen ausblenden und quasi diesen Moduswechsel ganz explizit hinbekommen. Was für mich da hilft und gerade, was ich gesagt hatte, wie man am Anfang entwickelt, das ist ja ein viel schnellerer Modus, als wie man Debuggt. Und diesen Switch ganz explizit hinzubekommen, ist erst mal schwierig und wichtig. Und dann würde ich jedem empfehlen und jeder empfehlen, diese Fragen so explizit wie möglich zu beantworten. Also wirklich in Papier oder in einer Textdatei hinzuschreiben. Okay, was weiß ich? Die Liste ist leer am Anfang. Und nächster Schritt, was ist meine erste Annahme oder was sind meine Annahmen, überlege ich erst mal. Und dann muss ich, also manchmal ist dieser Debuggingweg nicht so leicht und so einfach, wie jetzt Chris dargestellt hat mit diesem Mail-Beispiel, sondern es gibt häufig auch Fälle, wo wir selber auch erst mal gucken müssen, also wo sozusagen das Debugging an sich auch schon mal eine Weile dauert und ein paar Stunden dauert und das Herausbild einer Hypothese oder eines Experimentes zu designen schon schwierig ist, also wo wir quasi noch nicht genau wissen, worauf wir hinausarbeiten. Was mir dann immer hilft, ist sozusagen immer diesen roten Faden vor Augen zu haben. Also Beispiel mit dem Mail-Server. Wenn ich jetzt nichts über Mail-Server weiß, dann müsste ich wahrscheinlich erst mal einen Überblicksartikel suchen, der mir irgendwie auch Stackoverflow sagt, okay, wie funktioniert ein Mail-Kommunikation grundsätzlich? Ich lerne irgendwas über IMAP beispielsweise. Und dann habe ich eine ganz abstrakte Vorstellung, ja, so müsste es theoretisch funktionieren. So und dann ist halt der nächste Schritt, wie, naja genau, also diese diese Annahme zu formulieren, die auch hinzuschreiben, ganz explizit. Und im Übrigen, das ist auch was, wo man sich dann supergut Hilfe holen kann von anderen, wenn man diese Annahme schon mal so formuliert hat oder das Experiment designt hat. Wenn man sozusagen sagt, hier habe ich eine Annahme, ich habe keine Ahnung, wie ich rangehe, ich hätte die paar Ideen, aber so richtig bin ich mir nicht sicher. Das ist was total, also da kann man sehr, sehr gut zu Leuten mit mehr Erfahrung gehen, die können einem dann sehr genau auf dieser Basis helfen und sagen, naja, aus denen und den Gründen probiere ich das oder das beispielsweise. Also diese Investition ist sehr wertvoll. Ansonsten ist es sehr hilfreich, wenn man immer wieder nach Methoden schaut, wie man Wissen generieren kann. Was meine ich damit? Beispielsweise, wenn ich ein System vor mir habe, wie kann ich die Konfiguration des Systems auslesen, beispielsweise, ist so ein wichtiger Baustein. Der ist ja recht universell. Jedes System oder fast jedes System hat irgendeine Art von Konfiguration und da brauche ich Werkzeuge, die mir sagen, was ist denn gerade die aktive Konfiguration. Das ist nicht zwangsläufig die, die in irgendeiner Datei liegt, weil da gibt es diverse Möglichkeiten, das zu überschreiben vielleicht, sondern wirklich die, die zur Laufzeit in echt sozusagen da ist. Ein anderes Beispiel, ein anderes Werkzeug, ein sehr grundlegendes Werkzeug ist, ich muss irgendwie in der Lage sein, rauszukriegen, komme ich an dieser Stelle Quellcode vorbei oder nicht, wenn ich einen Fehler angucke. Also das ist das typische Debugge, also eine Konsole-Ausgabe. Also ich mache quasi in meinen Quellcode eine Ausgabe rein. Ich mache Console-Log oder Print oder Echo oder wie das dann je nach Programmersprache heißt, rein. Um rauszukriegen, komme ich hier vorbei auf diesem Weg des Fehlers oder nicht und wenn ja, wie oft und passt das zu meiner Erwartung. Also es gibt schon, sage ich mal, diese Art von universellen Tools, die man erst mal lernt und mit denen man erst mal auch sehr weit kommt, wenn man dieses strukturierte Vorgehen durchführt. Ich glaube, was ganz wichtig ist, dass man sich nicht stressen lässt. Also man darf nicht mit der, mit dem Mindset rangehen, ja, ich habe jetzt eine Stunde Zeit, dann muss der Fehler gefixt sein. Ich weiß nie, wie lange ich für eine Fehlersuche brauche bei diesen Fehlern, wo ich am Anfang keine Ahnung habe. Also ob das jetzt eine Sache von einem halben Tag oder von zwei Wochen ist, ich habe keinen Plan. Ich kann nur sagen, ich werde das so zielstrebig und so fokussiert wie möglich angehen, aber ich kann keine seriöse Schätzung machen.
Tobias
Das ist natürlich ein schwieriger Punkt, den du da ansprichst, wenn der Bug, der Auftritt ein Produktivsystem beim Kunden betrifft und der ruft an und ist natürlich nicht ganz so glücklich darüber, wenn beispielsweise die Anwendung aus irgendeinem Grund nicht verfügbar ist. Und wie soll ich sagen, diese Information erreicht den entwickelnden und...
Sebastian
Mmh.
Tobias
die meisten Leute fühlen ja dann dieses Verantwortungsgefühl. Oh Gott, oh Gott, die Anwendung, für die ich verantwortlich bin, da ist irgendwas los. Ich möchte das Problem natürlich schnellstmöglich beheben und mir ist sehr bewusst, dass das für den Kunden gerade eine suboptimale, euphoristisch, eine suboptimale Situation ist. Ich würde sagen, ich stresse dich nicht, wir haben ja auch schon öfter das Thema gehabt, das ist super schwierig, Hilfe holen im Sinne von am besten nicht alleine durchstehen in so einer Situation. Ich glaube, das, was du gesagt hast, ist mit diesem, ich muss mich fokussieren können, ich muss mich konzentrieren können, ich muss in Ruhe Zeit haben, mich auch auf dieses strukturierte Vorgehen einzulassen. Das Gegenteil, was wir momentan als Wort verwenden für dieses strukturierte Debugging ist ja das Stochern. Ich habe eine ganz schnelle Annahme im Kopf und pieke es einfach mal irgendwo rein, also ändere irgendwas, schraube an irgendeiner Stelle und vielleicht auch zwei, drei Schritte auf einmal. Ich drücke mal da die drei Knöpfe in der Annahme, dass es dann hoffentlich wieder klappt. Und in den meisten Fällen ist die Erfolgsrate da nicht so gut, würde ich sagen. Und das ist zumindest in meiner Erfahrung, die wir auch bei Senstum gemacht haben, eine ganz große Herausforderung, diese Ruhe zu finden, zu sagen, hey, das dauert jetzt so lange, wie es dauert. Lieber Kunde, seid ihr versichert, das hat für uns die höchste Prior, wir gucken da gerade drauf, aber wir können noch keine sinnvolle Prognose abgeben, wie lange das jetzt dauert, diesen Fehler tatsächlich zu beheben. Christoph, ich habe in Erinnerung, dass ein Kollege in einem Projekt von uns schon ein paar Mal gesagt hat, er debugt total gerne mit dir, weil du so eine ganz ruhige Art ausstrahlst und ihm da hilfst und sagst, das ist ja interessant, das System verhält sich anders als erwartet. Kannst du vielleicht ein bisschen beschreiben, was da in dir vorgeht, wenn der Kollege meldet sich bei dir und sagt, Christoph, Hilfe!
Christoph
Ja, das hat genau was mit dem Don't Panic zu tun. Ich hab oft gemerkt, wenn... Also, ich verstehe, dass der andere aufgeregt ist. Ich spür auch etwas von dem Druck und auch von dem Zeitdruck, der da eine Rolle spielt. Aber ich hab auch gemerkt, wenn ich es schaffe, selber ruhig zu bleiben, dann färbt es auch auf den anderen ab. Und... ... dann ist die Lösung meistens schneller erreicht. Na, also, wenn ich jetzt... Ist jetzt nie vorgekommen, um Himmels willen. Aber wenn ich jetzt einen Fehler versuche zu fixen und die ganze Zeit steht jemand neben mir, der mich anschreit, dann dauert es länger. Weil ich einfach abgelenkt bin. Nö, das ist halt so. Untertitel im Auftrag des ZDF für funk, 2017
Tobias
Können wir doch alle ein Lied von singen, oder?
Christoph
Ich hoffe, dass das jetzt keinen überrascht, aber wenn ich aber, und ich versuche im Kopf mich ein bisschen zu distanzieren von dieser Dringlichkeit, das ist ohne das jetzt böse zu meinen, sondern ich weiß, dass es dadurch schneller geht. Ich weiß, okay, es ist dringend, aber in meinem Kopf versuche ich mich auf das Debugging zu konzentrieren und das eher als so eine Art Rätsel zu sehen. Und dann kann es auch Spaß machen und wenn es Spaß macht, dann ist die Konzentration natürlich hoch.
Tobias
Jetzt nur an dem Beispiel, als du das gerade beschrieben hast, ist mir das Wort Pair Debugging durch den Kopf geflogen. Ist das was, was ihr macht? Häufig. Pair Debugging.
Christoph
Ja, manchmal. Das ist auch sehr hilfreich. Gerade mit dem zusammen zu debuggen, der eigentlich wenig über den Fehler weiß, aber möglichst viel über das System und die verwendete Sprache und so weiter, kann es ja helfen, weil der hat noch einen frischen Kopf. Da ist die Wissen, was weiß ich, Spalte, die ist noch leer. Und da ist nicht außer Sehen irgendwas raufgerutscht, was vielleicht nicht so sicher validiert worden ist. Das kann eine große Hilfe sein. Und auch, wenn, sage ich mal, eine gewisse Distanz zu dem Projekt ist, hilft das. Mir fällt es natürlich viel leichter, ruhig zu bleiben, wenn ich nicht derjenige war, der angerufen wurde von jemandem, der ganz aufgeregt ist oder vielleicht auch ganz wütend. Alles total verständlich und alles total in Ordnung. Aber wenn das jetzt jemand ist, den ich nur über Ecken kenne, dann hält es mir in dem Moment natürlich viel leichter, dort ein bisschen Distanz zu halten und, sage ich mal, diese Aufregung, diese Emotionen nicht rüber schwappen zu lassen, sondern ganz im Gegenteil. Dann kann ich halt sagen, ach ja, das ist aber ein interessantes Problem. Das ist eine willkommene Abwechslung. Und ich bin natürlich auch total froh, wenn ich dann dem anderen helfen kann. Und dadurch entsteht halt ein sehr, sehr positives und auch konstruktives Gefühl.
Tobias
Sebastian, du hast es auch direkt bejaht.
Sebastian
Ja, auf jeden Fall. Ich hole mir häufig auch Leute zu mir, die müssen nicht denselben Background haben, im Gegenteil. Das Wichtige ist, dass die sich in dem Moment auch darauf einlassen können, dass sie sozusagen auch diese Wege mit mir gehen. Und klar, was Chris schon meinte, die müssen sozusagen die Sprache verstehen und wissen, wie sieht diese Sprache aus, kann ich die lesen sozusagen. Aber über das Projekt ist gar nicht so super viel Vorwissen notwendig unter Umständen, sondern es geht eher darum, genau dieses explizit machen, dieses Zwingen. Also das zwingt einen ja dazu, sozusagen seine Annahme ganz explizit auszusprechen und schon das hilft meistens ganz, ganz viel.
Christoph
Das hat ja auch schon Methode. Es gibt ja das sogenannte Rubber Duck Debugging. Das ist also aufs Deutsch übersetzt, das ist eine Quietsche-Ändchen-Fehlersuche. Und die Idee ist folgendermaßen, man nimmt sich ein Quietsche-Ändchen, weil das kann gut zuhören, und dann erklärt man dem, was eigentlich das Problem ist, und ist dadurch gezwungen, im Kopf nochmal ganz strukturiert durch dieses Problem und mögliche Ursachen durchzugehen. Und das hilft. Das ist auch eine gute Sache. Es ist auch oft so, Leute kommen zu mir oder auch umgekehrt. Ich gehe zu Leuten und sage, ich komme hier nicht weiter und ich brauche unbedingt Hilfe. Und ich erzähle dir mal, worum es geht. Und dann erzähle ich das. Und dann fällt mir ein, ach ja stimmt, das liegt da dran. Dann bedanke ich mich und gehe. Und der andere hat gar nichts gesagt, der hat nur zugehört. Da ist ein Quietsche-Ändchen auch ein guter Zuhörer.
Sebastian
Was, glaube ich, noch wichtig ist, ist, dass diese, also wir sind jetzt dabei, wie gehen wir vor, wenn wir so einen Fehler haben und irgendwann an diesem Prozess, sage ich mal, wird dieser Stapel, was weiß ich, immer größer und ich habe eine immer konkretere Vorstellung, in welcher Ecke das Problem zu suchen ist. Ich habe vielleicht das Problem noch nicht hundertprozentig durchdrungen, so bis zum letzten Stückchen, aber ich bin, also es gibt einen Punkt, der ist weit vor den hundertprozent, wo ich schon eine hilfreiche Lösungsstrategie habe in der Regel, also sprich, ich denke meistens, also kommt immer ein bisschen darauf an, wie kritisch das Problem ist, aber häufig habe ich sozusagen einen Hotfix, also eine Fehlermaskierung zum Endkunden hin sozusagen, die das Problem aus Kundensicht schon mal löst und mir Zeit verschafft, noch die letzten zwanzig Prozent, die halt auch noch mal aufwendig sind, noch mal zu gehen, also das heißt, das hängt immer ein bisschen davon ab, wie kritisch ist das Problem, also wie viele Leute sind betroffen und wie schwer sind diejenigen betroffen und aber das heißt sozusagen nur in dieser allerersten Phase, wenn ich sozusagen von Null starte, kann ich keine Abschätzung abgeben. Mit zunehmender Erfahrung kommt man schon an den Punkt, dass man sozusagen dann nach einer gewissen Zeit Fehler suche, ich sage mal in einem gewissen Riecher halt, wenn man sagt, okay, wahrscheinlich ist es in der Ecke und ich kann jetzt nie drauf wetten, aber ich würde mal sagen, Chance 70%, das behäbt schon mal das Symptom beispielsweise und dazu wäre es halt noch gesagt, je besser ich den Fehler nachstellen kann oder nachstellen oder auch vielleicht auf einem produktiven System sehen kann und auch direkt dort verändern kann, je schneller quasi meine Feedback-Schleife ist, desto schneller bin ich an dem Punkt, dass ich quasi das aus Kundensicht beheben kann und dann in Ruhe mir gucken kann, okay, was ist denn da jetzt eigentlich genauer schiefgegangen.
Tobias
Bei dem Thema Beheben würde ich ganz kurz noch mal einhaken, da Thema Fix, ich stelle mir noch mal ganz kurz nach hinten, ich wollte nämlich genau in diesem Zwischenstadium, wir haben so diese erste Diagnose, dieses erste Einordnen, okay, das ist jetzt passiert. Ich habe mich auf eine Komponente eingeschossen, in der es wahrscheinlich irgendwo hakt. Bei Mail Server hast du ja vor uns auch gesagt, Chris, ich gucke erstmal, ist das Problem auf dem Client oder auf dem Server und du, du, du, ich gehe da rein. Sebastian, du hattest vor uns schon mal so angedeutet, du hast dann so verschiedene Werkzeuge an der Hand, einmal dieses rausfinden, welche Konfiguration greift denn gerade eben, wenn der Fehler auftritt, tatsächlich und nicht, welche denke ich, dass sie greifen sollte. Das ist vielleicht so ein Beispiel oder das andere ist gesagt, du hast verschiedene, du nutzt verschiedene, wie soll ich sagen, Techniken, um zu schauen, wird denn dieser Code hier überhaupt ausgeführt oder komme ich überhaupt hier dran vorbei, bin ich auf der richtigen Spur, habt ihr noch ein paar dort, wie soll ich sagen, Techniken aus eurem Repertoire, was ihr nutzt, also ich sage mal, Konsole, Log oder Echo oder sowas hast du vor uns schon genannt, gibt es da noch mehr, wie ihr debuggt, wenn ihr dann dort im Code unterwegs seid.
Sebastian
Also ich nutze tatsächlich sehr, sehr viel häufiger Konsol-Log oder Echo als ein Debugger. Muss ich ja nicht erweiße sagen. Also Debugger im Sinne von man hält wirklich an an der Stelle und so. Das mache ich schon auch manchmal, aber ich persönlich, ja ich bin ein Konsolenkind, keine Ahnung. Also ich mache ganz viel mit diesem Konsolenweg. Ja.
Christoph
Ja, der Konsolenweg, der hat eine absolute Berechtigung. Also zu dem finde ich auch, ich benutze gerne einen Debugger, muss ich sagen. Aber bevor ich den benutzen kann, muss ich das Ding erst mal bei mir lokal starten können und diesen Fehler auch sehen. Das ist schon mal die erste Schwierigkeit. Und auf ein Produktivsystem jetzt einen Konsololok direkt einbauen ist ein echt heißes Ding. Da muss man aufpassen. Da wäre ich ganz vorsichtig. Da arbeite ich auch absichtlich mit halber Geschwindigkeit, weil da kann man dann auch schnell mal das Problem deutlich verschärfen. Dann hat man das Problem nicht gelöst, aber man hat trotzdem ganz andere Probleme. Ich bin aber auch ein großer Freund von einem Debugger. Das hängt natürlich an der Sprache. Es gibt Sprachen, da gibt es bessere Debugger, aber das ist leichter die einen zu richten als bei anderen. Was auch gut funktioniert, finde ich, ist...
Tobias
Was auch, was auch.
Christoph
Teile der Applikation auszuschalten. Ich benötige jetzt drei Schritte, um mein Ergebnis zu berechnen. Von mir aus Daten laden, Daten umrechnen, Daten schreiben, mit so einer ganz einfache Datenbankoperation. Und jetzt starte ich das Programm neu und habe es so modifiziert, dass es nur noch die Daten lädt. Und danach lasse ich es von mir aus direkt abstürzen, ich will ja nur gucken, was da beim Datenladen rauskam. Das ist auch eine Möglichkeit, um große Blöcke auf einmal zu testen. Und das hilft auch bei dem Beispiel, was du vorhin hattest. Ich habe jetzt eine Datenbank, aber ich weiß gar nicht, was das vielleicht eine ist. Ich kenne mich vielleicht mit Datenbanken nicht so aus. Das heißt, ich kann eigentlich die Datenbank selbst nicht debuggen, aber ich kann trotzdem meine Annahmen und meine Anforderungen validieren, die ich an die Datenbank habe. Ich kann trotzdem überprüfen, kann ich Daten rauslesen oder kann ich Daten reinschreiben, auch wenn ich nicht weiß, wie das funktioniert. Oder bei diesem E-Mail-Problem, ich kann gucken, ob der Client sich mit dem Server verbinden kann. Aber an irgendeiner Stelle hört da mein Wissen auch auf. Ich werde niemals rauskriegen, ob jetzt irgendwo bei unserem Internet-Provider der eine Switch einen Speicherfehler hat. Weil da weiß ich einfach zu wenig drüber und ich werde auch niemals diesen Switch in die Hände bekommen. Das ist völlig ausgeschlossen, das heißt, da muss ich natürlich große Blöcke auf einmal überprüfen. Das hilft mir auch sehr.
Sebastian
Genau was mir noch immer wichtig ist, ist sozusagen diese Experimente so zu bauen, dass sie sehr schnell reproduzierbar sind. Also was meine ich damit? Wenn man jetzt zum Beispiel ein langes Formular hat, was man irgendwie hintereinander weg ausführt, das ist irgendwie zehn Seiten. Und erst wenn ich am Ende sage, abschicken, dann geht was los. Und dann sehe ich sozusagen, ob es geklappt hat oder nicht. Dann wird die Anfrage an den Server geschickt beispielsweise. Dann gibt es zum Beispiel Werkzeuge, also Curl. Man kann quasi in dem Entwicklerwerkzeugen des Browsers sozusagen, kann man sagen, Copy as Curl. Da hat man so einen speziellen Befehl. Und den kann ich auf der Kommandozeile starten. Und dann kann ich sozusagen diese eine Abfrage einmal machen. Und also das Ziel davon ist, wenn ich immer wieder erst das ganze Formular ausfüllen muss sozusagen, dann habe ich immer das Problem, es dauert ziemlich lange, bis ich wieder an diesen Punkt komme, wo ich messen kann, ob alles geklappt hat oder nicht. Und es hat eine hohe Fehleranfälligkeit, wenn das vielleicht das Problem nur in bestimmten Situationen auftritt oder in bestimmten Werten beispielsweise. Denn dann müsste ich mir ja immer für meine ganzen 20, 30, 500 Felder merken, was habe ich denn da reingeschrieben. Und das ist zum Beispiel so ein Weg, was ich sehr häufig mache, dass ich das einmal im Browser mache sozusagen, um den Fehler zu sehen, aber dann sofort gehe und gucke, ob ich diesen Fehler quasi auf einem direkten Shortcutweg reproduzieren kann. Und was dann typischerweise passiert ist, dass man so eine Liste an, also man macht diese Experimente. Manchmal kommt raus, ja, okay, das ist so, wie ich es gedacht habe. Manchmal kommt raus, naja, das ist nicht so, wie ich es gedacht habe. Und das ist immer ein bisschen schwieriges Ding. Also Beispiel bei den Mails, wenn was nicht im Log auftaucht, das heißt halt noch nicht, dass es nicht geklappt hat. Das heißt halt nur, es taucht nicht im Log auf. Und diese Feinheiten muss man sich halt bewusst sein. Es kann also durchaus dran liegen, dass sich das Log-Level falsch eingestellt ist oder dass es überhaupt kein Logging da gibt an der Stelle. Und das heißt, manchmal ist es, also wenn ich was im Verhalten sehe, bin ich schon mal einen Schritt weiter, als wenn ich sozusagen nur Abwesenheit von Verhalten sehe, weil das immer an sehr vielen mehr Gründen liegen kann, wenn ich einfach was nicht sehe beispielsweise. Und genau, und wie gesagt, dann hat man sozusagen so eine Liste von Experimenten, wo man denkt, okay, die zeigen dann das Fehlerbild und die müssten sich ändern, wenn ich das Fehler gefixt habe sozusagen. Und meistens ist es so Zwiebelschalenmäßig, von innen nach außen. Ich gehe quasi, ich habe dann irgendwo an irgendeiner Stelle im Code einen Echo, wo ich sage, ja, ja, kommt voll raus. Da müsste aber True rauskommen. Dann fixe ich was und sehe, aha, das Ding wird True. Okay, check. Und dann gehe ich sozusagen die Zwiebelschale rückwärts mit meinen offenen Experimenten, bis ich halt am Ende sehe, okay, es funktioniert doch für einen Endkunden. Und das ist für mich so ein bisschen die Validierung hinten heraus, dass ich sozusagen durch diesen Fehler, durch dieses Debugging wirklich was gelernt habe. Also, dass ich dann am Ende des Debuggings sozusagen schlauer bin, dass ich besser verstanden habe oder auch in sich schlüssig verstanden habe oder erklären konnte, warum das Problem existiert.
Christoph
Dieses Stichwort schnelle Experimente, das ist extrem wichtig. Das macht auch einen großen Unterschied. Ich möchte den Fehler bei mir lokal nachstellen. Das ist natürlich nicht, weil ich den Fehler so toll finde und ihn gerne mit nach Hause nehmen möchte. Aber ich kann auf meinem Entwicklungsrechner einfach sehr, sehr schnell so ein Experiment machen oder ich kann das auch mehrmals machen. Wir haben über eine Fehlerklasse noch gar nicht gesprochen. Das sind die Fehler, die nur manchmal auftreten. Und dann wird das noch viel, viel wichtiger. Da muss ich jedes Experiment zehnmal machen. Und selbst dann kann ich mir nicht ganz sicher sein, ob ich nicht vielleicht zehn Faults Positives hatte. Und beim elften Mal wäre der Fehler endlich aufgetreten. Da wurde vorhin kurz angerissen, diese Feedback Loop, die soll kurz sein. Das heißt, ich möchte schnell etwas ausprobieren können. Und wenn es einen Tag dauert, weil der Fehler tritt nur auf dem System, wo ich nicht rauf kann auf und ich muss erst dem eine E-Mail schreiben, der dann am nächsten Tag für mich irgendwas nachguckt, dann kann das Debugging sich auch mal von einem Tag auf mehrere Wochen verlängern, im schlimmsten Fall. Also das macht dort die Crew wirklich fett. Also das ist ein ganz, ganz wesentlicher Unterschied.
Tobias
Schöne Beispiele. Ich würde nochmal eure Erfahrung anzapfen und eure Expertise. Und zwar hatten wir öfter schon Show and Tells bei uns, wo jemand gezeigt hat, hey, ich habe hier ein Debugging-Tool, eine Technik verwendet, etwas, was mir der Browser vielleicht ermöglicht. Aber das ist nicht verlässlich. Das gibt was anderes aus, als die Realität tatsächlich ist. Wir hatten ja schon mehrere solche Dinge. Wir hatten, wenn ich mich richtig erinnere, Console-Log war so ein Ding, Inhalte von Arrays. Kannst du das kurz beschreiben?
Sebastian
Ach das, ja, ich erinnere mich da dran. Genau, wenn man, also, wenn man, man hat ein JavaScript-Objekt zum Beispiel und jetzt macht man Console-Log von diesem Objekt und man würde erwarten, dass sozusagen das Objekt, so wie es zum Zeitpunkt des Loggings war, ausgegeben wird. Es ist auch meistens so, blöderweise nur meistens, weil aus Performance-Gründen sozusagen, wenn das Objekt sehr, sehr groß ist, wäre es halt sehr, sehr ineffizient, dieses Gesamtobjekt zu nehmen und quasi an die Konsole rauszuschreiben mit allen ganz, ganz, ganz vielen Unterobjekten, sondern da wird sich sozusagen in der Konsole nur eine Referenz auf das Objekt gemerkt. Das bedeutet, wenn man nach diesem Console-Log das Objekt nochmal modifiziert, kann es passieren, dass man schon das Modifizierte sieht. Da ist zum Beispiel so ein ganz schöner Quick-and-Dirty-Trick, man macht einen JSON-Serialize drauf, also macht aus diesem Objekt einen String, da weiß man, der ist unveränderlich, der ist, wie er ist und dann kann man das halt sehen. Das ist so ein Beispiel, das ist schwer, also das sind fiese Dinge und das sind auch Dinge, wo ich schon teilweise lange gehangen habe, weil das ist, ich glaube, das sind halt diese fiesen Sachen, die man, wo man dann irgendwann ein Gespür für entwickelt, aber da gibt es, glaube ich, keinen so richtigen Shortcut.
Christoph
Ich erinnere mich da dran.
Tobias
Christoph
Ja, ich erinnere mich, ich glaube, das war in dem Inspector-Tool von Redux, da kann man sich quasi alle Zwischenergebnisse, nenne ich sie mal, innerhalb der Applikation anzeigen lassen, und da ist genau das passiert. Es gab diese, ein Zwischenergebnis wurde angezeigt, was so nie existiert hat, aus dem Grund, dass halt diese Referenz darauf existiert hat. Ja, und es war auch ein Fehler, dass das so eine Referenz war. Es war schon Teil der Diagnose, aber das war dieses Mesa-Beispiel. Nur weil kein Log kommt, heißt es nicht, dass sich keiner verbunden hat.
Tobias
Ich habe noch ein anderes Beispiel im Kopf. Ich weiß aber nicht, ob ich es noch genau zusammenkriege. Da ging es irgendwie um Datei-Upload, glaube ich, Dateireferenzen und das Encoding von irgendwelchen Sonderzeichen in der URL und der Browser. Wenn man sich das angeguckt hat, hat es anders angezeigt, als es tatsächlich war. Was denn? Bei dir klingelt was?
Christoph
Ja, ich erinnere...
Tobias
Da war irgendwas, ne?
Christoph
Da war irgendwas, ne? Ja, da... Genau, also Datei, Dateinahme und Sonderzeichen ist sowieso immer ein richtig interessantes Problem tatsächlich. Und zwar... Das hatte was damit zu tun, die modernen Browser, also auch Chrome oder so was, die kürzen manchmal den Pfad oder die URL ab. Meistens fehlt zum Beispiel das Protokoll. Da sieht man nicht, ob das HTTP ist oder HTTPS. Zumindest steht das nicht mit da. Oder auch der www. Das wird gerne mal weggelassen. Auch bestimmte Sonderzeichen werden unterschiedlich dargestellt. Und dann gibt's quasi Regeln, wie diese Sonderzeichen übertragen werden. Und... Dann gibt's aber andere Regeln, wie sie dargestellt werden. Und da hatten wir tatsächlich, das war Chrome, eine kleine Kombination gefunden. Da konntest du... oben in der Leiste was eintippen. Und dann hast du das abgeschickt. Und oben in der Adressleiste das da, was du eingetippt hast. Und auch in den Entwicklertools stand das ein, was du eingetippt hast. Aber wenn du dort noch dreimal was aufgeklickt hast, hast du gesehen, was er wirklich gesendet hat. Das ist dann ein bisschen anders gewesen.
Tobias
Das war, glaube ich, das Beispiel mit dem Copy-as-curl-Sebastian, wo du dann zeigst, hier den tatsächlichen Aufruf, den der Browser macht, der ist anders encoded als das, was er dir an zwei Stellen anzeigt oder so.
Christoph
mit dem Copy-as-Curl-Sebastian, ne, wurde da noch...
Sebastian
Genau, genau, genau. Das ist genau so ein Ding, wo man sozusagen, im Zweifelsfall, der nächste Schritt wäre gewesen, wenn das nichts gebracht hätte und man will aber weiter das validieren. Da würde man halt dann gucken, ob man zum Beispiel wirklich mit einem Netzwerk-Tracing-Tool draufgeht und also wirklich guckt, was geht denn an Paketen übers Netzwerk und was steht denn da drin, beispielsweise. Also man kann sozusagen schrittweise näher an die Wahrheit rankommen mit so einem Werkzeugen halt.
Christoph
Wobei das bei verschlüsselten Verbündungen dann schon schwieriger, schneller schwierig wird.
Tobias
Aber warum es mir ging, als ich das jetzt angesprochen habe, ist ja, auch das, was mir sozusagen mein Experiment zeigt, hat einen gewissen, wie soll ich sagen, kann mit einer gewissen Unsicherheit verbunden sein, wenn ich ein Konsole mache, wie wir es gesagt haben, und ich lasse mir ein Objekt ausgeben und ich wundere mich, dass was anderes drin steht, als ich erwartet hätte. Dann muss ich mir im Zweifelsfall bewusst sein, Moment mal, wie funktioniert denn die Console-Log-Ausgabe und was zeigt die mir denn? Zeigt die mir wirklich, dass das Objekt zu diesem Zeitpunkt, wie es in dem Moment ist, oder kriege ich, aus Performance-Effizienzgründen, das Objekt vielleicht zu einem anderen Zeitpunkt, wenn ich sozusagen diese Annahme nicht hinterfrage, ist vielleicht die Console-Log-Ausgabe nicht die, dann kann ich da wahrscheinlich noch viel mehr Stunden drum herumdrehen.
Christoph
Wo ich ganz kritisch nochmal mit allen Annahmen ins Gericht gehe, die ich so habe, zum Beispiel, wenn ich was mit ConsoleLog ausgebe, wird dann das ausgegeben, was ich ausgeben wollte. Das ist so eine grundlegende Annahme, ja, davon geht man normalerweise ja aus beim Entwickeln, aber wenn ich alles mir angeguckt habe und alles funktioniert so, wie ich es mir vorstelle und ich habe keinen Fehler gefunden und es tut einfach nicht, dann habe ich wohl eine falsche Annahme irgendwo getroffen.
Sebastian
Genau, dann muss man kreativ werden und überlegen, okay, was ist denn ein anderer Weg, das rauszukriegen, vielleicht ohne Console-Log? Also beispielsweise, was ich dann auch schon manchmal mache, ist, es gibt Fälle, da geht Console-Log nicht so einfach oder führt zu Folgeeffekten. Und da schreibe ich zusätzlich nochmal in irgendeinem File in einem temporären Verzeichnis mit beispielsweise, mit eigenen, so selbst gestrickten Log-Ausgaben beispielsweise. Oder, genau, ich hatte ja schon das Beispiel, quasi Curl, oder manchmal muss man in die System-Calls reingucken. Das ist schon ein bisschen esoterischer, sage ich mal. Das ist dann eher, wenn es um fiese Performance-Probleme geht oder so, die dann überall sein können. Aber das ist dann halt, ich sage mal, wie so sagen, das ist schwer zu beschreiben, wie man da vorgeht, aber ich versuche mir immer, die Offenheit zu erhalten, dass sozusagen der Weg, den ich gerade eingeschlagen habe, wie bei einem wissenschaftlichen Experiment, kann es halt sein, dass da rauskommt, ich habe keine Ahnung. Und obwohl das Experiment jetzt gerade true sagt und beim nächsten Mal sagt es false, dann wieder true, dann wieder false, dann messe ich vielleicht einfach falsch. Und das ist halt genauso wie auch in einem wissenschaftlichen Experiment kann das halt passieren. Und genau, und wenn das so ist, versuche ich es so hinzunehmen, als aha, das könnte so sein, okay, wie können wir das validieren? Und wirklich immer wieder schrittweise. Und man wird ja nicht dümmer dabei, das ist ja das Coole daran. Man lernt ja ganz, ganz viel. Und es macht auch sehr viel Spaß, mir zumindest, wenn man dann am Ende so dieses Gefühl hat, man ist an der Wurzel angekommen. Und man hat so unglaublich viel verstanden, wo man vorher nicht mal wusste, dass das existiert. Das ist cool.
Tobias
Sehr schön. Ich würde noch ein Thema ansprechen. Wir hatten, wir hatten vor uns ja schon mal das Thema, okay, wir haben eine Diagnose gestellt mit den ganzen Hilfstechniken, die wir jetzt auch schon besprochen haben. So was, und du bist vor uns schon mal in dem Thema Fixing vorbeigestriffen. Also gesagt, ja, da gibt es einen Hotfix, den ich vielleicht veröffentlichen kann, weil der erstmal das Symptom behäbt. Weiß ich nicht, was ist denn so ein Klassiker, die Anwendung hat sich an irgendetwas, was der User hochgeladen hat, verschluckt und kommt nicht mehr hoch, die ist einfach down. Und jetzt kann ich in die Datenbank gehen und ich löche das und die Anwendung tut wieder. Das wäre ein Hotfix. Hab ich aber noch nicht das Problem behoben, wenn der User das noch mal hochlädt, ist die Anwendung wieder kaputt. Wenn man das beheben möchte sozusagen, dann ist man eben nicht mehr im Hotfix-Bereich, sondern ist man bei der Root Cause. Also was ist denn die eigentliche Ursache vielleicht für das Fehlverhalten? Was ist für euch der Unterschied zwischen Hotfix und Root Cause Fix?
Christoph
Naja, ich will jetzt nicht sagen, bei einem Hotfix weiß ich, dass der nicht funktioniert, aber bei einem Hotfix weiß ich, dass der zumindest keine Dauerlösung ist. Das würde für mich den Unterschied machen. Du hast jetzt gesagt, da ist irgendwas hochgeladen, was das kaputt macht, dann lösche ich das halt erstmal wieder. Kann natürlich sein, dass es wieder hochgeladen wird. Ich bin auch viel profaner, die ganze Webseite crasht, sobald Leute da einen Kommentar schreiben wollen. Starte ich sie halt neu? Nee, ach was, dann gibt es halt keine Kommentare. Dann werden die halt deaktiviert mit einem kleinen Hinweis, wir kümmern uns drum, funktioniert gerade nicht. Das ist natürlich keine Dauerlösung, wenn das mal einen Tag dasteht, finden die Nutzer das vielleicht schade, aber okay, aber wenn das nach zwei Monaten immer noch dasteht, dann finden sie es vielleicht nicht richtig ernst genommen oder das wirkt sich dann sehr negativ auf den Ruf der Seite aus eventuell. Das ist aber eine Lösung für das akute Problem, das verbessert auch die User Experience, also die Bedienbarkeit, aber es kann sein, dass nicht alles so funktioniert, wie es soll oder es funktioniert nicht lange. Ich habe jetzt einen Hotfix, wo ich sage, okay, ich schreibe das erst mal alles auf Platte, eigentlich sollte ich so eine Datenbank speichern, naja, das mache ich dann irgendwann später, in Klammern, damit es vielleicht auch mal irgendwann gelesen werden kann. Die Daten sind erst mal nicht weg, die Festplatte läuft langsam voll und ich bin nur den halben Weg gegangen. Das war's für heute, bis zum nächsten Mal, bis zum nächsten Mal, bis zum nächsten Mal,
Sebastian
Das Entscheidende ist, glaube ich, dass man nicht beim Hotfix stehen bleibt, weil der ist ein sehr wichtiger Schritt, weil er sozusagen den Druck aus dem System, den Druck vom Kessel nimmt, weil er aus Kundensicht das Problem schon mal behebt oder einen Großteil des Problems behebt und der die Kunden wieder arbeitsfähig macht sozusagen. Und wenn man aber jetzt sozusagen jeden Woche dieselben Hotfix macht, jetzt mal ein bisschen übertrieben gesagt, dann merkt man schon, dass das irgendwie Quatsch ist, dass das nie sinnvoll ist. Das heißt, ich mache das häufig persönlich so, wenn ich ein Problem das erste Mal sehe, dann bleibe ich vielleicht beim Hotfix stehen und sage, ja, okay, das ist okay. Keine Ahnung, wie das gekommen ist. Ich habe es gerade sehr schwer nachzuvollziehen. Ich habe keine Ahnung, ob das das nächste Mal in drei Jahren oder in einem Monat passiert. Also, lassen wir uns mal bei diesem Hotfix. Ich lösche die Zeile aus der Datenbank wieder von mir aus. Wenn ich jetzt nicht sofort sehe, woran es dann liegt, also irgendeine Exception, wo ich dann nachlesen kann. Apropos, das war noch ein Werkzeug. Stack Traces lesen, Exceptions lesen und lesen, lesen, lesen, also Nachrichten lesen, die irgendwie das Programm ausgibt und rausfinden, von wo das kommt. Das ist noch so ein wichtiges Werkzeug.
Christoph
Ja, und auch wenn man es dran gelesen hat und merkt, man versteht es nicht, nicht abhaken und mit dem nächsten weitermachen, sondern versuchen, rauszukriegen, was da steht, weil es könnte wichtig sein. Genau.
Sebastian
Genau. Wo war ich stehen geblieben? Genau, bei dem Hotfix. Aber wenn das Problem das zweite oder das dritte Mal auftritt, dann vielleicht noch in kürzerer Zeit, dann ist es auf jeden Fall akut, da was zu machen. Und dann ist ganz wichtig, dass nach dem Hotfix auch die Rootcourse-Analyse sehr zeitnah kommt. Und das wundert manchmal die Leute, dass Probleme, die sind jetzt drei Jahre lang nicht aufgetreten, und jetzt fängt es an, dieses Problem in dieser Variation zu geben. Das ist für mich eigentlich was recht Normales, weil es gibt typischerweise an der Anwendung so gewisse Kipppunkte, die entstehen. Also die vielleicht passieren ab einer gewissen Anzahl Leute, die parallel das System nutzen oder ab einer gewissen Last auf dem Server oder alle möglichen Faktoren. Und dann fängt es an, das System sich sozusagen hochzuschaukeln in irgendeiner Form und negativ zu entwickeln. Das heißt, es ist für mich nicht unerwartet, dass irgendwann nach langer Zeit so eine Art von Problem auftaucht. Das kann durchaus passieren. Und deshalb ist es aber wichtig, wie man damit umgeht.
Christoph
Und gerade im Bereich Web ist ja die Hälfte der Applikation außerhalb unserer Kontrolle. Das ist ja der Nutzer, der raufgeht. Und da dreht sich die Welt einfach weiter. Thema Smartphones, meine Nutzer hatten immer einen schönen Monitor. Die waren damals meistens im Verhältnis 4 zu 3. Jetzt haben die plötzlich ein Telefon, das ist total schmal und klein und das sieht alles total doof aus. Da hat sich gar nichts an der Applikation geändert, die funktioniert so wie immer, aber ist einfach nicht mehr gut genug, weil sich die Anforderung geändert hat. Oder jetzt hier viele Browser stellen jetzt für Privacy immer mal bestimmte Regeln um, was die Cookies betrifft. Weil da gibt es Sachen, die sind jetzt erlaubt und manchmal wird es aber missbraucht, sage ich mal oder viele Browser-User wollen das nicht, dass das für Tracking eingesetzt wird und dann ändern die das und damit funktionieren natürlich auch andere Sachen vielleicht nicht mehr. Und das ist halt einfach, die Welt dreht sich halt weiter.
Tobias
Rahmenbedingungen, die dazu beitragen können, ohne dass ich was an der Anwendung selbst geändert habe, dass sie nicht mehr so für den Nutzer funktioniert, wie sie es vorher vielleicht getan hat.
Christoph
Genau. Oder es geht über technische Gründe hinaus. Meine Konkurrenz bietet jetzt einen ganz tollen Service an und der wird langsam normal und dann wird er plötzlich vermisst.
Tobias
Lass mich euch mal noch eine letzte Frage stellen. Habt ihr noch vielleicht eine Anekdote, wo ihr was debuggt habt und ihr habt, als ihr es dann gefunden habt, habt ihr gedacht, oh mein Gott, das war jetzt, weiß ich nicht, völlig falsche Spur, auf die mich die Log-Ausgabe geschickt hat oder völlig, also es war so was triviales oder da hätte ich auch vorgestern schon drauf kommen können, ich habe jetzt zwei Tage, bin ich einfach in die falsche Richtung galoppiert, weil ich irgendeine ganz grundsätzliche Annahme falsch hatte, habt ihr irgendwas im Kopf, was euch einfällt?
Christoph
Irgendwas, was so jetzt ganz viel Zeit verloren ging, weiß ich nicht.
Sebastian
Also, was ich schon hatte häufiger ist, dass diese, also, man muss ja sowieso sagen, wenn man am Ende den Fix sieht, der ist ja meistens nur zwei Zeilen oder drei Zeilen oder noch weniger oder ein Zeichen oder so, also das heißt, der Fix und der Aufwand, der reinsteht, steht eh in keinem Verhältnis zueinander, also die Größe des Fixes, ich persönlich habe nicht so dieses Gefühl, also, oh Gott, oh Gott, das war verschwendet, selbst wenn ich mal in die falsche Richtung gerannt bin, weil das ist halt Teil dieses notwendigen Lernprozesses in diesem Bereich dann.
Tobias
Ja, ja, das ist auch nicht das, was ich meine, sondern ich bin eher, wir hatten doch heute morgen hier oder gestern Abend dieses Beispiel, wo irgendein Deployment-Job war es doch bei uns, der mit einer Fehlermeldung auf die Bretter gegangen ist, haben wir in das CI gesehen, was war das, irgendwelche Rechte haben gepasst oder was war es? Genau, Systemrechte. Und dann haben wir geguckt, wo kommt denn das überhaupt im Code vor, was er da anmeckert. Und dann haben wir geguckt, wo kommt denn das überhaupt im Code vor, was er da anmeckert.
Sebastian
Und das war keine Stelle, die wir quasi im Code hatten. Das war Code, den unser GitLab, unsere Quercode-Verwaltung für uns generiert hat, sozusagen. Also völlig jenseits von unserer Einflusssphäre, sozusagen, weil...
Tobias
Weil das Interessante war, wir hatten das Gefühl, es wird Code ausgeführt, der aber eigentlich nicht ausgeführt werden darf. Dann hat man Echo an der Stelle reingemacht, das kam auch nicht. Genau. Aber, dass in dem generierten Code...
Sebastian
die gleiche Zeilnummer.
Tobias
Das war die gleiche Zeile. Genau, das stand da in Zeile 109 und in der Config-Datei, wo dieses Ding kam, gab es nur Zeile 109, wo das stand. Also das war echt nochmal so ein total fieses Ding, wo wir auf den falschen Pferd gelenkt wurden. Und Sebastian, du hattest noch die andere schöne Anekdote. Die Tage, wie war das mit dem Router, zu Hause, im privaten Umfeld, das war doch auch so ein Ding. Genau.
Sebastian
Genau, im privaten Umfeld, das war auch so ein fieses Teil. Da hab ich auch echt, da hab ich mir das angeguckt, hab ich überhaupt nicht verstanden, was ich da sehe. Da war das Problem, also, mein Vater konnte nicht auf unseren privaten Mailserver zugreifen. Da kam immer ein SSL-Fehler, also Zertifikatsfehler. Aber wenn er ins LTE-Netz gegangen ist mit seinem Laptop, dann ging es. Und wenn ich mit meinem Laptop mich daneben gestellt hab und im selben Netz war, dann ging es auch. Also, und, lange Rede, kurzer Sinn, wir haben es, also, wir sind eben gerade nur bedingt auf die Spur. Wir haben dann die SSL-Zertifikate, wir haben dann gesnifft, was kommt auf dem Server an und so. Und was es letztendlich war, war eine kleine Config-Änderung im Router, die dazu geführt hat, dass unter gewissen Umständen quasi die Pakete, also ein Stück eines Paketes weggeworfen wurde auf dem Hinweg sozusagen, also auf dem Rückweg. Und das war halt dummerweise genau dieses Stück, wo sozusagen der Hash des Zertifikats drin stand oder ein Teil des Hashes. Und das ist jetzt erst so spontan aufgetreten, weil wir ja, weil die Zertifikate automatisch neu generiert werden mit Let's Encrypt alle sechs Wochen oder alle acht Wochen oder so. Und die haben halt irgendwas geändert, da ist ein neuer Zertifikatsfeature dazugekommen oder wie auch immer. Die Größe hat sich also ganz leicht geändert und dann hat es genau dieses Problem getriggert. Und das war so ein Punkt, das nehme ich dann auch mit nach Hause. Also, das gucke ich mir an und ich entwickele Theorien und man kriegt es nie zu fassen. Und in dem Fall hatte dann mein Vater die entscheidende Idee irgendwie einen halben Tag später, heute rufe ich mich an und hatte dann sozusagen die Verbindung gezogen, nachdem wir schon mal, ich habe gedacht, ja, es muss eigentlich der Router sein, aber ich habe keine Ahnung, was es da sein könnte und er hat aber ganz viel Netzwerk-Knowhow und so sind wir dem dann auf die Schlichte gekommen. Aber das war so ein richtig fieses Teil, auf jeden Fall.
Tobias
Vielen, vielen Dank nochmal für diese kleinen Anekdoten am Schluss, war doch eine Folge, oder?
Sebastian
Ja, auf jeden Fall. Hat Spaß gemacht. Mmh, vielen, vielen Dank.
Tobias
Ich denke auch, total spannend. Ich hoffe, da ist viel für unsere Hörerinnen und Hörer abgefallen. Wir freuen uns natürlich wie immer über Feedback zur Folge, wenn ihr Fragen habt, wenn ihr Anregungen habt, wenn ihr sagt, hey, hier diese Technik und dieses Tool, probiert das doch mal aus. Teilt das total gerne auf Twitter oder schreibt uns eine Mail, freuen wir uns sehr drüber. Wir werden auch in den Show Notes nochmal einen Blogartikel verlinken, wo wir das Thema Structured Debugging auch mal textuell aufgeschrieben haben für alle die, die sich das nochmal in textueller Form anschauen wollen. Ich glaube, es gab sogar ein Video, oder? Wir haben sogar mal eine Session aufgezeichnet. Also multimedial können wir das Thema ausspielen. Ich bedanke mich vielmals bei meinen Gästen heute. Danke, Chris.
Christoph
Vielen Dank Tobias, es hat viel Spaß gemacht.
Tobias
Und danke, Sebastian. Vielen, vielen Dank. Und wir würden uns freuen, wenn ihr auch bei der nächsten Folge Sandpapier wieder reinhört. Macht's gut und tschüss.
