Kann man absichtlich einen Fehler machen?

Wir Entwickler stoßen regelmäßig auf Fehler , das gehört einfach zu unserem Job. Daher stellt sich auf den ersten Blick die Frage „Kann man absichtlich einen Bug machen?“ mag banal erscheinen – „Ja, natürlich kann ich einen Fehler schreiben.“ Wenn man jedoch darüber nachdenkt, scheint nicht mehr alles so offensichtlich zu sein.

Tatsache ist, dass der Fehler nicht dasselbe ist wie defekter Code . Ein Bug ist ein Fehler, ein Fehler im Allgemeinen

Arbeitsprogramm.

Was ist das Problem?

Die Welt lässt sich bekanntlich gut durch mathematische Formeln beschreiben. Und die Formeln sind eigentlich die Algorithmen. Wenn wir also in der Lage wären, ein Phänomen mathematisch zu beschreiben, wäre es keine triviale Aufgabe, die resultierende Formel so zu korrigieren, dass sie nur manchmal das falsche Ergebnis liefert. Dennoch ist es nicht an der Zeit zu verzweifeln. Dabei können uns Randbedingungen weiterhelfen. Wir alle haben diese if index == 0 {…} else if index == n-1 {…} gesehen. Mit den Grenzen stimmt immer etwas nicht 🤷‍♀️. Beachten wir also die erste Idee zum Erstellen eines Fehlers: Randfälle ignorieren .

Im Allgemeinen ist das Durchlaufen von Arrays eine Quelle potenzieller Fehler. Und die häufigste davon ist „Index außerhalb der Grenzen“ . Wenn Sie noch nie auf so etwas gestoßen sind, haben Sie noch nie codiert. Leider ist dieser Fehler so weit verbreitet, dass man begann, sichere Wrapper für Arrays zu schreiben, etwa array[safe: index] . Daher werden Ihre Kollegen heute kaum einen Code ohne dieses Ding genehmigen. Sie können es versuchen, aber es ist unwahrscheinlich ...

Zu den häufigsten Fehlern gehört der Stapelüberlauf . Ein rekursiver Algorithmus kann unendlich oft wiederholt werden, wenn keine Beendigungsbedingung vorliegt. Rekursion scheint hier optional zu sein – schreiben Sie while true , und Sie sind fertig. Allerdings spielt die Popularität des Fehlers erneut gegen uns. Die Entwickler sind sich der potenziellen Probleme von Endlosschleifen durchaus bewusst und werden beim Code-Review auf jeden Fall auf so etwas stoßen 👮

Um Ihren heimtückischen Plan dennoch in die Tat umzusetzen, versuchen Sie , eine globale Variable für Beendigungsbedingungen zu verwenden und diese stillschweigend von außen zu ändern .

 var coditionCounter = 0; class A { func foo() { while coditionCounter < 10 { coditionCounter++; B.boo(); } } } class B { func boo() { coditionCounter--; } }

Allgemeine Ratschläge

Es ist lustig, dass sogar ChatGPT sich weigert, beim Schreiben von Fehlern zu helfen. Vielleicht brauche ich einfach ein Premium-Abonnement… 🤔

Positiv zu vermerken ist, dass KI eine Reihe allgemeiner Regeln bietet, die zum Schreiben von fehlerfreiem Code beitragen: In kleinen Schritten codieren, Codierungsstandards befolgen, Unit-Tests schreiben und Bla-Bla-Bla. Wir können das Gegenteil versuchen – Spaghetti-Code schreiben und SOLID vergessen. Allerdings verlieren wir auf diese Weise die Kontrolle über den gesamten Code, den wir schreiben. Anstelle einer eleganten Punktwaffe erhalten wir ein unkontrollierbares Chaos, das unser Programm erobern wird.

Bei der Lösung des Problems der Entstehung eines Fehlers lohnt es sich, die Teilaufgaben festzulegen. Zuerst müssen wir uns einige seltene Randfälle einfallen lassen. Zweitens müssen wir den Fehler als regulären Code tarnen, damit er die Codeüberprüfung besteht. Drittens müssen wir die Aufmerksamkeit der Qualitätssicherungsabteilung abschwächen. Viertens: Lassen Sie sich nicht gleich erwischen. Dies ist aber bereits optional.

Mein allgemeiner Rat ist wie folgt (und Sie teilen Ihren in den Kommentaren):

• Bearbeiten Sie die Zugriffsebene . Um einen Rückzieher zu machen, ändern Sie die Werte wichtiger Parameter an den unerwartetsten Stellen. Tun Sie dies über mehrere Kurse hinweg, als wären Sie ein VPN.

• Implementieren Sie eine unerwartete Logik in der untergeordneten Klasse. Kurz gesagt, brechen Sie das L-Prinzip in SOLID .

   class A { func decrease() { x--; } } class B: A { override func decrease() { x++; } }

• Verstecken Sie Ihre heimtückischen Änderungen in größeren Funktionen. Je mehr Schlangen, desto besser – verlieren Sie sich in der Menge.

• Verwenden Sie dasselbe Prinzip bei Pull-Anfragen. Bei einer kleinen PR ist die Wahrscheinlichkeit, wahrgenommen zu werden, höher.

• Versuchen Sie, den Fehler in Teile aufzuteilen und sie in verschiedene Pull-Anfragen einzufügen. Wenn möglich, dann auch an verschiedene Gutachter.

• Finden Sie die Schwächen Ihrer Qualitätssicherung und gewinnen Sie sein Vertrauen. Oder lenken Sie sie mit Gesprächen während der Kontrolle ab.

Haben Sie übrigens schon von Heisenbug gehört? Dies ist ein Fehler, der während der Recherche/ Debugging verschwindet oder sein Verhalten ändert. Wie Schrödingers Katze. Perfekt, wenn das Fix-Problem nicht Ihnen zugewiesen wird.

Du kannst

An sich selbst glauben! Die Geschichte kennt Beispiele dafür, dass in sehr seriösen Unternehmen ein Fehler in die Produktion gelangte.

Ariane-5-Flug 501: Einer der teuersten Softwarefehler trat 1996 auf, als die Ariane-5-Rakete mit der Cluster-Mission nur 40 Sekunden nach dem Start explodierte. Der Fehler wurde auf einen Softwarefehler im Leitsystem der Rakete zurückgeführt.

Der Mars Climate Orbiter der NASA: 1999 verlor die NASA den Mars Climate Orbiter aufgrund eines Softwarefehlers. Die Software verwendete imperiale Einheiten (Pfundsekunden) anstelle von metrischen Einheiten (Newtonsekunden), was dazu führte, dass das Raumschiff in der Marsatmosphäre verglühte.

Darüber hinaus können einige Fehler zu Features werden, wie z. B. ein Mauerspringen in Mario oder das Verhalten von Mahatma Gandh in Civilization … wahrscheinlich.

Einen Fehler zu entwickeln ist die Fähigkeit, Ihren Algorithmus zu durchdenken und mögliche Probleme gründlich zu antizipieren. Auch wenn Sie also keinen Grund haben, einen Fehler im Code zu belassen, ist es dennoch eine Überlegung wert.