Stellen Sie sich folgendes Szenario vor:

Sie haben festgestellt, dass Ihr (oder das eines anderen) Programms einen Fehler aufweist - eine Funktion führt bei einer bestimmten Eingabe zu einem falschen Ergebnis. Sie überprüfen den Code und können nichts Falsches feststellen: Bei dieser Eingabe scheint er nur zu stecken.

Sie können nun eine der beiden folgenden Aktionen ausführen: Sie untersuchen den Code weiter, bis Sie die tatsächliche Ursache gefunden haben. Oder Sie schlagen auf einen Verband, indem Sie eine ifAnweisung hinzufügen , die überprüft, ob es sich bei der Eingabe um diese bestimmte Eingabe handelt. Wenn dies der Fall ist, geben Sie den erwarteten Wert zurück.

Das Anlegen des Verbandes wäre für mich völlig inakzeptabel. Wenn sich der Code bei dieser Eingabe unerwartet verhält, auf welche andere Eingabe, die Sie verpasst haben, reagiert er merkwürdig? Es scheint überhaupt keine Lösung zu sein - Sie schaufeln das Problem einfach unter den Teppich.

Da ich das gar nicht in Betracht ziehen würde, wundere ich mich darüber, wie oft die Professoren und Bücher uns daran erinnern, dass das Anwenden von "Verband" -Korrekturen keine gute Idee ist. Ich frage mich also, wie häufig diese Art von "Korrekturen" vorkommen.

Zeit- / Termindruck sind ein Grund.

Wenn Sie mit einer engen Frist konfrontiert sind und Ihr Chef Ihnen den Hals runter atmet (möglicherweise im wahrsten Sinne des Wortes!), Dann ist es sehr verlockend, wenn Sie denken, "Ich komme zurück und repariere das später" und vielleicht sind Sie das einzige, was Sie tun tun können.

Natürlich ist die Häufigkeit, mit der Sie zurückkehren und das Problem ordnungsgemäß beheben, sehr gering, da Sie ein neues Problem haben, das gestern behoben werden muss.

So sehr wir als Programmierer dies auch nicht gerne zugeben, eine schön codierte Software wird nicht immer einen Mehrwert für das Unternehmen oder die Kunden bedeuten. Dies gilt in einer Katastrophensituation in doppelter Hinsicht, zum Beispiel, wenn die Software die Kreditkarten von Personen doppelt belastet. Manchmal müssen Sie wie bei einem Verband nur die Blutung mit den erforderlichen Mitteln stoppen und versprechen, nach der Stabilisierung des Patienten wiederzukommen und das Kernproblem tatsächlich zu beheben.

Der Trick ist, dass es wirklich schwierig ist, irgendjemanden davon zu überzeugen, die Bandage durch eine echte Lösung zu ersetzen, wenn die Dringlichkeit erst einmal verflogen ist. Vor allem, wenn man bedenkt, dass hinter dem ersten immer noch ein dringendes Problem ansteht. Sie müssen nur wachsam sein, wenn es darum geht, das Problem über die schnelle Lösung hinaus zu lösen.

Zeit

Ist meiner Meinung nach der Hauptgrund. Obwohl, wenn das Problem Codebasis weise ist, ich mehr Zeit nehmen könnte, um es zu untersuchen. Oft beinhalten meine "Bandage" -Fixes CSS- oder UI-Optimierungen. Ich habe einige ziemlich böse Inline-CSS und JavaScript geschrieben, um schnell damit umzugehen. Zurückgehen und es reparieren ist immer eine Option, wenn Sie die Zeit haben.

Wir machen sie ausnahmsweise.

Bei Fixes während der Entwicklung stellen wir sicher, dass keine Fixes durchgeführt werden, ohne die Hauptursache zu kennen. Jedoch:

• In Ausnahmefällen wird die Suche nach der Ursache zu lange dauern oder zum Stillstand kommen UND es gibt eine harte Frist,
• Ausnahmsweise sind Codeänderungen zur Behebung der Grundursache aus taktischen Gründen nicht möglich (Änderungen dauern zu lange und nähern sich der Frist).

In diesen Fällen entscheiden wir uns für "Verband" -Fixes. Anschließend öffnen wir interne Fehler, um die Grundursache zu beheben. Ja, häufig werden diese internen Fehler mit sehr geringer Priorität behandelt.

Bei Fixes im Wartungs-Stream stellen wir sicher, dass keine Fixes durchgeführt werden, ohne die Hauptursache zu kennen. Jedoch:

• Sehr ausnahmsweise wird die Suche nach der Grundursache zum Stillstand kommen,
• In Ausnahmefällen kann es vorkommen, dass die Behebung der Grundursache taktisch nicht möglich ist (Änderung ist nicht trivial und der Kunde hat die Behebung gestern benötigt).

In diesen Fällen entscheiden wir uns zuerst für die temporäre Fixierung "Bandage". Wenn der Kunde zufrieden ist, arbeiten wir an der korrekten Fixierung und erst dann ist der Fehler behoben.

Begriffsklärung.

• In Anbetracht eines bestimmten Fehlers ist es sehr schwierig, objektiv zu bestimmen, ob ein bestimmter Fix eine "Bandage" ist, weil: die "richtige Lösung" die "Bandage" einer anderen Person sein kann.
• Also benutze ich die folgende Definition: um einen Defekt auf eine Weise zu beheben, die weniger elegant und weniger gut durchdacht ist, als ich es mir professionell gewünscht hätte.

Erstens, in Bezug auf die Häufigkeit von "Verband" -Fixes:

• Neuer Code: fast keiner.
• Alter Code:
  • Sie werden einige finden, obwohl sie normalerweise elegant genug geschrieben sind (siehe "Datengesteuerte Schadensbegrenzung" unten), dass sie nicht wie Bandagen aussehen und alle Codeüberprüfungen überstehen.
  • Achten Sie auch auf den "unsichtbaren Verband": Rufen Sie diese Funktion einfach nicht auf. Aufgrund des fehlenden Codes gibt es nicht einmal einen Hinweis darauf, dass ein Fehler vorliegt.
• Alter Code mit vielen externen Abhängigkeiten:
  • Fast voll davon.
  • Es wurde fast immer für eine veraltete Version der Abhängigkeit geschrieben, und niemand hat die "Versionshinweise" der Abhängigkeit wirklich gelesen, bevor die Abhängigkeit auf eine neue Version aktualisiert wurde.

Zweitens mein Rat:

Wenn der Fehler im Quellcode eines Entwicklerteams auftritt:

• Repariere es auf professionelle Weise. (Wenn Sie es reparieren, besitzen Sie es.)
• Wenn Sie unter Zeitdruck stehen, tun Sie das Beste, was Sie können. Dazu müssen Sie:
  • Betrachten Sie die möglichen Auswirkungen auf den Endbenutzer: auf den Fehler selbst und auf den vorgeschlagenen Fix, um zu entscheiden, ob der Fix akzeptiert werden soll.
  • Studieren Sie verwandte Codeausschnitte (unter Verwendung der Verlaufsinformationen aus Ihrem Quellcodeverwaltungs-Tool) und besprechen Sie sie mit Ihren Mitarbeitern (nehmen Sie jedoch nicht zu viel Zeit in Anspruch), bis Sie das Problem und die Lösung gut verstanden haben.
• Verfolgen Sie den Fehler immer mit einem Fehlerverfolgungssystem .

Wenn der Fehler im Quellcode eines anderen Teams auftritt:

• Schieben Sie das Team, um den Fehler zu beheben.
• Melden Sie diesen Fehler immer beim Fehlerverfolgungssystem des anderen Teams an .

Wenn der Fehler in einem Produkt eines anderen Unternehmens (oder in einem Produkt eines anderen Unternehmens) auftritt:

• In diesem Fall können nur Korrekturen auf Klebeband (oder datengesteuerte Problemumgehungen ) den Fehler beheben.
• Wenn es Open Source ist, archivieren Sie diesen Fehler trotzdem mit einem (möglicherweise öffentlichen) Fehlerverfolgungssystem , damit sich jemand darum kümmern kann.

Kommt sehr auf das Alter der Codebasis an, denke ich. Bei altem Code finde ich es sehr verbreitet, dass das Umschreiben der 20 Jahre alten COBOL-Routine keinen Spaß macht. Sogar auf mäßig neuem Code, der in Produktion ist, ist es noch ziemlich verbreitet.

Ich würde sagen, es ist sehr verbreitet.

Lesen Sie den Blog-Beitrag von Joel Spolsky: The Duct Tape Programmer

Ich kann leicht sagen , dass fast jedes Projekt , das ich je gesehen habe auf Ich hatte anwenden irgendeine Art von Verband oder Klebeband zu treffen Fristen und füllen Sie eine Aufgabe. Es ist nicht schön, es ist nicht sauber, aber es erledigt die Arbeit, damit ein Unternehmen weiterarbeiten und das Projekt auf irgendeine Weise voranschreiten kann.

Es gibt einen Unterschied zwischen der akademischen Welt und der realen Welt, in der Software tatsächlich unter Zeit- und Geschäftsbeschränkungen ausgeliefert werden muss.

In gewisser Weise wird es unter den Teppich gelegt, um eine Lösung bis hoffentlich später aufzuschieben. Leider passiert die verzögerte Korrektur zu oft nie und dieser Code findet Eingang in die Produktion.

Ohne mehr Kontext ist es schwierig zu sagen - warum ist das Hinzufügen der if-Anweisung in Ihrem Beispiel nicht die richtige Korrektur? Liegt es daran, dass sich irgendwo ein anderer Codeblock mit dieser Eingabe befassen soll?

Wie oft Verbandfixes verwendet werden, hängt von einer Reihe von Faktoren ab, wie komplex der Code ist und ob die mit dem Code vertrauteste Person verfügbar ist (die Person, die für die 20-jährige COBOL-Routine von Craig verantwortlich ist, hat das Unternehmen möglicherweise vor Jahren verlassen ) und den Zeitrahmen.

Mit einer Frist, die Sie ins Gesicht starrt, werden Sie manchmal für die sicherere Lösung plumpsen, selbst wenn es nur darum geht, ein Pflaster aufzuschlagen, anstatt die Grundursache zu beheben. Das ist in Ordnung, solange Sie nichts Schlimmeres tun, aber es ist wichtig, die Tatsache zu verfolgen, dass es immer noch nicht korrekt ist und immer noch richtig repariert werden muss.

Es gibt Fälle, in denen diese Art der Korrektur wirklich in Ordnung und wahrscheinlich die ideale ist (was die Zeit zum Debuggen betrifft).

Stellen Sie sich ein Szenario vor, in dem Sie 20 DLLs haben, die als eine Art Modul für Ihre ausführbare Hauptdatei fungieren sollen, aber auch einige Informationen von der ausführbaren Hauptdatei benötigen, um ausgeführt zu werden.

Wenn Sie diese DLLs jemals außerhalb der ausführbaren Hauptdatei verwenden möchten, müssen Sie einige Rückgabewerte aus der ausführbaren Hauptdatei fudgen, weil. A.) Es existiert in diesem Kontext nicht und B.) Sie wollen nicht, dass es in diesem Kontext existiert.

Abgesehen davon sollten Sie einige Compiler-Direktiven in Ihren Code einfügen, um sicherzustellen, dass Sie einen völlig anderen Code ausführen, wenn Sie die Ergebnisse verfälschen, als wenn Sie die tatsächlichen Ergebnisse erhalten.

Anstatt eine ifFunktion in eine andere Funktion zu integrieren, würde ich {$ifdef}die Funktion mit einer Umgehung versehen - auf diese Weise verwechselt niemand sie mit etwas, das vorhanden sein sollte.