Zum Inhalt springen
L

Das Video kommt von YouTube: erst beim Abspielen verbindet sich die Seite mit YouTube (Google).

Debugging Kenntnisse // Business Intelligence in der Praxis

datenanalyst․com6:20 215 Aufrufe veröffentlicht Auf YouTube

Das Wichtigste aus dem Video

Tipp auf eine Zeit – das Video springt genau dorthin.

Transkriptautomatisch erstellt · 36 Zeilen
Herunterladen
  1. 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
  2. verbessern konnte bevor wir loslegen können bitte ich euch diesen kanal zu abonnieren um noch mehr videos für den
  3. wissenstransfer im bereich business intelligence und data warehousing anbieten zu können und bedanke mich sehr herzlich bei allen die diesen knall
  4. dadurch unterstützen jetzt starten wir los unabhängig davon ob der anfänger oder erfahrener softwareentwickler bist wird man wahrscheinlich früher oder
  5. später auch bei dir einmal einen fehler im code entdecken wir alle haben fehler in unseren anwendungen weil niemand alles über das
  6. programmieren weiß und wir machen manchmal fehler schließlich kann man nicht aufhören menschlich zu sein
  7. es ist wichtig aus diesen fehlern zu lernen und wiederholungen zu vermeiden indem du techniken entwickelt um deine programmier- und debugging fähigkeiten
  8. zu verbessern fehler sind in erster linie logisch und das sind taktisch einige von ihnen manifestieren sich durch ausnahmen oder
  9. abstützen während andere möglicherweise nur bei verwendung der software zu beobachten sind
  10. 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
  11. mit deiner software oder deinen entwicklungs code ist und nicht um etwas anderes wenn das feststeht kann zum nächsten schritt gegangen werden wenn
  12. 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
  13. 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
  14. eine allgemeine klassifizierung notwendig und zwar bei dieser klassifizierung stuft man das problem hinsichtlich seiner auswirkungen
  15. entsprechend 1 sind es akute und schwerwiegende probleme welche durch fehlerhaften code entstanden sind oder sind das unbedeutende probleme für
  16. 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
  17. 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
  18. führt in der aufbereitung dieser daten nachdem das problem nun aufgenommen und klassifiziert wurde kann nun endlich mit der konkreten lösungsfindung
  19. schrägstrich debugging begonnen werden meine vorgehensweise ist die eingrenzung des problems auf immer kleinere abschnitte und durch testen und
  20. ausschlussverfahren angenommen es wird eine falsche zahl in einem bericht angezeigt dann künftig sozusagen vom frontend nach backend die ursache
  21. einzugrenzen schließlich lässt sich das problem mit hoher wahrscheinlichkeit in einer der folgenden drei kategorien einordnen
  22. kategorie 1 es handelte sich um einen syntax fehler kategorie 2 es handelt sich um eine implementierungsfehlern und kategorie 3
  23. 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
  24. 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
  25. die bank kommentare hinzufügen wo die logik auch komplex ist auch das verwenden einer durchgehend schreibweise von variablen
  26. 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
  27. fehlerhaften code abschnittes nochmals zu reflektieren ob es nicht auch eine einfachere lösung gibt oft ist es so dass ich einen bestimmten befehlssatz
  28. oder software partnern nicht wirklich verstanden habe und deshalb eine komplexe lösung implementiert habe bei der kategorie 3 bei logischen fehlern
  29. hilft es inhaltlich die anforderungen nochmals gemeinsam mit dem kunden oder auch cooling durchzugehen ich konnte auf mal stand beobachten dass
  30. 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
  31. 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
  32. drei stunden das ist unterschiedlich eine andere arbeit zu verrichten oder sich abzulenken
  33. 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
  34. 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
  35. 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
  36. erfolg

Zum Nachlesen