Bei meinem aktuellen Arbeitgeber müssen wir auf jahrealter SW herum doktorn. Wenn man ein "neuschreiben" auch nur erwähnt, bekommt man Diskussionen an den Hals. Es ist so ermüdend, ständig gegen so ein Chaos anzukämpfen. Es gibt keine Requirements, keine Architektur, kein Testumfeld und und und. Alle coden einfach auf diesem alten Klotz herum und müssen sich dann auch noch anhören, dass man nicht performant ist 😒
Kündigen und weitergehen. Du musst doch nicht deine Lebenszeit (und deinen eigenen Fortschritt) mit Dingen verschwenden, die dich frustrieren. Entweder der bisherige AG findet Leute, die richtig Lust auf Altsysteme haben (die gibt es!) oder er wird umdenken müssen. Ein "neuschreiben" löst meist die Probleme nicht, da ähnliche Probleme wieder eingefügt werden, imho müssen neue Features / Featureänderungen an das bisherige System über Schnittstellen angekoppelt werden. Das bisherige System wird damit nach und nach obsolet und kann organisch ausgephast werden.
Glaub mir, wenn das Ding neu geschrieben wird, werden 80% der Fehler wieder gemacht, da wegen Zeitdruck ein Großteil des alten scheiß Codes kopiert wird. Been there many times.
Wenn man überhaupt versteht, was der Code macht bzw. machen soll. Wir haben einen Stack aus einem wohlbekanntem asiatischen Land, in dem void-void-Funktionen beliebig globale Variablen ändern. Versteht kein Mensch und keiner traut sich, den Moloch auch nur ansatzweise zu refactors. So schafft man Kundenbindung 😮
Zum Rucksack: es reicht völlig, wenn einmal ein einziger Zahn des Reißverschlusses beim Schließen nicht da landet, wo er hinsoll. Dann braucht es kaum Kraft, dass sich der Reißverschluss von dort aus in beide Richtungen öffnet. Wenn der beim nächsten Mal wieder richtig sitzt, dann hält der Reißverschluss so, wie gewohnt.
Hey, ja sowas war auch meine Vermutung - aber wie schon gesagt, das Risiko war mir einfach zu groß - der jetzige Rucksack hat nochmal eine Schnalle um das Fach zusätzlich zu sichern. Gruß David
Analog zur Physik (dort geht es um Bewegungsvorgänge und die sie beeinflussenden Kräfte) gilt es in der SW-Entwicklung die Einflüsse im Lauf der Zeit einzukalkulieren. Irgendwann kommt aber auch bei einem hoch spezialisierten Team der kritische Punkt, ab dem es zuviele Einflüsse werden und man nur noch raten kann, was das SW-Produkt (nicht) tut.
@@DavidTielkeun der Physik ist das Gegenteil der Fall und führt zu Komplexitätsvermehrung. Cynefin ist ein hervorragendes Tool, wie dem zu begegnen sei.
Hey Herr Thielke, macen Sie doch mal ein Video darüber, warum Feature-Creep ein echtes Problem ist und warum ein ordentliches logging ein wichtiger Punkt ist, den man nicht vernachlässigen sollte.
Hab das in einer Siemens Steuerung. Ich schieb es immer einfach auf Siemens. Ab und zu wird einfach mal ein Wert zwischen PLC unf HMI nicht synchronisiert. Funktioniert 1000 mal und beim 1001 mal ist der Wert nicht da -.- Und das mit den Objektiven hatte ich leider auch schon. Ruhe in Frieden mein 70-300mm.
Hey, das Problem dabei ist, dass man mit Unit Tests isolierte Einheiten testet und gerade Heisenbugs oftmals erst bei der Integration (vor allem der asynchronen) von solchen Einheiten auftritt, daher helfen Unit Tests da zwar in manchen Fällen, aber oftmals nicht in allen - besonders bei Race Conditions. Gruß David
Meine Unittest sind sehr strikt (was die Kommunikation mit Dependecies betrifft). So dass auch ein Teil dieser möglichen Probleme auffallen. Aber am Ende hast du recht, dass es keine 100% gibt.
Kannst du nicht vielleicht mal ein komplett Tutorial machen und eine Software und das komplette entwickeln dieser dabei erläutern, was warum und wieso? Soetwas vermisse ich noch irgendwie. Jch programmiere jetzt schon ein gut 2 Jahre, wann immer ich Zeit habe (als Privatperson - also nicht professionell). Ihre Videos schaue ich auch seit einigen Wochen, finde diese sehr gut. Mir fehlt aber bei allen Kursen/Büchern etc immer so goldene leitende Faden, der wirklich im Sinne von "Best Practice" seinen Code nun aufbaut und wann man was und warum so macht. Man erfährt immer wieder einzelne Inhalte, die man aber früher oder später wieder vergisst, weil man den Sinn dahinter und das Wann (besser zu) verwenden ist nicht erfährt.
Hey, danke für den Vorschlag, leider ist das nicht so einfach umzusetzen. Also einfach wäre es schon, aber meine Plattform wäre halt .NET/C#/NDEPEND/Azure DevOps und damit hole ich halt nur einen kleinen Bruchteil der Zuschauer ab, weil hier Leute zuschauen die mit Python, Java, Cobol, C++ etc. entwickeln. Ich verstehe deinen WUnsch total, sowas hätte ich früher auch gerne gehabt - aber da es viel Arbeit für zu wenige für Euch wäre, konzentriere ich mich lieber auf die Themen die alle weiterbringen. Es gibt aber genug sehr gute Kanäle hier die das für verschiedenen Plattformen zeigen. Gruß David
Wie die beste Praxis aussieht, kommt darauf an, was damit erreicht werden soll. Außerdem macht es einen großen Unterschied, ob du etwas ganz alleine entwickelst und keine Stakeholder außer dich selbst hast, oder ob du in einem Team ein Produkt für einen Kunden entwickelst.
Im Endeffekt ist Programmierung die Frage, wie sich der Compiler / Interpreter / Transpiler ... verhält, wenn er auf ein Schlüsselwort trifft (oder dieses i.V. mit anderen Schlüsselwörtern (nicht) tut ). Und auch bei anderen Plattformen gibt es (andere) Änderungsraten um von der Idee zum SW-Produkt zu kommen. Begriffe wie Architektur, SOLID, Clean Code, SW-Tests,... sind Empfehlungen für den Menschen um (häufige(re)) Änderungen oder Erweiterungen an einer (zentralen) Stelle leicht(er) vornehmen zu können (wobei es auch ohne all das geht, siehe Kanal "thenativeweb", "Softwareentwicklung ist keine Kunst" -> 70.000 Zeilen PHP-Code)
Das Problem ist, dass selbst bei sehr elementaren Fragen in der Softwareentwicklung keine Einigkeit herrscht. Das fängt bei so trivialen Dingen wie "private Variablen mit oder ohne Unterstrich?" an, und hört bei "OOD oder funktionale Programmierung?" noch lange nicht auf. Viele gute Tipps sind nach fast 50 Jahren immer noch nicht in der Praxis angekommen, und da muss man sich mittlerweile fragen, obs dafür nicht auch gute Gründe gibt.
Der neue Rucksack hat das gleiche Problem wie der alte: schön bequem mit rundum Reißverschluß, und wenn der auf geht, war's das. Ein normaler Rucksack hat nur oben den Reißverschluß. Ist für Equipment sicherlich umständlich. Aber es ist sicherer. Geht der Reißverschluß auch an den Seiten auf und bis unten, sollte mindestens noch ein Gurt (oder mehrere) vorhanden sein, damit genau das geschilderte Problem nicht auftaucht.
Habe in den letzten 10 Jahren alle heisenbugs gefunden und gefixt. Musste oft module ausknipsen oder eigene kleine testprogramme schreiben um die bugs zu isolieren. Bei verteilten Anwendungen im Prinzip gleiches Problem nur eben verteilt und dadurch suche erschwert. Ist allerdings auch typsache, viele entwickler mögen es nicht bugs zu fixen oder haben gar keine systematische Vorgehensweise und probieren einfach rum ohne nachzudenken. Und dann ist das Problem plötzlich weg und man weiß gar nicht wieso 😅
@prostmahlzeit womit programmierst du deine Testprogramme? Ganz klassisch als Shellskript oder Python? Oder nutzt du da speziellere Software bzw Bibliotheken?
Au ja, Race Conditions Nenn mich verrückt, aber ich mag solche Fehler, die sind richtig fordernd ^^ Allerdings mag ich das auch nur, wenn die Software wenigstens halbwegs vernünftig aufgebaut ist, ich also den Ablauf ohne Debugger nachvollziehen kann, ohne dabei verrückt zu werden. Zum Rucksack: Wäre nicht ein Rucksack besser geeignet, der zusätzlich zum Reißverschluss noch Schnallen hat? Beides auf einmal wird vermutlich nicht kaputt gehen.
Hey, bin komplett bei Dir, ich liebe diese Fehler auf der einen Seite auch - aber es gibt halt bestimmte, die kannst du einfach nicht nachstellen - warum auch immer. Das ist der frustrierende Part. Gruß David
Also in erster Linie habe ich Angst vor den direkten Folgen eines Softwarebugs, der kann schonmal Menschenleben kosten. Wenn der Bug dann nicht reproduzierbar wäre, käme ggf noch ein Rückruf mit enormen finanziellen Kosten dazu. Einziger Vorteil, der mich idR dann doch schlafen lässt: egal was ich mache, mein Fehler müsste in mehrern Schritten nach meiner Arbeit noch aufgedeckt werden, ich wäre damit zumindest nicht allein schuld. Ich denke das wäre dann aber für mich kein Trost, ich wüsste nicht ob ich den Job nach einem solch fatalen Fehler noch machen könnte... der Gedanke lässt mich tatsächlich manchmal schlecht schlafen.
Mal eine Frage zu dem rewriting: Haste dann die Funktionalität auch mit umgeschrieben? Das, was das Modul also machen sollte, auf eine andere Art und weise gelöst?
Hey, muss ja nicht nur an Race Conditions liegen, sind halt oft auch Einflüsse durch Umgebungen die Du so gar nicht in Maßentests umsetzen kannst. Gruß David
Ja man.... fühle ich. Positiv ist, dass ein Testcenter schon gute Arbeit leistet und Fehler findet sodass die nicht in die Öffentlichkeit kommen. Jedoch wenn in deren Ticket dann drin steht "tritt sporadisch auf" ist das eine absolute Hölle. Bei dem Versuch dies zu reproduzieren läuft es bei einem aber perfekt... Absolute Hölle... Der Ansporn ist groß es zu fixen, bevor die gleiche Meldung aus dem freien Feld kommt.
Hey, ja Testcenter sind da super, aber besonders Heisenbugs haben ja oft auch eine zeitliche Komponente - d.h. im Testcenter fallen die auch nicht unbedingt auf. Gruß David
Oha, da sagste was... Ich hab in dem Betrieb in dem ich arbeite fast jeden Tag einen Heisenbug. Das liegt meist an irgendwelchen Raceconditions. Die lassen sich nur schwer ausfindig machen wenn das System sehr verteilt oder im allgemeinen asynchron ist. Oft ist es dann so, dass der Debugger dafür sorgt, dass dieser Bug zu 100% nicht nachstellbar ist. I.d.R. gehe ich dann hin und stopfe den Code mit Logging voll und versuche das nachzuvollziehen. Meistens klappt das auch. Wenn nicht, dann schnappe ich mir mein Tablet, mach den Code auf, mach's mir gemütlich uns lese einfach nur Code ohne ihn auszuführen. Mein Hirn wird da regelmäßig viel zu warm, aber was solls. Am Ende des Tages hab ich dann meistens eine Idee woran das liegen könnte und nicht selten stimmt das dann auch. In den Fällen, in denen das dann nichts bringt, hat es mir dann geholfen anderen den Code zu erklären, wodurch ich nochmal anders darüber nachdenke und bei der Hälfte der Erklärung machts dann klick. Bisher hab ich solche Bugs eigentlich immer gefunden. Eine schöne Lösung dafür zu finden ist dann wieder ne andere Sache. Das ist meistens sogar noch schwerer als den Bug zu finden.
Statt einem Rucksack würde ich lieber eine Art Tragetasche verwenden, die nur oben auf sein kann, sodass man sie a) immer im Blick hat und sie b) nicht einfach nach unten oder zur Seite aufgehen kann. Ist auch ein ziemlicher Designfail dass die Objektive nicht durch Klettbänder o.ä. innen nochmal gesichert waren
Hey, jain . ich habe halt immer 3-4 Objektive + Body + Drohe + Fernsteuerung + Stativ dabei, deshalb fällt die Tragetasche leider aus - trotzdem danke für den Tipp :) Gruß David
Weiß nicht ob man das tatsächlich als Heisenbug bezeichnen kann, aber ich hatte mal den Fall, dass ein Dialog einfach so manchmal abgestürzt ist, manchmal aber auch nicht. Ich habe bestimmt einen halben Tag damit verbracht diesen Fehler zu suchen. Der Code war ursprünglich in COBOL geschrieben und wurde zu C++ mit einem hausintern entwickelten Transpiler umgewandelt. Problem war nur: Der Transpiler hat eine Klammer in einer komplexeren Abfrage falsch gesetzt, was mir allerdings auch erst nach mehrmaligem Vergleich vom Code mit der Grundlage und Debugging aufgefallen ist. COBOL und lokale Variablen sind ja nicht so die besten freunde und daher wurden auch in C++ globale Variablen benutzt (schlimm genug), dadurch ist der fehler immer an unterschiedlichen stellen aufgetreten oder eben manchmal auch nicht, wenn die daten vorher nochmal geupdatet wurden 😂
In unserem aktuellen Onlineshop-Projekt habe ich auch komische Bugs, die sich nicht reproduzieren oder eingrenzen lassen. Bspw. Einstellungen, die sich ändern, ohne dass jemand was in der Datenbank geändert hat. Aber glücklicherweise nicht sehr kritisch. Ich nenne es unseren lieben Poltergeist. Den lasse ich seinen Bereich, da tobt er sich aus, und lässt den Rest vom Shop in Ruhe. Mittlerweile glauben ein paar Kollegen auch dran.
Hm, wie findet man Bugs? Schonmal was von error log gehört? Klar, muss man von Anfang an in die Software implementieren, am besten mit on/off Switch oder als shadow run aber so findet man auch sporadische bugs. Einfach error log an, stresstest und auswerten. Das auswerten kann man auch mit Chat GPT machen. Error log mit entsprechender prompt parsen über REST an gpt4o und Auswertung abarbeiten.
Bugs findet man nicht, man vermeidet sie. Selbstverständlich werden trotzdem Bugs auftreten. Da man aber unnötige Features nicht implementiert, fallen schon diese Bugs weg. Automatische Tests müssen auch eine Selbstverständlichkeit sein. Sie sind nicht verhandelbar. Eine andere Compileroption verlangt einen Testlauf.
Hey, ich bin mir nicht sicher, ob Du den Posts ironisch meinst, meine Message nicht verstanden hast oder ich gerade einfach nur auf dem Schlauch stehe :D Gruß David
@@DavidTielke Eine Küche putzt man nicht, man hält sie sauber. Von Zeit zu Zeit wird man die Küche trotzdem putzen müssen. Vor Heisenbugs ist man nie gefeit, aber ist es wirklich ein Heisenbug, oder hat man sich nur ein paar "unnötige" Tests erspart?
Warum denn Angst als Begriff? Ich würde es als Respekt, gepaart mit Erfahrung bezeichnen. Und bei den Objektiven kann ich den Selbstfrust gut nachvollziehen. Da wirkte aber relativ früh beim Rucksack das Thema Redundanz mit - ich bin da sehr aus dem Klettersport noch geprägt. Neben dem Reißverschluss sichern eben noch Fixierungen, die über die Fächer gehen, die darin befindlichen Objektive und Kameras.
Das hatte ich schon sehr oft. Das Zeitverhalten ist einfach ein kleines bisschen anders. Und manchmal ist die Test-Hardware vom Systemtest ein wenig anders im Verhalten, als die Hardware beim Kunden. Ich bin im Embedded-Bereich unterwegs und da kann es schon passieren, dass irgendwo ein Elektronikteil abgekündigt wird und ein paar Monate später plötzlich Bugs bei den Kunden auftauchen.
@@o21211671 Es ist nicht nur Timing. Ein wesentlicher Aspekt ist, dass damals der saubere Umgang mit Speicher (Use after free), und Bereichsgrenzen Disziplin erfordert hatte und es wenig Hilfsmittel gab. In Debug Builds können Speicherbereiche anders aufgebaut sein und damit wird das Fehlerverhalten bei solchen Themen anders.
Ein Reißverschluss ist kein sicheres Verschlusssystem, genauso wird es auch bei deiner Software gewesen sein. Bei einer Software gibt es auch Designmuster, Verfahren und Algorithmen, die Fehleranfällig sind.
@@silentwater79weil js für sehr kleine Aufgaben praktisch ist (gibt natürlich auch dafür besseres) und viele machen dann halt den Fehler ja für große Projekte zu verwenden
Och JavaScript ist eigentlich ganz in Ordnung, solange man keine 10 Millionen Codezeilen damit schreiben will. Deshalb mag ich Blazor, ich nutze JavaScript nur noch für einfache Interaktionen innerhalb meiner Komponente, dafür ist es super geeignet. Viel schlimmer finde ich dagegen CSS, mit JavaScript kann ich venigstens ungefähr nachvollziehen, was passiert, bei CSS bleibt häufig nur noch raten.
Man kann solche Bugs aber oftmals auch dergestalt lösen, indem man ihn jemand Anderen erzählt. Das kann auch mal - die hoffentlich geduldige Oma - sein. Ich habe oftmals schon Knoten solcher Art lösen, indem man noch einmal *umfassender* über das Thema nachdenkt! Und das tut man implizit, wenn man darüber redet. Mir fiel dann manchmal schon während des Erzählens auf, wo das Problem liegt… Probiert es doch einfach mal aus! 🙄
Das neu schreiben von Modulen ist aus meiner Sicht keine Lösung für "Heisenbugs" denn die Gefahr ist sehr groß NEUE und noch unbekannte "Heisenbugs" zu bekommen. Besser ist aus meiner Sicht, sich immer wieder klar zu machen das Software keiner "Hogwardsmagie" folgt sondern immer deterministisch arbeitet.
Mit den gleichen "Eingaben" wird die Software immer das gleiche Ergebnis liefern - die Herausforderung ist hierbei heraus zu finden woher die (fehlerhaften) "Eingaben" kommen und warum und um dann den Fehler zu korrigieren oder "Fehlertolerant" darauf zu reagieren.
TLDL; 6 Minuten Einleitung, danach Heisenbug. Was ich interessant finde, die Person, die nicht für komplette Unit-Test Abdeckung ist, hat Angst vor Bugs. Ich habe fast 100% Testabdeckung in Projekten und keine Angst vor Bugs oder Changes. Ja macht alles langsam, funktioniert aber. Und Windows Software ist leider für Produktivanwendungen ungeeignet. Es sei denn, man möchte mit Bugs leben. 😂
Ich arbeite in der industriellen Bildverarbeitung mit Maschinen auf der ganzen Welt verteilt. Wir hatten einmal einen Bug in unterschiedlichen Werken zu unterschiedlichen Tageszeiten und sehr sporadisch. Am Ende konnten wir herausfinden, dass das nur in Werken mit Oberlichtern auftritt und die Sonne zu bestimmten Tageszeiten voll auf die Aufnahmefläche scheint. 2 Jahre und sehr sehr viel Dokumentation, Kommunikation mit den Kunden sowie Wochen an Arbeitszeit hat es gedauert, bis wir bei den Aufbauten einen Sichtschutz als Bugfix implementiert hatten.
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
Bei meinem aktuellen Arbeitgeber müssen wir auf jahrealter SW herum doktorn. Wenn man ein "neuschreiben" auch nur erwähnt, bekommt man Diskussionen an den Hals. Es ist so ermüdend, ständig gegen so ein Chaos anzukämpfen. Es gibt keine Requirements, keine Architektur, kein Testumfeld und und und. Alle coden einfach auf diesem alten Klotz herum und müssen sich dann auch noch anhören, dass man nicht performant ist 😒
Fühl ich so und es frustriert einen einfach nur noch.
@@TC103RoadGlide leider in viele Unternehmen der Fall....das is auch ein typisches Problem von Managern und den Entwicklern..Interessenkonflikt
Kündigen und weitergehen. Du musst doch nicht deine Lebenszeit (und deinen eigenen Fortschritt) mit Dingen verschwenden, die dich frustrieren.
Entweder der bisherige AG findet Leute, die richtig Lust auf Altsysteme haben (die gibt es!) oder er wird umdenken müssen.
Ein "neuschreiben" löst meist die Probleme nicht, da ähnliche Probleme wieder eingefügt werden, imho müssen neue Features / Featureänderungen an das bisherige System über Schnittstellen angekoppelt werden. Das bisherige System wird damit nach und nach obsolet und kann organisch ausgephast werden.
Glaub mir, wenn das Ding neu geschrieben wird, werden 80% der Fehler wieder gemacht, da wegen Zeitdruck ein Großteil des alten scheiß Codes kopiert wird. Been there many times.
Wenn man überhaupt versteht, was der Code macht bzw. machen soll. Wir haben einen Stack aus einem wohlbekanntem asiatischen Land, in dem void-void-Funktionen beliebig globale Variablen ändern. Versteht kein Mensch und keiner traut sich, den Moloch auch nur ansatzweise zu refactors. So schafft man Kundenbindung 😮
Zum Rucksack: es reicht völlig, wenn einmal ein einziger Zahn des Reißverschlusses beim Schließen nicht da landet, wo er hinsoll. Dann braucht es kaum Kraft, dass sich der Reißverschluss von dort aus in beide Richtungen öffnet.
Wenn der beim nächsten Mal wieder richtig sitzt, dann hält der Reißverschluss so, wie gewohnt.
Hey,
ja sowas war auch meine Vermutung - aber wie schon gesagt, das Risiko war mir einfach zu groß - der jetzige Rucksack hat nochmal eine Schnalle um das Fach zusätzlich zu sichern.
Gruß David
@@DavidTielke hätte ich bei so teuren Sachen auch gemacht. Man weiß nie, wann das wieder passiert.
Analog zur Physik (dort geht es um Bewegungsvorgänge und die sie beeinflussenden Kräfte) gilt es in der SW-Entwicklung die Einflüsse im Lauf der Zeit einzukalkulieren. Irgendwann kommt aber auch bei einem hoch spezialisierten Team der kritische Punkt, ab dem es zuviele Einflüsse werden und man nur noch raten kann, was das SW-Produkt (nicht) tut.
Hey,
manchmal habe ich das Gefühl, in der Physik gibt es weniger ungelöste Rätsel als in der Entwicklung :D
Gruß David
@@DavidTielkeun der Physik ist das Gegenteil der Fall und führt zu Komplexitätsvermehrung. Cynefin ist ein hervorragendes Tool, wie dem zu begegnen sei.
Hey Herr Thielke, macen Sie doch mal ein Video darüber, warum Feature-Creep ein echtes Problem ist und warum ein ordentliches logging ein wichtiger Punkt ist, den man nicht vernachlässigen sollte.
Moin,
bitte nicht Sie'zen ;) Super Idee, genau das Video kommt sogar als nächstes oder übernächstes, habe ich schon länger in der Planung.
Gruß David
Hab das in einer Siemens Steuerung. Ich schieb es immer einfach auf Siemens. Ab und zu wird einfach mal ein Wert zwischen PLC unf HMI nicht synchronisiert. Funktioniert 1000 mal und beim 1001 mal ist der Wert nicht da -.-
Und das mit den Objektiven hatte ich leider auch schon. Ruhe in Frieden mein 70-300mm.
Hey,
mein Beileid - ich hoffe es war ein Tamron :D
Gruß David
Immutably, Unit Tests verringert diese nach meiner Erfahrung stark
Kann ich nur unterschreiben. Seit ich (exzessiv) Tests schreibe, schlafe ich viel besser und die Gefahr der Verschlimbesserung ist auch stark gesunken
Hey,
das Problem dabei ist, dass man mit Unit Tests isolierte Einheiten testet und gerade Heisenbugs oftmals erst bei der Integration (vor allem der asynchronen) von solchen Einheiten auftritt, daher helfen Unit Tests da zwar in manchen Fällen, aber oftmals nicht in allen - besonders bei Race Conditions.
Gruß David
Meine Unittest sind sehr strikt (was die Kommunikation mit Dependecies betrifft). So dass auch ein Teil dieser möglichen Probleme auffallen. Aber am Ende hast du recht, dass es keine 100% gibt.
Immutability ist ein drastisch unterbewertetes Konzept. Dass sowas wie F# nicht schon mehr verfangen hat, ist schade.
Kannst du nicht vielleicht mal ein komplett Tutorial machen und eine Software und das komplette entwickeln dieser dabei erläutern, was warum und wieso? Soetwas vermisse ich noch irgendwie. Jch programmiere jetzt schon ein gut 2 Jahre, wann immer ich Zeit habe (als Privatperson - also nicht professionell). Ihre Videos schaue ich auch seit einigen Wochen, finde diese sehr gut. Mir fehlt aber bei allen Kursen/Büchern etc immer so goldene leitende Faden, der wirklich im Sinne von "Best Practice" seinen Code nun aufbaut und wann man was und warum so macht. Man erfährt immer wieder einzelne Inhalte, die man aber früher oder später wieder vergisst, weil man den Sinn dahinter und das Wann (besser zu) verwenden ist nicht erfährt.
Hey,
danke für den Vorschlag, leider ist das nicht so einfach umzusetzen. Also einfach wäre es schon, aber meine Plattform wäre halt .NET/C#/NDEPEND/Azure DevOps und damit hole ich halt nur einen kleinen Bruchteil der Zuschauer ab, weil hier Leute zuschauen die mit Python, Java, Cobol, C++ etc. entwickeln. Ich verstehe deinen WUnsch total, sowas hätte ich früher auch gerne gehabt - aber da es viel Arbeit für zu wenige für Euch wäre, konzentriere ich mich lieber auf die Themen die alle weiterbringen. Es gibt aber genug sehr gute Kanäle hier die das für verschiedenen Plattformen zeigen.
Gruß David
Wie die beste Praxis aussieht, kommt darauf an, was damit erreicht werden soll.
Außerdem macht es einen großen Unterschied, ob du etwas ganz alleine entwickelst und keine Stakeholder außer dich selbst hast, oder ob du in einem Team ein Produkt für einen Kunden entwickelst.
Im Endeffekt ist Programmierung die Frage, wie sich der Compiler / Interpreter / Transpiler ... verhält, wenn er auf ein Schlüsselwort trifft (oder dieses i.V. mit anderen Schlüsselwörtern (nicht) tut ). Und auch bei anderen Plattformen gibt es (andere) Änderungsraten um von der Idee zum SW-Produkt zu kommen. Begriffe wie Architektur, SOLID, Clean Code, SW-Tests,... sind Empfehlungen für den Menschen um (häufige(re)) Änderungen oder Erweiterungen an einer (zentralen) Stelle leicht(er) vornehmen zu können (wobei es auch ohne all das geht, siehe Kanal "thenativeweb", "Softwareentwicklung ist keine Kunst" -> 70.000 Zeilen PHP-Code)
Das Problem ist, dass selbst bei sehr elementaren Fragen in der Softwareentwicklung keine Einigkeit herrscht. Das fängt bei so trivialen Dingen wie "private Variablen mit oder ohne Unterstrich?" an, und hört bei "OOD oder funktionale Programmierung?" noch lange nicht auf. Viele gute Tipps sind nach fast 50 Jahren immer noch nicht in der Praxis angekommen, und da muss man sich mittlerweile fragen, obs dafür nicht auch gute Gründe gibt.
Sehr schöne Analogie zum Real-Life. Gerne Themen mehr so erklären :) wird viel anschaulicher mMn.
Hey,
danke für das Feedback - ich werde es versuchen!
Gruß David
Der neue Rucksack hat das gleiche Problem wie der alte: schön bequem mit rundum Reißverschluß, und wenn der auf geht, war's das.
Ein normaler Rucksack hat nur oben den Reißverschluß. Ist für Equipment sicherlich umständlich. Aber es ist sicherer.
Geht der Reißverschluß auch an den Seiten auf und bis unten, sollte mindestens noch ein Gurt (oder mehrere) vorhanden sein,
damit genau das geschilderte Problem nicht auftaucht.
Habe in den letzten 10 Jahren alle heisenbugs gefunden und gefixt. Musste oft module ausknipsen oder eigene kleine testprogramme schreiben um die bugs zu isolieren. Bei verteilten Anwendungen im Prinzip gleiches Problem nur eben verteilt und dadurch suche erschwert. Ist allerdings auch typsache, viele entwickler mögen es nicht bugs zu fixen oder haben gar keine systematische Vorgehensweise und probieren einfach rum ohne nachzudenken. Und dann ist das Problem plötzlich weg und man weiß gar nicht wieso 😅
Hey,
ja die Fähigkeit Bugs zu finden muss man natürlich haben - keine Frage und da gehört auch eine Menge Erfahrung zu.
Gruß David
@prostmahlzeit womit programmierst du deine Testprogramme? Ganz klassisch als Shellskript oder Python? Oder nutzt du da speziellere Software bzw Bibliotheken?
Au ja, Race Conditions
Nenn mich verrückt, aber ich mag solche Fehler, die sind richtig fordernd ^^ Allerdings mag ich das auch nur, wenn die Software wenigstens halbwegs vernünftig aufgebaut ist, ich also den Ablauf ohne Debugger nachvollziehen kann, ohne dabei verrückt zu werden.
Zum Rucksack:
Wäre nicht ein Rucksack besser geeignet, der zusätzlich zum Reißverschluss noch Schnallen hat? Beides auf einmal wird vermutlich nicht kaputt gehen.
Hey,
bin komplett bei Dir, ich liebe diese Fehler auf der einen Seite auch - aber es gibt halt bestimmte, die kannst du einfach nicht nachstellen - warum auch immer. Das ist der frustrierende Part.
Gruß David
Also in erster Linie habe ich Angst vor den direkten Folgen eines Softwarebugs, der kann schonmal Menschenleben kosten. Wenn der Bug dann nicht reproduzierbar wäre, käme ggf noch ein Rückruf mit enormen finanziellen Kosten dazu. Einziger Vorteil, der mich idR dann doch schlafen lässt: egal was ich mache, mein Fehler müsste in mehrern Schritten nach meiner Arbeit noch aufgedeckt werden, ich wäre damit zumindest nicht allein schuld. Ich denke das wäre dann aber für mich kein Trost, ich wüsste nicht ob ich den Job nach einem solch fatalen Fehler noch machen könnte... der Gedanke lässt mich tatsächlich manchmal schlecht schlafen.
Mal eine Frage zu dem rewriting: Haste dann die Funktionalität auch mit umgeschrieben? Das, was das Modul also machen sollte, auf eine andere Art und weise gelöst?
Woran liegen solche Bugs den oft? Race conditions? Ich hab neulich mit einem Stresstest mit 300 000 Anfragen gefunden und dann auch gefixt
Hey,
muss ja nicht nur an Race Conditions liegen, sind halt oft auch Einflüsse durch Umgebungen die Du so gar nicht in Maßentests umsetzen kannst.
Gruß David
@@DavidTielke externe Umgebungen sollten so weit wie möglich weg gemockt werden. Aber ja du hast recht. In der Realen Welt sind das nicht immer 100%
Ja man.... fühle ich. Positiv ist, dass ein Testcenter schon gute Arbeit leistet und Fehler findet sodass die nicht in die Öffentlichkeit kommen. Jedoch wenn in deren Ticket dann drin steht "tritt sporadisch auf" ist das eine absolute Hölle. Bei dem Versuch dies zu reproduzieren läuft es bei einem aber perfekt... Absolute Hölle... Der Ansporn ist groß es zu fixen, bevor die gleiche Meldung aus dem freien Feld kommt.
Hey,
ja Testcenter sind da super, aber besonders Heisenbugs haben ja oft auch eine zeitliche Komponente - d.h. im Testcenter fallen die auch nicht unbedingt auf.
Gruß David
Was mache ich denn jetzt mit meinem Rucksack? Prophylaktisch auch austauschen? 🤔
JA!!!! :D
durch Tragetasche ersetzen die nur oben aufgeht so dass bei normalem Tragen nichts rausfallen kann
Oha, da sagste was... Ich hab in dem Betrieb in dem ich arbeite fast jeden Tag einen Heisenbug. Das liegt meist an irgendwelchen Raceconditions. Die lassen sich nur schwer ausfindig machen wenn das System sehr verteilt oder im allgemeinen asynchron ist. Oft ist es dann so, dass der Debugger dafür sorgt, dass dieser Bug zu 100% nicht nachstellbar ist. I.d.R. gehe ich dann hin und stopfe den Code mit Logging voll und versuche das nachzuvollziehen. Meistens klappt das auch. Wenn nicht, dann schnappe ich mir mein Tablet, mach den Code auf, mach's mir gemütlich uns lese einfach nur Code ohne ihn auszuführen. Mein Hirn wird da regelmäßig viel zu warm, aber was solls. Am Ende des Tages hab ich dann meistens eine Idee woran das liegen könnte und nicht selten stimmt das dann auch. In den Fällen, in denen das dann nichts bringt, hat es mir dann geholfen anderen den Code zu erklären, wodurch ich nochmal anders darüber nachdenke und bei der Hälfte der Erklärung machts dann klick. Bisher hab ich solche Bugs eigentlich immer gefunden. Eine schöne Lösung dafür zu finden ist dann wieder ne andere Sache. Das ist meistens sogar noch schwerer als den Bug zu finden.
Statt einem Rucksack würde ich lieber eine Art Tragetasche verwenden, die nur oben auf sein kann, sodass man sie a) immer im Blick hat und sie b) nicht einfach nach unten oder zur Seite aufgehen kann. Ist auch ein ziemlicher Designfail dass die Objektive nicht durch Klettbänder o.ä. innen nochmal gesichert waren
Hey,
jain . ich habe halt immer 3-4 Objektive + Body + Drohe + Fernsteuerung + Stativ dabei, deshalb fällt die Tragetasche leider aus - trotzdem danke für den Tipp :)
Gruß David
Weiß nicht ob man das tatsächlich als Heisenbug bezeichnen kann, aber ich hatte mal den Fall, dass ein Dialog einfach so manchmal abgestürzt ist, manchmal aber auch nicht. Ich habe bestimmt einen halben Tag damit verbracht diesen Fehler zu suchen. Der Code war ursprünglich in COBOL geschrieben und wurde zu C++ mit einem hausintern entwickelten Transpiler umgewandelt. Problem war nur: Der Transpiler hat eine Klammer in einer komplexeren Abfrage falsch gesetzt, was mir allerdings auch erst nach mehrmaligem Vergleich vom Code mit der Grundlage und Debugging aufgefallen ist. COBOL und lokale Variablen sind ja nicht so die besten freunde und daher wurden auch in C++ globale Variablen benutzt (schlimm genug), dadurch ist der fehler immer an unterschiedlichen stellen aufgetreten oder eben manchmal auch nicht, wenn die daten vorher nochmal geupdatet wurden 😂
In unserem aktuellen Onlineshop-Projekt habe ich auch komische Bugs, die sich nicht reproduzieren oder eingrenzen lassen. Bspw. Einstellungen, die sich ändern, ohne dass jemand was in der Datenbank geändert hat.
Aber glücklicherweise nicht sehr kritisch. Ich nenne es unseren lieben Poltergeist. Den lasse ich seinen Bereich, da tobt er sich aus, und lässt den Rest vom Shop in Ruhe. Mittlerweile glauben ein paar Kollegen auch dran.
Hm, wie findet man Bugs? Schonmal was von error log gehört? Klar, muss man von Anfang an in die Software implementieren, am besten mit on/off Switch oder als shadow run aber so findet man auch sporadische bugs. Einfach error log an, stresstest und auswerten. Das auswerten kann man auch mit Chat GPT machen. Error log mit entsprechender prompt parsen über REST an gpt4o und Auswertung abarbeiten.
Bugs findet man nicht, man vermeidet sie. Selbstverständlich werden trotzdem Bugs auftreten. Da man aber unnötige Features nicht implementiert, fallen schon diese Bugs weg. Automatische Tests müssen auch eine Selbstverständlichkeit sein. Sie sind nicht verhandelbar. Eine andere Compileroption verlangt einen Testlauf.
Hey,
ich bin mir nicht sicher, ob Du den Posts ironisch meinst, meine Message nicht verstanden hast oder ich gerade einfach nur auf dem Schlauch stehe :D
Gruß David
@@DavidTielke Eine Küche putzt man nicht, man hält sie sauber. Von Zeit zu Zeit wird man die Küche trotzdem putzen müssen. Vor Heisenbugs ist man nie gefeit, aber ist es wirklich ein Heisenbug, oder hat man sich nur ein paar "unnötige" Tests erspart?
Warum denn Angst als Begriff? Ich würde es als Respekt, gepaart mit Erfahrung bezeichnen. Und bei den Objektiven kann ich den Selbstfrust gut nachvollziehen. Da wirkte aber relativ früh beim Rucksack das Thema Redundanz mit - ich bin da sehr aus dem Klettersport noch geprägt. Neben dem Reißverschluss sichern eben noch Fixierungen, die über die Fächer gehen, die darin befindlichen Objektive und Kameras.
Solche Fehler tauchen oft kurz nach einem Rollout auf und alle schieben es dann auf die neue Version 😂
Hey,
das stimmt... :D
Gruß David
Vor vielen Jahren im C Code einen Fehler gesucht, der im Debug Build nicht aufgetaucht ist. :)
Das hatte ich schon sehr oft.
Das Zeitverhalten ist einfach ein kleines bisschen anders. Und manchmal ist die Test-Hardware vom Systemtest ein wenig anders im Verhalten, als die Hardware beim Kunden.
Ich bin im Embedded-Bereich unterwegs und da kann es schon passieren, dass irgendwo ein Elektronikteil abgekündigt wird und ein paar Monate später plötzlich Bugs bei den Kunden auftauchen.
Hey,
oh ja, ich leide mir dir :D
Gruß David
@@o21211671 Es ist nicht nur Timing. Ein wesentlicher Aspekt ist, dass damals der saubere Umgang mit Speicher (Use after free), und Bereichsgrenzen Disziplin erfordert hatte und es wenig Hilfsmittel gab. In Debug Builds können Speicherbereiche anders aufgebaut sein und damit wird das Fehlerverhalten bei solchen Themen anders.
Ein Reißverschluss ist kein sicheres Verschlusssystem, genauso wird es auch bei deiner Software gewesen sein. Bei einer Software gibt es auch Designmuster, Verfahren und Algorithmen, die Fehleranfällig sind.
Leider hast Du recht :)
Gruß David
Eine wunderschöne Metapher. Was war zuerst da? Die Video-Idee oder der Heisenbug des Rucksacks? 😁
Meine Angst heißt JavaScript 😨😰
Kann ich nachvollziehen. Warum man diese Rotz Sprache verwendet hat sich mir immer entzogen.
@@silentwater79weil js für sehr kleine Aufgaben praktisch ist (gibt natürlich auch dafür besseres) und viele machen dann halt den Fehler ja für große Projekte zu verwenden
Och JavaScript ist eigentlich ganz in Ordnung, solange man keine 10 Millionen Codezeilen damit schreiben will.
Deshalb mag ich Blazor, ich nutze JavaScript nur noch für einfache Interaktionen innerhalb meiner Komponente, dafür ist es super geeignet.
Viel schlimmer finde ich dagegen CSS, mit JavaScript kann ich venigstens ungefähr nachvollziehen, was passiert, bei CSS bleibt häufig nur noch raten.
@@Palladin007 vor allem: wer soll sich all die CSS-Features merken?
Hey,
ich fürchte mich mit Dir :D
Gruß David
Man kann solche Bugs aber oftmals auch dergestalt lösen, indem man ihn jemand Anderen erzählt. Das kann auch mal - die hoffentlich geduldige Oma - sein. Ich habe oftmals schon Knoten solcher Art lösen, indem man noch einmal *umfassender* über das Thema nachdenkt! Und das tut man implizit, wenn man darüber redet. Mir fiel dann manchmal schon während des Erzählens auf, wo das Problem liegt… Probiert es doch einfach mal aus! 🙄
Hey,
ja, super Tipp - bin absolut bei dir :D
Gruß David
Nach dem Video zum Green-Coding kommt sicherlich noch eins zum Wet-Coding. Den Trailer gab's hier ja schon 😜
Das neu schreiben von Modulen ist aus meiner Sicht keine Lösung für "Heisenbugs" denn die Gefahr ist sehr groß NEUE und noch unbekannte "Heisenbugs" zu bekommen.
Besser ist aus meiner Sicht, sich immer wieder klar zu machen das Software keiner "Hogwardsmagie" folgt sondern immer deterministisch arbeitet.
Mit den gleichen "Eingaben" wird die Software immer das gleiche Ergebnis liefern - die Herausforderung ist hierbei heraus zu finden woher die (fehlerhaften) "Eingaben" kommen und warum und um dann den Fehler zu korrigieren oder "Fehlertolerant" darauf zu reagieren.
TLDL; 6 Minuten Einleitung, danach Heisenbug.
Was ich interessant finde, die Person, die nicht für komplette Unit-Test Abdeckung ist, hat Angst vor Bugs. Ich habe fast 100% Testabdeckung in Projekten und keine Angst vor Bugs oder Changes. Ja macht alles langsam, funktioniert aber.
Und Windows Software ist leider für Produktivanwendungen ungeeignet. Es sei denn, man möchte mit Bugs leben. 😂
"I am the one who bugs!"
Mein Beileid um die Objektive. Kann ich durchaus Nachvollziehen das dich das Ärgert.
Danke :)
6min Intro... wenn deine sonstigen Videos nicht so lehrreich wären hätte ich dieses hier geskipped.
Wenn du dir die Zeit dafür nicht nehmen kannst, empfehle ich dir dringend die Videos nicht mehr zu schauen und nach Alternativen zu suchen!
@@DavidTielke Ok, ciao. ;D
Das beste sind Heisen-Hydrabugs. Du versuchst den Heisenbug zu reproduzieren und dann entdeckst du weitere Heisenbugs.
Ich arbeite in der industriellen Bildverarbeitung mit Maschinen auf der ganzen Welt verteilt.
Wir hatten einmal einen Bug in unterschiedlichen Werken zu unterschiedlichen Tageszeiten und sehr sporadisch.
Am Ende konnten wir herausfinden, dass das nur in Werken mit Oberlichtern auftritt und die Sonne zu bestimmten Tageszeiten voll auf die Aufnahmefläche scheint.
2 Jahre und sehr sehr viel Dokumentation, Kommunikation mit den Kunden sowie Wochen an Arbeitszeit hat es gedauert, bis wir bei den Aufbauten einen Sichtschutz als Bugfix implementiert hatten.