Warum ist das Kopieren und Einfügen von Code gefährlich? [geschlossen]

Manchmal beschwert sich mein Chef bei uns:

Warum brauchen wir so viel Zeit, um eine Funktion zu implementieren?

Tatsächlich wurde die Funktion bereits in einer anderen Anwendung implementiert. Sie müssen lediglich Codes von dort kopieren und einfügen. Die Kosten sollten niedrig sein.

Es ist wirklich eine schwierige Frage, denn das Kopieren und Einfügen von Codes ist aus meiner Sicht nicht so einfach.

Haben Sie gute Gründe, dies Ihrem nicht-technischen Chef zu erklären?

Wenn Sie einen Fehler in Ihrem Code zum Einfügen und Kopieren finden, müssen Sie ihn an jeder Stelle beheben, an der Sie ihn gemacht haben, und hoffen, dass Sie sich an alle erinnern können (dies gilt auch für geänderte Anforderungen).

Wenn Sie die Logik an einem Ort aufbewahren, ist es einfacher, sie bei Bedarf zu ändern (wenn Sie also entscheiden, dass die Anwendung aktualisiert werden muss, tun Sie dies nur an einem Ort).

Lassen Sie Ihren Chef über das DRY-Prinzip lesen (Wiederholen Sie sich nicht).

Was Sie beschreiben, klingt nach der perfekten Verwendung für Bibliotheken , in denen Sie Code gemeinsam nutzen und nur an einem Ort aufbewahren.

Ich würde Code immer nur kopieren und einfügen, wenn ich ihn bald darauf umgestalten wollte - um sicherzustellen, dass ich später gemeinsamen Code extrahiere, damit ich so viel Logik wie möglich wiederverwenden kann. Und bald danach meine ich Minuten und Stunden später, nicht Tage und Wochen.

Sie würden weit besser dran , den Austausch durch den Aufbau einer Bibliothek den Code anstatt Kopieren Sie den Code Kopieren und Einfügen.

Sie erhalten immer noch einen Geschwindigkeitsvorteil gegenüber dem erneuten Schreiben (DRY nachschlagen), haben jedoch nur einen Platz, um den Code zu verwalten.

Der offensichtliche Grund ist, dass Sie eine „Schuld“ für die Zukunft übernehmen: Jede Änderung, die Sie jemals am Code vornehmen müssen (nicht nur Bugfixes, jede Änderung), ist jetzt doppelt so teuer, da Sie zwei Stellen aktualisieren müssen - und riskanter, weil Sie irgendwann einen von ihnen vergessen werden. Mit anderen Worten, wenn Sie es jetzt schneller arbeiten lassen, wird Ihre Arbeit in Zukunft noch langsamer. Dies kann wirtschaftlich sinnvoll sein, ist es aber normalerweise nicht.

Der wichtigere Grund ist jedoch, dass die Annahme "das ist das Gleiche wie das" meistens subtil falsch ist. Wenn Ihr Code von unausgesprochenen Annahmen abhängt, um korrekt zu sein, führt das Kopieren an einen anderen Ort zu Fehlern, es sei denn, diese Annahmen gelten auch für den neuen Ort. Daher ist der eingefügte Code häufig von Anfang an falsch und nicht erst nach der nächsten Änderung.

In Bezug auf das Design ist das Einfügen von Code sicherlich eine Katastrophe, die in Zukunft viele Probleme verursachen kann. Aber Sie fragen sich, warum Sie gerade jetzt viel Arbeit benötigen . Die Antwort lautet: Weil es nie nur Kopieren und Einfügen ist.

Wenn der ursprüngliche Code geschrieben wurde, um als ziemlich unabhängige Bibliothek unter Berücksichtigung der Flexibilität und der Verwendung durch den Client wiederverwendet zu werden - dann großartig, aber das ist kein Kopieren, sondern das Verwenden einer Codebibliothek. Das Einfügen von echtem Code funktioniert normalerweise eher so:

• "Sicher, ich habe bereits Code, der genau das tut!"
• "Warten Sie, welche dieser fünf Codeversionen möchte ich als Quelle verwenden?"
• "Hmmm, was machen all diese 'util_func_023'-Funktionen? Habe ich sie nicht dokumentiert? Welche brauche ich jetzt?"
• "Oh ja, dieser Code verwendet Code Base Y. Ich denke, ich muss [einen auswählen: Kopieren Sie den gesamten Code Base Y in mein neues Projekt / verbringen Sie einen Tag damit, die eine Funktion zu extrahieren, die ich aus Code Base Y herausholen möchte / verbringen Sie eine Woche damit, den Code zu extrahieren eine Funktion, die ich von Code Base Y möchte]. "
• "Ich habe alles kopiert, yay!"
• "Warum funktioniert das nicht?"
• Dies ist der Punkt, an dem Sie Stunden / Tage / Wochen damit verbringen, vorhandenen Code zu debuggen, der dem entspricht, was Sie möchten, anstatt den Code zu schreiben, mit dem Sie tatsächlich beginnen möchten.

Zusammenfassend kann vorhandener Code, der nicht direkt verwendet werden kann, bestenfalls als gute Referenz für das Schreiben von ähnlichem Code dienen. Es kann sicherlich nicht ganz angehoben werden und es wird erwartet, dass es in einem völlig anderen System funktioniert. Im Allgemeinen ist es eine sichere Annahme, dass jeder Code, der geschrieben und vervollständigt wurde, mit so wenig wie möglich durcheinander gebracht werden sollte - selbst wenn es sich um eine Kopie handelt und nicht um das Original selbst.

Wenn Sie Ihr Projekt auf das Einfügen von Kopien stützen möchten, müssen Sie zunächst so codieren , dass eine einfache Wiederverwendung möglich ist, ohne den ursprünglichen Code zu kopieren und damit herumzuspielen. Das lohnt sich, und wenn Ihr Chef dies erwartet, müssen Sie beide sicherstellen, dass Sie in erster Linie so entwerfen und arbeiten.

Kopieren und Einfügen ist eine Katastrophe, die darauf wartet, passiert zu werden. Ihr Chef sollte den Preis für den Versand frühzeitig in Bezug auf den Preis für den Versand eines fehlerhaften Codes an den Endbenutzer bewerten.

Wenn Sie bereits die Funktionen implementiert haben , und Sie müssen kopieren und sie wieder zu verwenden, es klingt wie Sie etwas falsch gemacht haben. Können Sie diese Funktionen nicht in eine Bibliothek einfügen, damit Sie sie ohne Kopieren / Einfügen wiederverwenden können?

Das DRY-Prinzip (Wiederholen Sie sich nicht): DRY auf Wikipedia .

"Jedes Wissen muss eine einzige, eindeutige und maßgebliche Darstellung innerhalb eines Systems haben."

anderer Link .

Es klingt für mich nach dem schlimmsten Missverständnis, das Ihr nicht-technischer Chef hat, dass Ihr Job hauptsächlich das Tippen ist. Sie denken, Sie können viel Zeit sparen, indem Sie das Tippen eliminieren.

Ich denke, die beste Ausbildung, die Sie dieser Person geben können, besteht darin, auf all Ihre Arbeit hinzuweisen, die Sie nicht tippen. Auch wenn der größte Teil dieser Arbeit normalerweise unsichtbar in Ihrem Kopf geschieht, gleichzeitig mit dem Tippen.

Sicher, das Eliminieren der Eingabe spart einige Zeit. Aber dann wird der viel größere, nicht tippende Teil Ihres Jobs größer und kostet Zeit und mehr.

Sind Sie sicher, dass Ihr Chef etwas über das DRY-Prinzip, Fehler und andere technische Dinge erfahren möchte?

Diese Art von Kommentaren hören Sie normalerweise, wenn Ihr Chef oder Ihr Unternehmen die für die Fertigstellung eines Projekts erforderliche Zeit unterschätzt hat. Und aufgrund einer falschen Schätzung wurde ein Vertrag unterzeichnet usw. In den meisten Fällen waren Programmierer nicht an Schätzungen beteiligt.

Warum passiert das? Manchmal hat der Projektsponsor ein zu kleines Budget. Möglicherweise ist ein Geschäftsprozess, den Sie mithilfe von Software automatisieren, Ihre Teamarbeit nicht wert. Manager sind in solchen Fällen im Allgemeinen für schlechte Nachrichten sehr geschlossen. Zu Beginn des Projekts gibt es Wunschdenken. Dann versuchen Manager, Programmierern die Schuld zu geben. In Ihrem Fall indirekt per Copy-and-Paste. In extremen Fällen spricht man von einem Todesmarsch .

Das Kopieren und Einfügen von Code führt normalerweise zur Programmierung durch Zufall

Ich denke, "eine andere Anwendung " ist hier der Schlüssel. Wenn die andere Anwendung bereits getestet und verwendet wird, sollte sie nicht geändert werden , um eine gemeinsame Bibliothek zu verwenden. Daher können Sie keinen Code mit ihr teilen.

Innerhalb derselben Anwendung ist "Kopieren und Einfügen" schlecht, aber zwischen Codebasen, die von verschiedenen Teams oder mit unterschiedlichen Veröffentlichungszyklen entwickelt wurden, kann "Kopieren und Einfügen" die beste Option sein.

Ich habe für eine ähnliche Firma gearbeitet. Als Auszubildender wusste ich es damals nicht besser. Als ich ein neues Projekt startete, schlug mein Chef vor, den Code von einer anderen Stelle einzufügen. Nun, wie Sie vielleicht denken, war die gesamte Software ziemlich durcheinander, bis zu dem Punkt, an dem Sie versuchten, einen Fehler zu beheben, zwei neue Fehler auftraten.

Selbst wenn die andere Anwendung bereits über die von Ihnen benötigte Funktion verfügt, passt der Code für diese Funktion möglicherweise nicht ohne größere Umschreibung in Ihre aktuelle Anwendung. Es ist, als würde man den Motor eines Ford nehmen und versuchen, ihn in einen Toyota einzubauen. Im Allgemeinen gilt die Faustregel, dass es besser (billiger) ist, den von Grund auf neu geschriebenen Code neu zu schreiben, wenn Sie mehr als 25% des kopierten Codes ändern müssen.

Das Extrahieren des betreffenden Codes in eine Bibliothek klingt überzeugend, ist jedoch möglicherweise schwieriger als es sich anhört, je nachdem, wie das andere System aufgebaut ist. Beispielsweise ist der Code für diese Funktion möglicherweise schwer zu extrahieren, da er viele andere Codes auf unreine Weise miteinander verbindet (z. B. durch Zugriff auf viele globale Variablen usw.).

Sagen Sie Ihrem Chef, dass der Teil jedes Variablennamens den Namen des alten Projekts enthält, und jetzt müssen Sie alle manuell ändern. Wenn Ihr Chef nicht weiß (oder wissen möchte), warum Kopieren / Einfügen schlecht ist, könnte er das genauso gut glauben :)

Ja, das größte Problem ist, dass es nicht nur kopiert und eingefügt wird - es wird kopiert, dann eingefügt und dann leicht geändert.

Wenn später eine der eingefügten Varianten ein Problem hat, wird sie geändert. Später wird dann eine andere Variante geändert.

Dann stellen Sie fest, dass sich alle Varianten ändern müssen, da die Originalkopie Fehler aufwies. Jetzt sind Sie wirklich geschraubt, weil jetzt nicht alle geklebten Bereiche gleich sind.

Und würden Sie es nicht wissen, diese Art von beschissener Codierung ist normalerweise fast völlig kommentarlos.

Für mich besteht der Unterschied darin, dass Sie, wenn Sie mehrere Kopien von Code haben, die dasselbe tun, eine Menge Code haben. Wenn Sie nur einen Code haben, der die jeweilige Aufgabe ausführt, haben Sie ein System.

Das Verhalten eines Systems kann ganz einfach mit Einzelpunktänderungen geändert werden. Um das Verhalten einer Reihe von Codes zu ändern, ist eine Reihe von Codes erforderlich.

Ich mag Systeme, keine Menge Code.

Es gibt Kompromisse zwischen der Geschwindigkeit der Entwicklung der unmittelbaren Funktionalität vor Ihnen (insbesondere wenn die Anwendung klein ist) und den längerfristigen Wartungskosten, wenn die Anwendung wächst.

Das Kopieren und Einfügen ist für die sofortige Funktionalität schneller, kostet Sie jedoch mit zunehmender Größe der Anwendung viel Geld, da Fehler behoben, systemweite Änderungen vorgenommen und Workflows zwischen verschiedenen Komponenten der Anwendung beibehalten werden.

Das ist das Argument, das Unternehmer hören müssen. Es ähnelt den akzeptierten Kosten für die Wartung einer Fahrzeugflotte. Mit Software sind die fehlerhaften Aspekte der Softwarearchitektur jedoch im Allgemeinen für die Unternehmensseite verborgen und können nur von Entwicklern gesehen werden.

Er hat Recht, wenn das Team zuvor ähnliche Funktionen implementiert hat, wird es beim zweiten Mal viel einfacher sein , sie zu wiederholen .

Sie sollten jedoch wahrscheinlich erklären, dass jede Anwendung anders ist. Nur weil Sie eine Tür in einem Haus installiert haben, heißt das nicht, dass Sie in kürzester Zeit eine andere Tür in einem anderen Haus installieren können - Sie werden aufgrund der Erfahrung schneller sein (# Türen installiert), aber es wird immer noch einige Zeit dauern, bis Sie Ihre Ausrüstung erhalten Montieren Sie die Tür, stellen Sie sicher, dass sie lotrecht ist, und schrauben Sie sie in den Rahmen.

In meiner Firma arbeiten wir immer mit Klassen und Methoden und erstellen technische Dokumentationen für diese. Ich denke, es ist die beste Vorgehensweise, wenn Sie Ihre eigenen SVN-Suchanwendungen mit guten Schlüsseln verwenden können, um die zuvor verwendete Methodenklasse zu finden :)