Verwandeln Sie frustrierende Debugging-Sitzungen in systematische Problemlösungen mit bewährten Techniken, leistungsstarken Tools und methodischen Ansätzen, die über jeden Technologie-Stack hinweg funktionieren.
Die Skill-ZIP herunterladen
In Claude hochladen
Gehe zu Einstellungen → Fähigkeiten → Skills → Skill hochladen
Einschalten und loslegen
Teste es
Verwendung von "debugging-strategies". Meine API gibt intermittierend 500-Fehler zurück. Die Logs zeigen 'connection refused', aber nur manchmal.
Erwartetes Ergebnis:
Das klingt nach einem intermittierenden Verbindungsproblem. Lassen Sie uns systematisches Debugging anwenden:
**1. Informationen sammeln:** Prüfen Sie, welche spezifischen Anfragen fehlschlagen, Zeitmuster und vergleichen Sie funktionierende mit fehlschlagenden Anfragen.
**2. Hypothesen bilden:** Könnte Connection-Pool-Erschöpfung, DNS-Auflösungsverzögerungen, Load-Balancer-Probleme oder Timeout-Einstellungen sein.
**3. Binäre Suche:** Beginnen Sie zu prüfen, ob es mit Hochverkehrsperioden korreliert. Sehen Sie sich Connection-Pool-Metriken an.
**4. Nächste Schritte:** Prüfen Sie auf Connection-Leaks in Ihrem Code, überprüfen Sie Timeout-Konfigurationen und untersuchen Sie Load-Balancer-Logs während Fehlerperioden.
Verwendung von "debugging-strategies". Der Speicher meiner Node.js-App wächst ständig, bis sie abstürzt. Wie finde ich den Memory-Leak?
Erwartetes Ergebnis:
Lassen Sie uns Memory-Profiling nutzen, um den Leak zu finden:
**1. Memory-Tracking aktivieren:** Fügen Sie periodische Heap-Snapshots mit v8.writeHeapSnapshot() hinzu oder nutzen Sie clinic.js
**2. Mit Monitoring reproduzieren:** Führen Sie Ihre App aus und lösen Sie die vermuteten Operationen aus, während Sie die Heap-Nutzung überwachen
**3. Snapshots vergleichen:** Erstellen Sie Snapshots vor und nach vermuteten Operationen, suchen Sie nach wachsenden Objektzahlen
**4. Häufige Ursachen:** Prüfen Sie auf nicht entfernte Event-Listener, Closures mit Referenzen oder wachsende Caches
Sicherheitsaudit
SicherSecurity scanner flagged 48 potential issues in markdown documentation. After evaluation, all findings are false positives. The flagged patterns are code examples and documentation within markdown files, not executable code. External commands shown are educational CLI examples (git bisect, etc.). Network references are localhost debugging endpoints. This is a legitimate debugging education skill with no security concerns.
Qualitätsbewertung
Was du bauen kannst
Produktions-Incidents debuggen
Untersuchen und diagnostizieren Sie Produktions-Bugs mit systematischen Ansätzen, sammeln Sie sicher Beweise ohne Änderungen vorzunehmen und identifizieren Sie Ursachen für schnelle Lösungen.
Performance-Engpässe beheben
Proflieren Sie Anwendungen, um langsame Operationen zu identifizieren, analysieren Sie Speichernutzungsmuster und optimieren Sie Code basierend auf tatsächlichen Performancedaten statt Vermutungen.
Schwer findbare Bugs aufspüren
Wenden Sie binäre Suche, differentielles Debugging und Trace-Analyse an, um Bugs zu finden, die nur unter bestimmten Bedingungen oder in Produktionsumgebungen auftreten.
Probiere diese Prompts
Ich sehe diesen Fehler: [ERROR_MESSAGE]. Der Fehler tritt auf, wenn [WHAT_TRIGGERS_IT]. Können Sie mir helfen, systematische Debugging-Schritte anzuwenden, um die Ursache zu finden?
Meine/Mein [APPLICATION/COMPONENT] läuft langsam. Es dauert [TIME], um [OPERATION] abzuschließen. Ich habe [WHAT_YOU_TRIED] versucht. Helfen Sie mir, Profiling-Tools zu nutzen, um den Engpass zu finden.
Ich habe einen Bug, der [FREQUENCY] auftritt, aber ich kann ihn nicht zuverlässig reproduzieren. Es scheint [WHAT_IT_AFFECTS] zu betreffen. Welche Strategien kann ich nutzen, um das Problem einzugrenzen?
Helfen Sie mir, ein Produktionsproblem sicher zu debuggen. Ich kann [ERROR/SYMPTOM] in [WHERE_YOU_CAN_SEE_IT] sehen. Was sollte ich zuerst prüfen und wie vermeide ich, die Situation zu verschlimmern?
Bewährte Verfahren
- Reproduzieren Sie das Problem immer lokal, bevor Sie Fixes versuchen, um sicherzustellen, dass Sie das Problem verstehen
- Ändern Sie während des Debuggings immer nur eine Sache, um zu isolieren, was das Problem tatsächlich behebt
- Dokumentieren Sie Ihre Erkenntnisse und Hypothesen während des Prozesses, um zukünftige Debugging-Sitzungen zu unterstützen
- Nutzen Sie die Versionsverlauf-Historie (git bisect), um zu finden, wann Regressionen eingeführt wurden
Vermeiden
- Mehrere Änderungen gleichzeitig vornehmen, ohne zu verfolgen, was das Problem behoben hat
- Annehmen, dass das Problem komplex ist, obwohl es ein einfacher Tippfehler oder Konfigurationsproblem sein könnte
- Fehlermeldungen und Stack-Traces ignorieren – sie enthalten normalerweise wertvolle Hinweise
- In der Produktion debuggen ohne geeignetes Monitoring oder Rollback-Pläne
Häufig gestellte Fragen
Was ist der erste Schritt beim Debugging eines Problems?
Wie debugge ich intermittierende Bugs, die schwer zu reproduzieren sind?
Wann sollte ich Logging vs. einen Debugger nutzen?
Wie finde ich Memory-Leaks in meiner Anwendung?
Was ist binäres Such-Debugging?
Wie debugge ich Produktionsprobleme sicher?
Entwicklerdetails
Autor
sickn33Lizenz
MIT
Repository
https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/debugging-strategiesRef
main
Dateistruktur