Was machst du wenn du einen Bug zu lange nicht finden kannst?
Einen Bug von was denn genau?
wir sind beim Programmieren & Softwareentwicklung
13 Antworten
Debuggen, entweder mit einem Debugger, oder mit gezieltem Logging.
Mit der Zeit lernt man aber eine analytische Denk- und Arbeitsweise, mit der man ein Problem sehr kleinteilig betrachten und durchdenken kann, so finde ich eigentlich die meisten Fehler auch ohne Debugging.
Und wenn das alles nicht funktioniert, dann hilft das sog. "Rubber Duck Debugging", entweder mit einer "menschlichen Quietscheente", oder - mit etwas Übung - allein für sich im Kopf.
Und ein "Ich habe den Bug nicht gefunden" gibt es für mich nicht, darf es gar nicht geben.
Was ich gerade unter der Antwort von theodoravontane kommentiert habe:
Du kannst ja auch versuchen, das Problem nochmal von vorne zu durchdenken. Bau dir im Kopf wie eine Art Mindmap zusammen, die die Abläufe/Prozesse abbildet und beobachte dabei zwei Dinge:
* Welcher Pfad ist noch offen, wo müsste ich nachschauen?
* Welche Annahmen habe ich getroffen, die ggf. falsch sind?
Das funktioniert auch ganz gut, besonders wenn Du nebenbei gedanklich (oder mit einem "Albi-Ja-Sager") erklärst, was jeder Pfad in der Gedanken-Mindmap tut oder bedeutet.
Und:
Oder Du betrachtest das Problem "von hinten". Meistens ist ja ziemlich schnell klar, wo genau der Fehler aufgetreten ist, entweder eine Fehlermeldung, oder ein falsches Berechnungsergebnis, oder Code, der nicht oder falsch ausgeführt oder ...
Dann kannst Du hingehen und diesen Code rückwirkend ablaufen, wodurch wird er ausgeführt, was führt das wiederum aus und wodurch wird das wieder ausgeführt und so weiter. Dabei beobachtest Du dann auch Bedingungen und Berechnungen und "filterst" die Zweige heraus, die für dich irrelevant sind. Meistens bleibt dann ein recht einfacher Pfad übrig, der an irgendeiner Stelle sich anders verhalten *muss*, als erwartet und da kannst Du dann gezielt nachschauen.
Das ist besonders dann hilfreich, wenn man keinen guten Überblick hat, oder den Fehler nicht lokal reproduzieren kann und dann z.B. umständliches Logging oder Mitarbeit eines Kunden brauchst. Das will man natürlich nicht so super oft machen, da lohnt es sich, das Problem vorher auf einen kleinen Bereich einzuschränken.
Nicht direkt bei Bugs, aber bei logischen Fehlern im Code, die ein Verhalten zeitigen, das ich so eigentlich nicht erwarte. Dann suche ich mir einen Ja-Sager.
Der muss keine Ahnung davon haben, was ich da machen will, besser ist es sogar, wenn er keine Ahnung hat. Und dem erkläre ich dann ganz genau und wie dem Unwissenden, der er ist, was ich da so mache, wie das funktioniert (funktionieren soll) und was ich erwarte. Das öffnet mir sehr oft die Augen, weil ich noch mal anders auf den Code schaue. Bin ich alleine, sehe ich das, was ich denke, was ich geschrieben habe, erkläre ich es aber einer Person, die einfach nur zuhören und ab und zu mal 'aha', 'ja, ok' sagt, ist der Blick auf den Code noch mal ein anderer.
Bei mir funktioniert das gut.
Da ich dazu neige, dann laut vor mich hin zu brabbeln, wirkt das eher seltsam auf meine Umwelt. Deshalb ist ein Alibi-Ja-Sager ganz gut, zur Not geht es aber auch ohne :)
Du kannst ja auch versuchen, das Problem nochmal von vorne zu durchdenken. Bau dir im Kopf wie eine Art Mindmap zusammen, die die Abläufe/Prozesse abbildet und beobachte dabei zwei Dinge:
- Welcher Pfad ist noch offen, wo müsste ich nachschauen?
- Welche Annahmen habe ich getroffen, die ggf. falsch sind?
Das funktioniert auch ganz gut, besonders wenn Du nebenbei gedanklich (oder mit einem "Albi-Ja-Sager") erklärst, was jeder Pfad in der Gedanken-Mindmap tut oder bedeutet.
Oder Du betrachtest das Problem "von hinten". Meistens ist ja ziemlich schnell klar, wo genau der Fehler aufgetreten ist, entweder eine Fehlermeldung, oder ein falsches Berechnungsergebnis, oder Code, der nicht oder falsch ausgeführt oder ...
Dann kannst Du hingehen und diesen Code rückwirkend ablaufen, wodurch wird er ausgeführt, was führt das wiederum aus und wodurch wird das wieder ausgeführt und so weiter. Dabei beobachtest Du dann auch Bedingungen und Berechnungen und "filterst" die Zweige heraus, die für dich irrelevant sind. Meistens bleibt dann ein recht einfacher Pfad übrig, der an irgendeiner Stelle sich anders verhalten *muss*, als erwartet und da kannst Du dann gezielt nachschauen.
Das ist besonders dann hilfreich, wenn man keinen guten Überblick hat, oder den Fehler nicht lokal reproduzieren kann und dann z.B. umständliches Logging oder Mitarbeit eines Kunden brauchst. Das will man natürlich nicht so super oft machen, da lohnt es sich, das Problem vorher auf einen kleinen Bereich einzuschränken.
Ich speichere das Problem im Hirn, im Verzeichnis 'noch zu erledigen' ab, und umschreibe erst einmal das Problem mit alternativen Code.
Geht das nicht versuche ich zu lokalisieren, ab wann der Bug auftritt. Bis dahin sollte die App ja furzen.
1-2 tage warten, was anders machen und dann nochmal drauf schauen.
Neuerdings sofern es sicherheitstechnisch möglich ist... ich pack den code in ein ZIP und frage GPT und bitte es den Fehler zu finden. Das klappt wirklich
Das kann ich mir beim besten Willen nicht vorstellen, dass ChatGPT einen Fehler findet, den ich selbst nicht finden kann. Wirklich nicht.
Solche Fehler liegen dann tief unten in den Algorithmen. Sowas findet man nur in einem Code Review mit Kollegen, wo ich genau erklären muss, was ich mir so gedacht habe.
es sind oft einfach einfache Fehler die aber in hundert Seiten code nicht unbedingt auffallen. Hätte es früher auch nicht gedacht, aber einfach mal probiert und war sehr überrascht. Schade ist nur dass es nicht lokal läuft, würde es gern viel häufiger nutzen... aber kann nicht wahllos Code da hochladen :). Was später aber eh mal public wird.... optimal. Spart zeit.
Was machst du wenn du einen Bug zu lange nicht finden kannst?
Bug zu lange nicht finden? Wie soll das gehen?
Entweder ist die Architektur schlecht oder der Programmierer kann nicht mit dem Debugger umgehen.
Ansonsten wäre Pair-Programming eine Idee.
Man nennt es scherzhaft "Rubber Duck Debugging"
Funktioniert by the way auch ohne einen "Ja-Sager", ich gehe das im Kopf dann so durch, als würde ich es jemandem erklären und erreiche so meistens den gleichen Effekt.