Meine ständige ANGST in der Softwareentwicklung

Подписаться 17 тыс.

Просмотров 6 тыс.

50% 1

In diesem Video spreche ich über ein oft unterschätztes, aber extrem frustrierendes Problem in der Softwareentwicklung: Heisenbugs. Diese schwer fassbaren Fehler scheinen immer dann zu verschwinden, wenn man versucht, sie zu diagnostizieren. Sie lassen mich nicht los und verfolgen mich sogar bis in meine Träume. Während ich keine definitive Lösung für dieses Problem anbieten kann, möchte ich eine interessante Geschichte darüber teilen, wie Heisenbugs meine Arbeit und mein Leben beeinflussen. Taucht ein in die Welt der mysteriösen Softwarefehler und teilt eure eigenen Erfahrungen in den Kommentaren. Vielleicht finden wir gemeinsam einen Weg, diese Geister zu bannen!
Heisenbugs
[00:00] Das Leben als Softwareentwickler
[01:00] Mein nicht gefundener Bug im wahren Leben
[06:29] Heisenbugs in der Softwareentwicklung
[09:07] Mein Ansatz bei Heisenbugs
▬ Über diesen Kanal ▬▬▬▬▬▬▬▬▬▬▬▬
Seit vielen Jahren arbeite ich als Consultant, Coach und Trainer für professionelle Softwareentwicklung mit den Schwerpunkten Softwarequalität, Softwarearchitektur sowie Prozessmanagement. Auf meinem Kanal möchte ich Euch mein Wissen und meine langjährige Erfahrung in diesen Bereichen vermitteln - natürlich kostenlos. Dabei versuche ich stets Euch das Wissen so zu vermitteln, dass Ihr damit direkt in der Praxis loslegen könnt und das ganze immer mit guten Portion Humor. Lernen soll ja schließlich Spaß machen :)
▬ Empfohlene Videos ▬▬▬▬▬▬▬▬▬▬▬▬
Wie viel Softwarequalität Ihr braucht - • Architekturen - Von Mo...
Warum Software unwartbar wird - • Warum Software unwartb...
Architektur - Modularisierung - • Architektur - Modulari...
Was ist Architektur - • Was ist Architektur?
Warum Architektur - • Warum Architektur für ...
▬ Wichtige Links ▬▬▬▬▬▬▬▬▬▬▬▬
Abonniere meinen Kanal: / @davidtielke
Alle Videos: / @davidtielke
▬ Social Media ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
► Twitter: / davidtielke
► Xing: www.xing.com/profile/David_Ti...
► LinkedIn: / david-tielke-06140912b
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

Наука

Опубликовано:

28 июн 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 93

@steitview 13 дней назад

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 😒

@TC103RoadGlide 13 дней назад

Fühl ich so und es frustriert einen einfach nur noch.

@mxz2024 13 дней назад

@@TC103RoadGlide leider in viele Unternehmen der Fall....das is auch ein typisches Problem von Managern und den Entwicklern..Interessenkonflikt

@chriss5749 13 дней назад

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.

@silentwater79 13 дней назад

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.

@OliverWieland-wk4fk 12 дней назад

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 😮

@ThomasVWorm 13 дней назад

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.

@DavidTielke 11 дней назад

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

@ThomasVWorm 11 дней назад

@@DavidTielke hätte ich bei so teuren Sachen auch gemacht. Man weiß nie, wann das wieder passiert.

@pauldennisbondy4885 13 дней назад

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.

@DavidTielke 11 дней назад

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

@Palladin007 13 дней назад

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.

@DavidTielke 11 дней назад

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

@rebarius 13 дней назад

Sehr schöne Analogie zum Real-Life. Gerne Themen mehr so erklären :) wird viel anschaulicher mMn.

@DavidTielke 11 дней назад

Hey, danke für das Feedback - ich werde es versuchen! Gruß David

@MrML78 12 дней назад

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.

@DavidTielke 11 дней назад

Hey, manchmal habe ich das Gefühl, in der Physik gibt es weniger ungelöste Rätsel als in der Entwicklung :D Gruß David

@c4itd 2 дня назад

@@DavidTielkeun der Physik ist das Gegenteil der Fall und führt zu Komplexitätsvermehrung. Cynefin ist ein hervorragendes Tool, wie dem zu begegnen sei.

@smallsnippets 10 дней назад

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.

@HellGhostEvocator 13 дней назад

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.

@DavidTielke 11 дней назад

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

@mepipe7705 11 дней назад

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.

@MrML78 11 дней назад

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)

@mariusg8824 10 дней назад

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.

@DominikZogg 12 дней назад

Immutably, Unit Tests verringert diese nach meiner Erfahrung stark

@OliverWieland-wk4fk 12 дней назад

Kann ich nur unterschreiben. Seit ich (exzessiv) Tests schreibe, schlafe ich viel besser und die Gefahr der Verschlimbesserung ist auch stark gesunken

@DavidTielke 11 дней назад

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

@DominikZogg 11 дней назад

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.

@mariusg8824 10 дней назад

Immutability ist ein drastisch unterbewertetes Konzept. Dass sowas wie F# nicht schon mehr verfangen hat, ist schade.

@beatbaer2 13 дней назад

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.

@DavidTielke 11 дней назад

Hey, mein Beileid - ich hoffe es war ein Tamron :D Gruß David

@MaxBenn 12 дней назад

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.

@DavidTielke 11 дней назад

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

@prostmahlzeit 12 дней назад

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 😅

@DavidTielke 11 дней назад

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

@superkaefer 10 дней назад

@prostmahlzeit womit programmierst du deine Testprogramme? Ganz klassisch als Shellskript oder Python? Oder nutzt du da speziellere Software bzw Bibliotheken?

@bjorn6726 12 дней назад

Solche Fehler tauchen oft kurz nach einem Rollout auf und alle schieben es dann auf die neue Version 😂

@DavidTielke 11 дней назад

Hey, das stimmt... :D Gruß David

@michaegi4717 10 дней назад

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.

@fairphoneuser9009 11 дней назад

Eine wunderschöne Metapher. Was war zuerst da? Die Video-Idee oder der Heisenbug des Rucksacks? 😁

@christianh.5908 12 дней назад

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

@DavidTielke 11 дней назад

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

@heinrichschiller4673 13 дней назад

Meine Angst heißt JavaScript 😨😰

@silentwater79 13 дней назад

Kann ich nachvollziehen. Warum man diese Rotz Sprache verwendet hat sich mir immer entzogen.

@programmieren3197 13 дней назад

@@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

@Palladin007 13 дней назад

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.

@christianh.5908 12 дней назад

@@Palladin007 vor allem: wer soll sich all die CSS-Features merken?

@DavidTielke 11 дней назад

Hey, ich fürchte mich mit Dir :D Gruß David

@programmieren3197 13 дней назад

Woran liegen solche Bugs den oft? Race conditions? Ich hab neulich mit einem Stresstest mit 300 000 Anfragen gefunden und dann auch gefixt

@DavidTielke 11 дней назад

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

@programmieren3197 11 дней назад

@@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%

@richardneumann3335 9 дней назад

UB durch fehlerhafte Speichermanipulation oder Race Conditions führt mEn oft zu Heisenbugs. Moderne Programmiersprachen, welche Speichersicherheit und Fearless Concurrency bieten können bei korrekter Verwendung das Risiko hierfür minimieren. Grüße von der RESF ;-)

@justusm1442 10 дней назад

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 😂

@m.b.9061 12 дней назад

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.

@Hofer2304 12 дней назад

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.

@DavidTielke 11 дней назад

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

@Hofer2304 11 дней назад

@@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?

@smallsnippets 10 дней назад

Nach dem Video zum Green-Coding kommt sicherlich noch eins zum Wet-Coding. Den Trailer gab's hier ja schon 😜

@m.k.3370 5 дней назад

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.

@amiganer681130 11 дней назад

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?

@DJTechnostyler 11 дней назад

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.

@mepipe7705 11 дней назад

"I am the one who bugs!"

@hanspeterbestandig2054 12 дней назад

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! 🙄

@DavidTielke 11 дней назад

Hey, ja, super Tipp - bin absolut bei dir :D Gruß David

@TillGroos 12 дней назад

Was mache ich denn jetzt mit meinem Rucksack? Prophylaktisch auch austauschen? 🤔

@DavidTielke 12 дней назад

JA!!!! :D

@christianh.5908 12 дней назад

durch Tragetasche ersetzen die nur oben aufgeht so dass bei normalem Tragen nichts rausfallen kann

@kingigzorn7680 11 дней назад

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. 😂

@matthias3512 7 дней назад

Vermutlich ein Glitch in der Matrix

@user-ti8yb8hs3v 13 дней назад

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.

@DavidTielke 11 дней назад

Leider hast Du recht :) Gruß David

@mishka0 13 дней назад

Vor vielen Jahren im C Code einen Fehler gesucht, der im Debug Build nicht aufgetaucht ist. :)

@o21211671 11 дней назад

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.

@DavidTielke 11 дней назад

Hey, oh ja, ich leide mir dir :D Gruß David

@mishka0 11 дней назад

@@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.

@IT-Entrepreneur 13 дней назад

Mein Beileid um die Objektive. Kann ich durchaus Nachvollziehen das dich das Ärgert.

@DavidTielke 11 дней назад

Danke :)

@t.c.7823 8 дней назад

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.

@matthias3512 7 дней назад

Weit gefehlt! Durch defekte Hardware kann auch die Software nicht deterministisch arbeiten

@t.c.7823 7 дней назад

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.