Debugging in der Praxis
24. April 2020 21:01
Falls noch jemand ein Geschenk für einen Entwickler sucht 
: Quietscheentchen-Debugging (Rubber duck debugging)
: Quietscheentchen-Debugging (Rubber duck debugging)
Re: Debugging in der Praxis
27. April 2020 07:46
Hallo,
eine sehr gute Methode. Insbesondere, wenn der Programmierer es dem Anwender erklären soll, was er für einen Stuss programmiert hat.
Bei mir führt das regelmäßig dazu, das ich nach zwei Sätzen sage: "Das muss ich wohl noch mal üben"
Gruß Fiddi
eine sehr gute Methode. Insbesondere, wenn der Programmierer es dem Anwender erklären soll, was er für einen Stuss programmiert hat.
Bei mir führt das regelmäßig dazu, das ich nach zwei Sätzen sage: "Das muss ich wohl noch mal üben"
Gruß Fiddi
Re: Debugging in der Praxis
27. April 2020 08:37
Die Methode wende ich auch schon seit einigen Jahren an, ohne zu wissen, dass es dafür sogar einen eigenen Begriff gibt. 
Anfangs hatte ich immer einen erfahrenen NAV-Programmierer um Hilfe gebeten.
Da er natürlich nicht wusste, was für eine Funktionalität ich umsetzen sollte, musste ich ihm einerseits den Prozess im Detail erläutern und anschließend den Programmcode.
Bei der Erklärung des Programmcodes fiel mir der Fehler dann selber auf.
Nachdem mir das ein paar mal passiert war, hatte ich beim nächsten mal dann einfach einen Azubi aus dem ersten Ausbildungsjahr oder gar einen Praktikanten um Hilfe gebeten.
Die Blicke waren göttlich. "Wie kann ich dir dabei behilflich sein?" - "Warte es einfach ab, dann wirst du es herausfinden."
Die Methode funktioniert hervorragend und ich kann sie jedem nur wärmstens empfehlen.
Anfangs hatte ich immer einen erfahrenen NAV-Programmierer um Hilfe gebeten.
Da er natürlich nicht wusste, was für eine Funktionalität ich umsetzen sollte, musste ich ihm einerseits den Prozess im Detail erläutern und anschließend den Programmcode.
Bei der Erklärung des Programmcodes fiel mir der Fehler dann selber auf.
Nachdem mir das ein paar mal passiert war, hatte ich beim nächsten mal dann einfach einen Azubi aus dem ersten Ausbildungsjahr oder gar einen Praktikanten um Hilfe gebeten.
Die Blicke waren göttlich. "Wie kann ich dir dabei behilflich sein?" - "Warte es einfach ab, dann wirst du es herausfinden."
Die Methode funktioniert hervorragend und ich kann sie jedem nur wärmstens empfehlen.
Re: Debugging in der Praxis
27. April 2020 09:15
Hallo,
wenn es um die Fehlersuche geht, reicht bei mir oft ein halber Satz. Danach folgt dann ein "Danke, mir ist gerade aufgefallen, woran es liegt."
Ich verstehe nicht, warum sich Programmierer dagegen sperren, mit Kunden zu tun zu haben, die sind die besten Versuchskaninchen um eigene Marotten abzulegen, und sich darauf zu konzentrieren, was der Anwender benötigt, und nicht eigenen Hirngespinsten nach zu rennen.
In meiner früheren Firma war es üblich, das zum Zwecke der QS jeder Sourcecode noch von einem Kollegen gegen gelesen wurde. Der hat einen dann auf Fehler aufmerksam gemacht und ggf. auch Verbesserungsvorschläge gemacht. Davon hatten dann am Ende alle was, Der Ersteller, weil seine Fehler gefunden wurden, und er Verbesserungen an seinem Code vornehmen konnte, und der Prüfer, weil er evtl. auch neue Ideen mitnehmen konnte.
Das funktioniert (zumindest wenn die beteiligten über Wissen verfügen) meistens besser oder zumindest genauso gut wie stundenlange Testläufe, die nur einen Bruchteil der möglichen Fehler prüfen können. (womit ich nicht sagen will, dass das Test- Famework sinnlos ist, aber es prüft halt nur etwa 1-2 % aller möglichen Testfälle, was aber oft schon herrausfordernd ist.
Ein Test- Framework das vernünftig testet, ist aus meiner Erfahrung, im Quellcode genauso groß oder größer als das eigentliche Programm und erfordert Programmierer, die besser sind als der Ersteller des zu testendes Programms, und die herausfinden wollen, was nicht funktioniert und nicht nur schauen, ob das Programm startet)
Gruß Fiddi
Gruß Fiddi
wenn es um die Fehlersuche geht, reicht bei mir oft ein halber Satz.
Danach folgt dann ein "Danke, mir ist gerade aufgefallen, woran es liegt."Ich verstehe nicht, warum sich Programmierer dagegen sperren, mit Kunden zu tun zu haben, die sind die besten Versuchskaninchen um eigene Marotten abzulegen, und sich darauf zu konzentrieren, was der Anwender benötigt, und nicht eigenen Hirngespinsten nach zu rennen.
In meiner früheren Firma war es üblich, das zum Zwecke der QS jeder Sourcecode noch von einem Kollegen gegen gelesen wurde. Der hat einen dann auf Fehler aufmerksam gemacht und ggf. auch Verbesserungsvorschläge gemacht. Davon hatten dann am Ende alle was, Der Ersteller, weil seine Fehler gefunden wurden, und er Verbesserungen an seinem Code vornehmen konnte, und der Prüfer, weil er evtl. auch neue Ideen mitnehmen konnte.
Das funktioniert (zumindest wenn die beteiligten über Wissen verfügen) meistens besser oder zumindest genauso gut wie stundenlange Testläufe, die nur einen Bruchteil der möglichen Fehler prüfen können. (womit ich nicht sagen will, dass das Test- Famework sinnlos ist, aber es prüft halt nur etwa 1-2 % aller möglichen Testfälle, was aber oft schon herrausfordernd ist.
Ein Test- Framework das vernünftig testet, ist aus meiner Erfahrung, im Quellcode genauso groß oder größer als das eigentliche Programm und erfordert Programmierer, die besser sind als der Ersteller des zu testendes Programms, und die herausfinden wollen, was nicht funktioniert und nicht nur schauen, ob das Programm startet)
Gruß Fiddi
Gruß Fiddi
Re: Debugging in der Praxis
27. April 2020 10:37
Wir haben bei uns in der Firma auch eine mehrstufige QS für die NAV-Entwicklung.
1. Developer: Programmiert und testet gegen die technische Spezifikation
2. Lead-Developer: Prüft die Anpassung gegen die Entwicklungsrichtlinien ("No-Gos", "Best Practices", Guidelines, Performance-Orientierung, Dokumentation, ...)
3. Consultant: Testet erneut gegen die technische Spezifikation mit Blick auf den gesamten Geschäftsprozess
4. Keyuser: Testet gegen seine Prozess-Spezifikation
Gefundene "Fehler" entpuppten sich in der Vergangenheit häufig als "ungenaue Spezifikation mit hohem Interpretationsspielraum".
Hier haben wir die Anforderungen an die Spezifikationen (sowohl die Prozess-Spezifikation, als auch die technische Spezifikation) angepasst, so dass es in den allermeisten Fällen nicht mehr zu Interpretationsspielräumen kommt.
Die Keyuser müssen neben der Anforderung auch eindeutige "Akzeptanzkriterien" definieren, die Consultants müssen die anzupassenden Objekte (soweit bekannt) eindeutig benennen.
Aussagen wie "wie im Altsystem" oder "in allen Pages/Reports" sind in den Spezifikationen nicht mehr erlaubt.
1. Developer: Programmiert und testet gegen die technische Spezifikation
2. Lead-Developer: Prüft die Anpassung gegen die Entwicklungsrichtlinien ("No-Gos", "Best Practices", Guidelines, Performance-Orientierung, Dokumentation, ...)
3. Consultant: Testet erneut gegen die technische Spezifikation mit Blick auf den gesamten Geschäftsprozess
4. Keyuser: Testet gegen seine Prozess-Spezifikation
Gefundene "Fehler" entpuppten sich in der Vergangenheit häufig als "ungenaue Spezifikation mit hohem Interpretationsspielraum".
Hier haben wir die Anforderungen an die Spezifikationen (sowohl die Prozess-Spezifikation, als auch die technische Spezifikation) angepasst, so dass es in den allermeisten Fällen nicht mehr zu Interpretationsspielräumen kommt.
Die Keyuser müssen neben der Anforderung auch eindeutige "Akzeptanzkriterien" definieren, die Consultants müssen die anzupassenden Objekte (soweit bekannt) eindeutig benennen.
Aussagen wie "wie im Altsystem" oder "in allen Pages/Reports" sind in den Spezifikationen nicht mehr erlaubt.
Re: Debugging in der Praxis
26. März 2021 15:07
Nach über einem Jahr im Homeoffice hier mal ein Gruß von meinen "Debugginghelfern". Der rechte saugt die Bugs sogar gleich mit weg 
.
.Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.