it-swarm.dev

"Es hat gestern funktioniert, ich schwöre!" Was kannst du tun?

Wenn Sie morgens ankommen, stellen Sie fest, dass Ihre Software nicht mehr funktioniert, obwohl Sie gestern Abend abgereist sind.

Wie geht's? Was überprüfst du zuerst? Was tun Sie, um nicht mehr wütend zu sein und an Ihrem Problem zu arbeiten? Beschuldigen Sie Ihre Kollegen und gehen Sie direkt zu ihnen? Was kann getan werden, um eine solche Situation zu vermeiden?

59
Nikko

Die üblichen Verdächtigen sind:

  • Sie dachten, es hat gestern funktioniert, aber nach einem vollen Arbeitstag waren Sie zu blind, um zu erkennen, dass es nicht funktioniert hat.

  • Heute Morgen können Sie nicht mehr auf das verweisen, was sich gestern im IDE Cache-Speicher) befand.

  • Die Workstation wurde letzte Nacht neu gestartet oder ein nächtlicher Wartungsvorgang hat die Verzeichnisse/tmp gelöscht.

  • In der Codebasis hat sich etwas geändert: Überprüfen Sie, ob jemand (möglicherweise Sie selbst) Änderungen zwischen Ihrer letzten Kompilierung von gestern und Ihrer letzten Kompilierung von heute vorgenommen hat.

  • In den Support-Bibliotheken hat sich etwas geändert: Überprüfen Sie, ob diese Bibliotheken neu kompiliert oder aktualisiert wurden. Die Ursache kann innerhalb des Projekts für bestimmte Bibliotheken oder außerhalb liegen, wenn eine neue Version eines scheinbar unabhängigen Pakets bereitgestellt wurde.

  • In der Testumgebung hat sich etwas geändert: Neue Version einer virtuellen Maschine, ein geänderter Stub, Änderungen an einem entfernten Datenbankserver ...

  • In der Kompilierungskette hat sich etwas geändert: Änderungen in Makefiles, neue Version von IDE, Compiler, Standardbibliotheken ...

96
mouviciel

1) Wenn es heute nicht funktioniert, hat es gestern auch nicht funktioniert.

Sie dachten , dass es funktioniert, aber es war nicht.

2) Es gibt ein Problem, das gelöst werden muss.

Denken Sie nicht daran, wer dafür verantwortlich ist oder andere zu beschuldigen.

Wenn sich zwischen gestern und heute nichts geändert hat (wie ich vermutlich Ihre Frage gelesen habe), bedeutet dies, dass Sie Ihren Code besser testen sollten, bevor Sie ihn tatsächlich angeben es funktioniert.

Um diese Situation zu vermeiden, müssen Sie Testen und Debuggen ausführen.

Definieren Sie "Arbeiten" und testen Sie die Grenzen Ihrer Coderoutinen.

  • Versuchen Sie, einer der Benutzer zu werden, die Ihre Programm- oder Codefunktionen verwenden.
  • Schieben Sie Ihren Code an die zulässigen Grenzen und darüber hinaus und prüfen Sie, ob er nicht funktioniert.

Eine Möglichkeit, dies zu tun, besteht darin, während der Nacht einen automatisierten Satz umfangreicher Tests durchzuführen, damit Sie am nächsten Tag überprüfen können, ob ein Fehler aufgetreten ist, und die Probleme beheben können.

49
Jose Faeti

Der Versuch, jemanden zu finden, der die Schuld trägt, ist unkonstruktiv und löst keine Probleme. Tu es nicht.

Wenn etwas gestern funktioniert hat und jetzt nicht funktioniert, dann haben Sie entweder nicht deterministisches Verhalten (wie eine Rennbedingung) und es gestern funktionieren zu lassen, war nur Glück, oder etwas hat sich zwischen damals und heute geändert, und Sie müssen herausfinden, was es ist ist.

Wie genau Sie herausfinden, was der Fall ist und wie es behoben werden kann, hängt von den Besonderheiten der Situation ab. Es ist jedoch immer hilfreich, die Ursachen methodisch zu beseitigen, dh nicht 5 Dinge gleichzeitig zu ändern und nicht mehr zu suchen, ob dies hilft. Finden Sie heraus, welche bestimmte Ursache das Problem verursacht hat, und schreiben Sie möglicherweise auf, wie Sie es beheben können, damit Sie es nachschlagen können, wenn es in 3 Wochen erneut auftritt.

Die Verwendung der entsprechenden Diagnosetools (Debugger, Profiler, Netzwerkanalysetools) kann ebenfalls einen großen Unterschied machen.

26

Ich habe mit Code gearbeitet, der sich über Nacht zu ändern schien, und nach einer Weile kam ich zu dem Schluss, dass dies darauf zurückzuführen war, dass böswillige Elfen nachts in meine Codebasis krochen und die Dinge so änderten, dass sie gestern funktionierten, jetzt funktioniert überhaupt nicht. In der Tat funktioniert es im klassischen Schroedinbug -Stil nicht nur jetzt nicht, es ist auch klar, dass es keine Möglichkeit gibt, die es jemals haben könnte.

Im Laufe der Zeit habe ich festgestellt, dass es nur möglich ist, dass Pixies tatsächlich nichts damit zu tun haben und dass möglicherweise meine "Zeit nach Hause zu gehen, die gut genug ist" beim letzten Build nicht die detaillierten Tests und Aufmerksamkeit erhält, die es vielleicht verdient .

Meine erste Annahme, wenn ich morgens darauf stoße, ist, dass es wahrscheinlich meine Schuld ist, da ich normalerweise für meine eigenen Funktionen oder Ecken der Software verantwortlich bin, an denen ich arbeite. Meine zweite Annahme ist, dass ich diesen Kaffee jetzt genauso gut bekommen könnte. Wenn es nicht offensichtlich ist, dass ein Affe es herausfinden könnte (was es manchmal ist), stehen die Chancen gut, dass ich es geschafft habe, eine alte Version einer Bibliothek zu ziehen, die fälschlicherweise eine Datei zurückgesetzt hat, die nicht gerollt werden musste zurück oder irgendwo etwas zwischengespeichert haben, das es in den Build gebracht hat, ohne es zu überprüfen. Wenn Sie meine letzten Quellcodeverwaltungsaktivitäten durchgehen, werden in der Regel Dinge angezeigt, die ich getan habe. Durch das Bereinigen des Builds werden häufig fehlerhafte zwischengespeicherte Versionen entfernt.

Manchmal hat es wirklich nichts mit mir zu tun - jemand hat eine Abhängigkeit aktualisiert, ohne sie zu erwähnen. WindowsUpdate hat etwas installiert, das die Umgebung so verändert hat, dass mein Code nicht funktioniert hat. Es gibt viele Hintergrundmöglichkeiten, aber normalerweise geht es darum, sich zu bemannen und zu akzeptieren, dass ich, wie die meisten Menschen, im Grunde genommen ein Idiot bin.

25
glenatron

Verwenden Sie die Versionskontrolle. Machen Sie einen Unterschied oder nutzen Sie die Schuldfunktion Ihres VCS:

  • diff: Jedes VCS. Zeigt Ihnen die Unterschiede verschiedener Versionen
  • blame: zum Beispiel git. Zeigt Ihnen zeilenweise an, wer was geändert hat

Wenn es keine Versionskontrolle gibt, können Sie die Änderungsdaten von Dateien und möglicherweise die Protokollierungsfunktionen Ihres Betriebssystems überprüfen, abgesehen davon, dass Sie selbst oder Ihr Chef schuld sind.

Abgesehen davon: Kompilieren Sie alles neu, stellen Sie sicher, dass Sie auch Hilfsbibliotheken neu kompilieren.

Natürlich: Wenn Sie die Fehlerquelle gefunden haben, bleiben Sie ruhig, fragen Sie nach dem Grund für eine Änderung, erklären Sie Ihr Problem und schlagen Sie eine Lösung vor, die Sie beide glücklich macht. Schreien Sie sie/ihn nicht an, das wäre Gift für Ihre Produktivität.

Wenn es überhaupt keine Änderungen gibt, ist es Zeit zu sehen, was sich am System geändert hat. Beispielsweise haben Mac OS-Computer kürzlich auf eine neue Version von Apache aktualisiert, wodurch einige Konfigurationen ungültig wurden.

20
phresnel

Nun, hier ist ein reales Beispiel für Code, der "gestern funktioniert hat" und nicht heute ... Es ist von Anfang dieses Monats.

Die betreffende Anwendung ruft Informationen nach Datum aus einer Datenbank ab. Standardmäßig werden Daten für den aktuellen Tag abgerufen. Dies funktionierte am 8. August gut, schlug aber am 9. fehl. Es wurde nicht früher getestet. Es hätte auch am 9. September und am 10. Oktober funktioniert ...

Ein weiterer Hinweis ist, dass wir in Großbritannien sind, die fragliche Datenbank war in den USA ...

Meine Antwort auf Ihre Frage, was zuerst überprüft werden soll, besteht darin, zu überprüfen, wie Sie Ihre Daten formatieren. Wenn Sie die Felder Tag und Monat verwechseln, funktioniert dies einwandfrei, jedoch nur an einem Tag pro Monat :-)

11
Steve

Das erste, was Sie tun müssen, wenn etwas nicht mehr funktioniert, ist sich zu fragen: Was ist anders? Was hat sich verändert?

Wenn letzte Nacht etwas funktioniert hat, aber heute Morgen fehlschlägt, hat sich offensichtlich Folgendes geändert: Datum und Uhrzeit :)

Ich würde versuchen zu überlegen, ob ein Teil der Logik, an der ich arbeite, von den Daten abhängt und möglicherweise vom Zeitablauf beeinflusst wird. Es ist überraschend, wie oft dies die Ursache für solche Probleme ist.

Wenn dies fehlschlägt, sollten Sie auf jeden Fall die anderen guten Ratschläge befolgen, die hier gegeben werden.

5
urig

Behebung des Fehlers (wie auch immer). Wenn Sie dann herausfinden, wer es verursacht hat, senden Sie ihnen eine höfliche E-Mail, in der sie wissen, was schief gelaufen ist.

Jeder Codierer macht Fehler und wenn Sie anfangen zu beschuldigen, wird es ernsthaft nach hinten losgehen, wenn Sie das nächste Mal dasselbe tun. (Möglicherweise war sogar dieser Fehler dein)

Nur wenn Sie den Verdacht haben, dass sie regelmäßig nachlässig sind, sollten Sie aus ein paar Fehlern eine große Sache machen.

5
Tom Squires

... Sie führen Regressionstests aus und konzentrieren sich auf diejenigen, die fehlschlagen.

Eigentlich ist es das, was du gestern vor deiner Abreise vergessen hast, es passiert.

Du hast keine? Ok .. was wo sagst du? Schuld ? Nun ... das könnte funktionieren, dann

5
ZJR

Eine kurze Antwort (zum Schreiben), aber eine lange Antwort: Warum Programme fehlschlagen: Ein Leitfaden zum systematischen Debuggen von Andreas Zeller (der vielleicht etwas zu akademisch aussieht, aber nicht)

4
Shady M. Najib

Sie sehen in Ihrer Mailbox nach der E-Mail, die von der Continuous Integration Engine gesendet wurde, als die Komponententests fehlgeschlagen sind (oder nach der Protokollseite, wenn Sie dieses spezielle Problem nicht beobachtet haben), und sehen, wer kurz vor diesem Build eingecheckt hat .

Dann rede mit ihm oder ihr.

4
user1249

Es gibt nur zwei mögliche Gründe, warum Ihr Code heute fehlschlägt, aber gestern funktioniert hat.

Schauen Sie sich die Daten an

Die Daten enthalten etwas, das Sie nicht getestet und/oder berücksichtigt haben. Entweder werden die Daten nicht ordnungsgemäß validiert oder ein Fehler in der Logik wurde erst aufgedeckt, wenn eine logische Bedingung auftritt, die Sie nicht erwartet haben. Dies bedeutet, dass der Fehler gestern vorhanden war, sich jedoch unter gültigen Daten vor Ihnen versteckt hat.

Ich hatte einmal einen Bestellcode, der wochenlang einwandfrei lief. Ich ging eines Tages nach Hause und es starb. Die Untersuchung am nächsten Tag ergab, dass ich einen Fehler in einer Reihe von Funktionsaufrufen versteckt hatte. In einer schwach typisierten Sprache habe ich eine Ganzzahl deklariert, wenn ich ein langes int hätte verwenden sollen. Die Sprache hat die Konvertierung zwischen den beiden automatisch durchgeführt, bis dies nicht mehr möglich war, da die Anzahl die in eine Ganzzahl passende Zahl überschritt. Das System ist unter der Bestellnummer 32768 ausgefallen.

Schau dir an, was sich geändert hat

Schau dir an, was sich geändert hat, seit es funktioniert hat. Hat der IT-Bereich ein Betriebssystem-Update veröffentlicht? Hat ein anderer Codierer den von Ihrem Programm verwendeten Code geändert? Hat sich die Berechtigung des Benutzers geändert? Wenn Sie feststellen, was sich geändert hat, finden Sie häufig den Fehler.

4
Andrew Neely

Binär hacken

funktioniert besonders gut bei schwierigen JavaScript-Fehlern. Kommentieren Sie im Grunde die Hälfte des Codes, und prüfen Sie, ob Sie den Fehler erhalten. Wenn Sie dies tun, befindet er sich in dieser Hälfte des Codes. Nochmals halbieren und weitermachen.

Wenn Ihr Code gut gekapselt ist, ist dies ein fantastisches, zeitsparendes und stressfreies Tool.

Sobald Sie den schuldigen Code gefunden haben, lohnt es sich oft, den Fehler auf einer eigenen Testseite zu isolieren.

3
chim

Und was kann man natürlich tun, um nicht in einer solchen Situation zu sein?

Wenn Sie sich mit dieser Frage befassen, sollten Sie sich Continuous Integration (CI) ansehen. Einfach ausgedrückt: CI ist ein Prozess, bei dem Entwickler häufig (bis zu mehrmals täglich) den gesamten Code integrieren und testen. Die Idee ist, dass Änderungen an einem Modul, die ein anderes Modul beschädigen, schnell gefunden werden.

In der Praxis verwenden die meisten Teams, die CI einsetzen, einen CI-Server (siehe: Wikipedia-Liste ). Der CI-Server ist normalerweise so eingerichtet, dass er das SCM-Repository überwacht und einen Build startet, wenn Änderungen festgestellt werden. Wenn der Build abgeschlossen ist, führt er eine Reihe automatisierter Tests durch und veröffentlicht die Ergebnisse per E-Mail und/oder Webseite des Builds und der Tests sowie die Änderungen, die den Build verursacht haben. Wenn etwas den Build oder die Tests unterbricht, müssen Sie hoffentlich nur eine sehr kleine Änderung anzeigen, damit sie schneller gelöst wird.

Es gibt hier noch weitere Fragen zu dem zu verwendenden CI-Server, daher lasse ich Sie daran interessiert sein. Persönlich bin ich ein großer Fan von Jenkins.

[Was soll ich tun, wenn Dinge kaputt gehen?]

Wie andere bereits gesagt haben, finden Sie heraus, was kaputt gegangen ist, und versuchen Sie, das Problem zu beheben. Zeit damit zu verbringen, Schuldzuweisungen zu machen, ist Zeit, die aufgewendet wird, um das Problem nicht zu lösen.

3
jwernerny

Meine natürliche Reaktion ist immer, andere zu beschuldigen, aber im Laufe der Zeit wurde mir klar, dass normalerweise ich schuld bin. Zusätzlich zu all den hervorragenden Kommentaren oben ist es wichtig, dass Sie selbst aufzeichnen, was der letzte Grund war. Es spielt keine Rolle, ob Sie ein Wiki verwenden, das mit anderen Teammitgliedern geteilt wird, ein privates Twiki, Evernote, ein Logbuch oder ein gutes Gedächtnis. Das Wichtigste ist, dass Sie im Moment die Antwort finden (und wieder arbeiten möchten!), Den Grund aufzuzeichnen.

3
Ant

Wenn Ihre üblichen Methoden zur Fehlerverfolgung nicht funktionieren und alles völlig durcheinander ist, kann es wunderbar sein, ein Backup zu haben, das Sie einfach wiederherstellen können.

Dies ist, was ich lokal laufe, automatisch jede Stunde von 8 bis 18 Uhr:

rdiff-backup /path/to/mystuff /path/to/mybackup

Einfach, was?

Wenn Sie jemals etwas wiederherstellen müssen, verwenden Sie

rdiff-backup -r 24h /path/to/mybackup/specific/dir /tmp/restored

rdiff-backup speichert nur Dateien, die sich unterscheiden. Sie können rdiff-backup unter Linux, Mac und Win verwenden.

Dies sollte natürlich nicht Ihr einziges Backup sein. Es ist jedoch äußerst einfach und kostengünstig, ein lokales Backup zu erstellen.

Nun, ich würde dies nicht als normale Fehlerbehebungsmethode empfehlen, aber wenn alles andere fehlschlägt, ist es ein Fallback.

2
olafure

Der Fehler war möglicherweise bereits vorhanden, wurde jedoch durch externe Faktoren oder tiefgreifende Systemprobleme verdeckt.

Das ist mir passiert. Zwischen zwei Builds unseres Projekts ist ein Fehler aufgetreten. Die einzige Änderung, die wir vorgenommen hatten, bestand buchstäblich darin, auf einen neueren Build der zugrunde liegenden Bibliotheken zu aktualisieren.

Natürlich haben wir ihnen die Schuld gegeben. Aber die einzige Änderung, die sie vorgenommen hatte, bestand darin, einige Header für eine schnellere Kompilierung umzugestalten. Ich stimmte zu, dass das System nicht kaputt gehen sollte.

Nach langem Debuggen stellte sich heraus, dass das Problem ein Schurkenzeigerfehler war, der seit Jahren in my Code latent war. Irgendwie wurde es nie ausgelöst, bis ihr Refactoring die Anordnung der ausführbaren Datei geändert hatte.

2
Matthew Scouten

Wenn es nicht mehr funktioniert, haben Sie vermutlich die Symptome festgestellt, dass es nicht funktioniert, dh es hängt oder wirft dem Benutzer einen bestimmten Fehlerdialog zurück.

Wenn die einzige Beschreibung des Problems "es funktioniert nicht" lautet, müssen Sie zunächst weitere Informationen zu den Symptomen des Problems sammeln.

Dann suchen Sie nach möglichen Ursachen, entweder über Protokolle oder über die versuchte Wiederherstellung des Problems oder über eine Kombination aus beiden - je nachdem, wie Ihr System eingerichtet ist.

Dann fangen Sie an, sie auszuschließen.

2
temptar

Das passiert normalerweise, wenn ich Urlaub mache :-)

Im Ernst, ich würde ihnen zuerst sagen:

  • Ich werde es untersuchen um zu sehen, was falsch ist und was die Wurzel sein könnte

  • Ich werde die Basis berühren in 30-60 Minuten, sobald ich die Gelegenheit hatte zu sehen was passiert

Nach dieser Zeit kann ich eine Schätzung riskieren, was möglicherweise passiert ist und wie lange es dauern wird, bis das Problem behoben ist, wenn es noch nicht behoben ist, und gegebenenfalls welche Daten wir möglicherweise verloren haben (aber ich habe gute Backups, sodass dies niemals geschieht hoffnungsvoll).


Was die Schuld betrifft:

  • wenn es nur ein Tippfehler eines Kollegen ist, muss es nicht erwähnt werden: Scheiße passiert und der Schreck vor dem Fehler hat ihm höchstwahrscheinlich eine Lektion erteilt, und hoffentlich wird er es nicht wieder tun.

  • wenn er absichtlich etwas getan hat, von dem ich ihm gesagt habe, dass er es nicht tun soll (z. B. dem neuen Mitarbeiter das Root-Passwort des Produktionsservers geben und ihm sagen, dass er direkt ohne Aufsicht Änderungen daran vornehmen soll) (ja, das ist bereits passiert ...), dann ich muss es erwähnen.

2
wildpeaks

es hat gestern funktioniert, da es richtig verwendet wurde.

sie finden, dass andere Leute Dinge auf eine Art und Weise benutzen, von der es nicht annimmt, dass sie eine gute Art sind, Dinge zu zerbrechen.

es ist immer gut, den Code früh am Tag zu aktualisieren, da Sie so eine gute Testumgebung haben.

Backup!

1
Robert