Debugging Kenntnisse // Business Intelligence in der Praxis
datenanalyst․com
https://www.youtube.com/watch?v=6wHlOJ7-xgY

Transkript (automatisch erstellt)

0:00 hallo zu einem neuen video auf dem business intelligence kanal heute möchte ich erklären wie ich meine debugging fähigkeiten im laufe der jahre
0:08 verbessern konnte bevor wir loslegen können bitte ich euch diesen kanal zu abonnieren um noch mehr videos für den
0:15 wissenstransfer im bereich business intelligence und data warehousing anbieten zu können und bedanke mich sehr herzlich bei allen die diesen knall
0:24 dadurch unterstützen jetzt starten wir los unabhängig davon ob der anfänger oder erfahrener softwareentwickler bist wird man wahrscheinlich früher oder
0:35 später auch bei dir einmal einen fehler im code entdecken wir alle haben fehler in unseren anwendungen weil niemand alles über das
0:44 programmieren weiß und wir machen manchmal fehler schließlich kann man nicht aufhören menschlich zu sein
0:52 es ist wichtig aus diesen fehlern zu lernen und wiederholungen zu vermeiden indem du techniken entwickelt um deine programmier- und debugging fähigkeiten
1:03 zu verbessern fehler sind in erster linie logisch und das sind taktisch einige von ihnen manifestieren sich durch ausnahmen oder
1:10 abstützen während andere möglicherweise nur bei verwendung der software zu beobachten sind
1:16 beginnen wir im ersten punkt bei der identifikation eines problems du musst dir sicher sein dass es sich um ein problem handelt welches im zusammenhang
1:28 mit deiner software oder deinen entwicklungs code ist und nicht um etwas anderes wenn das feststeht kann zum nächsten schritt gegangen werden wenn
1:40 das problem neu ist versuche herauszufinden wie lange es besteht und ob es nur für dich oder auch andere personen sichtbar ist kaum wir nun zum
1:51 nächsten schritt und zwar der klassifizierung des problems wenn es sich tatsächlich um ein problem in der software handelt ist dass als nächstes
2:00 eine allgemeine klassifizierung notwendig und zwar bei dieser klassifizierung stuft man das problem hinsichtlich seiner auswirkungen
2:10 entsprechend 1 sind es akute und schwerwiegende probleme welche durch fehlerhaften code entstanden sind oder sind das unbedeutende probleme für
2:22 das operative tagesgeschäft an dieser stelle kann auch bereits bestimmt werden ob es sich um eine externe einwirkung oder interne handelt ein beispiel für
2:34 eine externe einwirkung wäre wenn ihm vor system durch ein wartungsfenster plötzlich spalten in der bellen umbenannt wurde und es dazu zu fehlern
2:45 führt in der aufbereitung dieser daten nachdem das problem nun aufgenommen und klassifiziert wurde kann nun endlich mit der konkreten lösungsfindung
2:56 schrägstrich debugging begonnen werden meine vorgehensweise ist die eingrenzung des problems auf immer kleinere abschnitte und durch testen und
3:09 ausschlussverfahren angenommen es wird eine falsche zahl in einem bericht angezeigt dann künftig sozusagen vom frontend nach backend die ursache
3:21 einzugrenzen schließlich lässt sich das problem mit hoher wahrscheinlichkeit in einer der folgenden drei kategorien einordnen
3:32 kategorie 1 es handelte sich um einen syntax fehler kategorie 2 es handelt sich um eine implementierungsfehlern und kategorie 3
3:44 es handelt sich um einen logischen bzw inhaltlichen fehler bei syntax fehler kann das eindrücken von software-code stark helfen weil ein eingedrückter chor
3:59 abschnitt besser zu lesen ist einfach zu verstehen einfach auch zu ändern zu warten und zu erweitern und somit leichter fehler zu finden sind und zu
4:12 die bank kommentare hinzufügen wo die logik auch komplex ist auch das verwenden einer durchgehend schreibweise von variablen
4:22 um befehle erhöht die lesbarkeit und nach reduziert die häufigkeit von syntax fehlern bei implementierungsfehlern kann es helfen die primäre funktion des
4:36 fehlerhaften code abschnittes nochmals zu reflektieren ob es nicht auch eine einfachere lösung gibt oft ist es so dass ich einen bestimmten befehlssatz
4:47 oder software partnern nicht wirklich verstanden habe und deshalb eine komplexe lösung implementiert habe bei der kategorie 3 bei logischen fehlern
5:01 hilft es inhaltlich die anforderungen nochmals gemeinsam mit dem kunden oder auch cooling durchzugehen ich konnte auf mal stand beobachten dass
5:11 nur durch die erklärung des problems dem entwickler den knoten gelöst hat und die lösung parat hatte nun waren diese drei tipps hilfreich aber dennoch kann es
5:24 vorkommen dass man nach vielen stunden noch immer keinen schritt weiter ist man befindet sich im sogenannten tunnelblick in so einem fall hilft es für zwei bis
5:37 drei stunden das ist unterschiedlich eine andere arbeit zu verrichten oder sich abzulenken
5:45 da unser unterbewusstsein wie ein rechenprogramm trotzdem weiter an einer lösung arbeiten wird ohne dass wir es bewusst tun und plötzlich eine andere
5:56 sichtweise auf das problem haben und sehr häufig dann auch eine lösung finden ich hoffe ich konnte euch durch diese tipps das lösen von problemen
6:07 beziehungsweise debugging fähigkeiten unterstützen und wünsche mir natürlich dass wir auch im nächsten video der weisheit bis dahin alles gute und viel
6:18 erfolg