Wie kann ich das Kopier- / Einfügemuster korrigieren?

Wo ich arbeite, fühlen sich Leute (Berater) gedrängt, Features so schnell wie möglich freizugeben. Anstatt also zu viel Zeit damit zu verbringen, darüber nachzudenken, wie man Dinge richtig macht oder weil sie nichts kaputt machen wollen, wird Code aus verschiedenen Modulen kopiert und modifiziert.

Dies zu verhindern ist nicht einfach, da die Codebasis für das gesamte Unternehmen offen ist. Viele Leute arbeiten daran.

Was ist der beste Weg, um diese Redundanzen zu beseitigen, ohne zu viel zu verlieren?

Ein Teil der Antwort lautet Refactoring .

Beginnen Sie zunächst mit dem Schreiben von Komponententests, um sicherzustellen, dass Sie Ihre Änderungen nicht versehentlich ändern. Beginnen Sie dann mit der Verbesserung des Designs, dem Entfernen von Duplikaten usw. in kleinen Schritten, führen Sie Ihre Komponententests nach jedem Schritt durch, beheben Sie Probleme, wenn einer der Tests fehlschlägt, oder kehren Sie sofort zurück, wenn Sie auf ein größeres Problem stoßen, das Sie nicht leicht lösen können.

Der andere Teil ist Bildung .

Den Menschen muss beigebracht werden, keinen schlechten Code zurückzulassen. Dies ist sicherlich ein langfristiger Kampf, da Gewohnheiten und Denkprozesse nur schwer (manchmal sogar unmöglich) zu ändern sind . Ohne sie erhalten Sie jedoch weiterhin einen endlosen Vorrat an schlechtem Code, der schreit, um überarbeitet zu werden.

Sie können Gruppencodeüberprüfungen durchführen, um eine Diskussion über gute und schlechte Codierungsgewohnheiten zu eröffnen und deren Vorteile zu verbreiten. Es reicht nicht aus zu sagen "Sie müssen (nicht) Code wie diesen schreiben", Sie müssen die Leute mit Logik und harten Fakten überzeugen. Beispiel: "Wenn Sie diese Methode n- mal über die Codebasis dupliziert haben, wie stehen die Chancen, dass ein in dieser Methode gefundener Fehler in jeder Kopie des Methodencodes behoben wird?"

Möglicherweise muss Ihr Unternehmen auch die Anreize und Akzeptanzkriterien für die Berater überarbeiten. Wenn sie mit dem Schreiben von Sloppy-Code davonkommen, werden sie mit Sicherheit weiterhin den einfacheren Weg wählen. Wenn das Unternehmen weiterhin Wert auf eine "schnelle Lieferung" über eine langfristige Wartbarkeit legt, ändert sich nichts :-( Sie müssen dies möglicherweise auch mit dem Management besprechen. Ein Weg, dies zu verstehen, ist: Umgestalten bedeutet, den Code sauber und einfach zu halten Verstehen und pflegen Das Weglassen von Refactoring ist wie das Anhäufen von Schulden auf Ihrer Kreditkarte. Sie können eine Weile damit durchkommen, aber wenn Sie Ihre Kaufgewohnheiten und Schulden nicht aktiv verwalten, wird es eines Tages unweigerlich auf Ihren Schultern zerfallen. Während der Laufzeit eines Softwareprojekts kommt es zu einem Konkurs, wenn das Projekt nicht mehr verwaltet werden kann: Es ist einfacher, es von Grund auf neu zu schreiben, als der vorhandenen Codebasis eine neue Funktion hinzuzufügen. Oder Benutzer haben es so satt, dass sie einfach auf die Konkurrenz umsteigen.

Im Rahmen von Schulungen wie @Peter können Sie einen Copy & Paste-Detektor wie PMD einführen und als Teil Ihres Builds verwenden, um diesen Teil Ihrer Codierungsstandards durchzusetzen.

Stellen Sie sicher, dass der Kodierungsstandard Ihres Projekts dieses Muster abdeckt, damit Sie eine Ausgangsbasis haben, an der Sie Diskussionen beginnen können.

Menschen (Berater) fühlen sich gedrängt, Features so schnell wie möglich freizugeben

Sie haben kein technisches Problem, Sie haben ein soziales Problem. In der Tat haben Sie ein Managementproblem.

Dies zu verhindern ist nicht einfach, da die Codebasis für das gesamte Unternehmen offen ist. Viele Leute arbeiten daran.

Die "Codebasis ist für das gesamte Unternehmen offen" ist kein Problem. Spielt keine rolle

Entscheidend ist, dass ein Management-Belohnungssystem für das Kopieren und Einfügen vorhanden ist. Die Hauptursache ist, dass Menschen für das Kopieren und Einfügen belohnt (dh bezahlt oder gelobt oder befördert oder erweitert) werden.

Sie können dies nicht brechen, ohne die Kultur grundlegend zu ändern, von "so schnell wie möglich auf die Veröffentlichung von Features gedrängt" zu "dafür belohnt, dass Sie die entsprechenden, gut getesteten Änderungen an der Codebasis vorgenommen haben".

Sie müssen

1. Beginnen Sie oben mit den Managern, die die Belohnungen verstärken. Sie müssen die aktuelle Praxis aufdecken und die Kosten und Risiken dokumentieren. Sie müssen eine Alternative vorschlagen, die Kosten und Risiken reduziert.

2. Sie müssen die Kosten und Risiken für den Rest Ihrer Amtszeit in dieser Organisation unermüdlich dokumentieren und offenlegen. Unerbittlich. Faktenbasiert. Kosten und Risiko. Jede Woche mehr Kosten und mehr Risiko durch Kopieren und Einfügen.

3. Sie müssen den Managern dabei helfen, den neuen Ansatz zu würdigen, der sie gut aussehen lässt, und Sie werden ignoriert.

Es ist sehr wichtig, das Kopieren und Einfügen zu reduzieren. Es ist jedoch schwierig, die Kultur einer Organisation zu ändern. Sie müssen eine Menge Fakten liefern und den Fall immer wieder den Managern vorlegen, die Ihnen nicht zustimmen.

Ich habe jetzt eine Codebasis, die anfing zu faulen. Ich hatte über 10 statische Funktionen pro Modul, die im Grunde mit den gleichen statischen Funktionen in anderen Modulen identisch waren. Jeder verhielt sich gerade anders genug, um eine neue Inkarnation zu rechtfertigen, um die Dinge so schnell wie möglich zu erledigen.

Heute musste ich noch ein Feature hinzufügen und konnte es einfach nicht mehr aushalten. Ich habe eine neue Bibliothek erstellt, die über 100 Funktionen zu 10 wiedereintrittsfähigen Funktionen kombiniert, die ihr Verhalten basierend auf Bit-Flags geringfügig ändern, und dann eine Reihe von Tests geschrieben, um sicherzustellen, dass Änderungen an dieser Bibliothek nichts anderes bewirken.

Gesamtdauer: 4 Stunden. Ich war bereit, bei Bedarf einen 20-Stunden-Marathon zu laufen, und war überrascht, wie schnell ich ein wachsendes Durcheinander unter Kontrolle brachte. Als Bonus war es einfacher, eine Reihe von Problemen mit der Header-Abhängigkeit nachträglich zu beheben. Da ein Großteil unserer proprietären Inhalte jetzt in statischen Objekten zum Verknüpfen enthalten ist, können wir unseren Kunden, die Zugriff auf Quellcode erhalten, mehr als bisher bieten.

Mein Rat: Beißen Sie die Kugel und korrigieren Sie das Chaos, bevor es wirklich schlimm wird . Es wird wahrscheinlich nicht so lange dauern, wie Sie denken, aber für alle Fälle einen neuen Zweig für sich selbst erstellen.

Darüber hinaus können Sie weiterhin kopieren / einfügen, um Features aus der Tür zu holen, während Sie das grundlegende Problem beheben. Wenn Sie fertig sind, rippen Sie einfach das eingefügte Material aus und verwenden Sie stattdessen die neue Bibliothek.

Ich stimme den bisherigen Antworten zu. Du solltest:

• Komponententests erstellen
• Refactor
• erziehen
• Mühe in die Kodierung von Standards stecken und Verstöße erkennen

Auf der anderen Seite muss man sich ansehen, was die Leute dazu veranlasst, Paste zu kopieren und das zu beheben.

• Menschen sind möglicherweise nicht in der Lage, Code auf eine gute Weise wiederzuverwenden, da er mit vielem gekoppelt ist
• Die Leute wissen vielleicht nicht, dass es eine Bibliothek gibt, die sie benutzen können
• Der Bibliothekscode ist möglicherweise nicht generisch genug und das Backen Ihrer eigenen Version ist viel einfacher als das Verwenden einer vorhandenen Bibliothek
• Möglicherweise gibt es keine gute Versionsverwaltungsstrategie (keine Versionsverwaltungsstrategie), und das Ändern einer generischen Bibliothek kann dazu führen, dass auch viele andere Anwendungen getestet werden.

Ich denke, um das Kopieren / Einfügen-Muster zu stoppen, müssen Sie die Wiederverwendung vereinfachen.

• Bibliotheken auffindbar und gut dokumentiert machen
• Machen Sie die Bibliotheken unabhängig von allem
• Überlegen Sie sich eine gute Versionierungsstrategie
• Abwärtskompatibilität sicherstellen
• Denken Sie an die einfache Erweiterbarkeit der Bibliotheken

Lesen Sie die Framework Design Guidelines

Hoffe das hilft.

Es gibt eine starke "Kopierpaste als schädlich" Haltung. Ich finde es gut, geht aber ein bisschen zu weit. Kopieren und Einfügen als Übung zum Erkennen von Ähnlichkeiten und Unterschieden zwischen zwei Methoden oder Klassen - als ein Schritt im Triangulationsprozess - halte ich für gesund. Es ist jedoch in der Tat schädlich, die vollständige Triangulation zu unterbinden - die durch das Einfügen von Kopien verursachten Duplikate zu beseitigen.

Wenn Sie Wege finden, diese differenziertere Einstellung zu nutzen, um den Entwicklern nicht "das ist schlecht!", Sondern "das ist unvollständig" mitzuteilen, können Sie dann mit mir zusammenarbeiten, um das Refactoring abzuschließen?

Ich habe hier das gleiche Problem, und meine Meinung ist: Versuche nicht, es im Voraus zu vermeiden, sondern überarbeite es nur, wenn es zu schlimm wird.

Das Modul, an dem ich gerade arbeite, wurde als Kopie eines anderen Moduls gestartet. Jetzt ändere ich alles, was anders sein muss. Sobald dies erledigt ist und das neue Modul fertig ist, werde ich es mit dem ursprünglichen Modul vergleichen und herausfinden, welche Teile mehr oder weniger unverändert sind und in eine Bibliothek, eine abstrakte Elternklasse usw. verschoben werden sollten.

Wer verantwortlich ist, ist schuld. Es ist nicht zu erwarten, dass eine Person jede Codezeile überprüft, aber sie legt die Standards und den Zeitrahmen fest.

Auftragnehmer (oder alle, die sich kurzfristig mit einem Projekt befassen) können in die Position versetzt werden, in der sie nur dafür bezahlt werden, dass sie es zum ersten Mal zum Laufen bringen. Es gibt einen Anreiz, dies so schnell wie möglich zu tun. Der kopierte Code muss möglicherweise nie geändert werden, und wenn ja, wird er nicht von ihnen stammen.

Sie könnten versuchen, sie zu zwingen, es in ihrer eigenen Zeit zu beheben. Dann fangen sie von vorne an, nehmen sich dann aber eine Menge Zeit, um die Dinge zu erledigen. Ich denke, AmmoQ hat die richtige Idee, Dinge umzugestalten, die Probleme verursachen.

Die einzige Möglichkeit, um das Kopieren / Einfügen von Code zu vermeiden, besteht in (IMHO-) Codeüberprüfungen. Lassen Sie eine Person (oder vorzugsweise mehrere) den Code überprüfen, und lassen Sie den Programmierer überarbeiten, wenn sie einen Code finden, der aus einer Aktion zum Kopieren / Einfügen zu stammen scheint.

Wie vorgeschlagen ist dies hauptsächlich ein Problem in der Organisation. Versuchen Sie zunächst, die Mitarbeiter zu schulen (vergessen Sie nicht die direkte Managementebene über Ihrer Position). Es hilft sehr, ein oder zwei Leute in den Zug zu bekommen und den Virus verbreiten zu lassen. Wenn die Mehrheit der Meinung ist, dass dies eine gute Idee ist, lassen Sie sich beschreiben und versuchen Sie Bewertungen einzuführen, um sicherzustellen, dass dies auch so bleibt. Dies ist ein sehr langsamer und langwieriger Prozess, der sich jedoch nicht schnell ändern kann. Zunächst wird es zusätzliche Zeit kosten, daher ist es wichtig, dass das Management das langfristige Ziel kennt und unterstützt.

@Anders K. Bewertungen sind ein gutes Mittel, um die Praxis am Platz zu halten. Wenn Leute gezwungen werden, Code zu schreiben, glauben sie nicht daran, was zu viel Reibung führt. Sie werden in den alten Habbit zurückgreifen, sobald die Dose da ist. Ich bin der festen Überzeugung, dass Sie mit der Ausbildung beginnen sollten, um an Dynamik zu gewinnen.