Copypaste in der App-Entwicklung — was es ist, warum es gefährlich ist und wie man es vermeidet

Was ist Copypaste?

Copypaste (Copy-Paste-Programmierung) ist das Verschieben von vorhandenem Code an einen neuen Ort mit wenigen oder keinen Änderungen. Der Begriff wird abwertend verwendet: Er impliziert, dass der Entwickler keine Lösung entwirft, sondern einen fertigen Block mechanisch kopiert, oft ohne vollständig zu verstehen, wie er funktioniert.

Copypaste tritt in zwei Formen auf: beabsichtigt (intentional) und versehentlich (accidental). Beabsichtigt — wenn ein Entwickler Code bewusst mit dem Plan kopiert, ihn später zu refaktorisieren (aber der Plan wird oft aufgegeben). Versehentlich — wenn Duplikation unbemerkt entsteht, zum Beispiel wenn zwei Entwickler unabhängig voneinander dieselbe Logik für verschiedene Bildschirme schreiben.

Laut dem Bericht SonarQube State of Clean Code (2025) macht duplizierter Code in kommerziellen Projekten durchschnittlich 12–18 Prozent des gesamten Codevolumens aus. Gleichzeitig sind die Kosten für die Behebung eines Fehlers in dupliziertem Code 2,5-mal höher als in Code mit einer einzigen Implementierung, weil der Entwickler alle Kopien finden und korrigieren muss.

Das wichtigste Werkzeug gegen Copypaste ist das DRY-Prinzip (Don't Repeat Yourself). Allerdings ist es auch gefährlich, DRY zu verabsolutieren: Manchmal ist Kopieren gerechtfertigt, wenn zwei Kopien unabhängig voneinander evolvieren müssen. Wichtig ist, zwischen „versehentlicher Duplikation“ (die beseitigt werden muss) und „notwendiger Duplikation“ (die dokumentiert werden muss) zu unterscheiden.

Warum Copypaste gefährlich ist

Die erste und wichtigste Gefahr ist die Verbreitung von Bugs. Wenn der ursprüngliche Code einen Fehler enthält, wird er zusammen mit dem Code an alle neuen Stellen kopiert. Wenn der Fehler entdeckt und im ursprünglichen Modul behoben wird, bleiben die Kopien unkorrigiert. Der Entwickler weiß möglicherweise nicht einmal, dass der Bug in fünf verschiedenen Dateien existiert.

Die zweite Gefahr ist die ungleiche Evolution. Zwei Kopien desselben Algorithmus sammeln im Laufe der Zeit unterschiedliche Änderungen an. Eine Kopie fügt eine Grenzwertvalidierung hinzu, eine andere ändert das Ausgabeformat. Nach einigen Monaten ist nicht mehr feststellbar, welche Version „richtig“ ist, und das Projekt verliert an Verhaltenskonsistenz.

Die dritte Gefahr ist das erhöhte Testvolumen. Jede Copypaste-Instanz erfordert eigene Tests. Wenn die gemeinsame Logik in eine einzige Funktion extrahiert wird, kann sie mit einem Testsatz abgedeckt und wiederverwendet werden. Bei Duplikation muss jede Kopie separat getestet werden — das vervielfacht die CI-Laufzeit und die Größe der zu wartenden Testbasis.

Die vierte Gefahr ist die Illusion von Produktivität. Copypaste erzeugt ein falsches Gefühl von Geschwindigkeit: Der Entwickler fügt schnell den Code ein und sieht, dass der Bildschirm funktioniert. Aber diese „Geschwindigkeit“ verwandelt sich in technische Schulden, die mit Zinsen zurückgezahlt werden müssen, wenn ein Bug im duplizierten Block gefunden wird oder eine Änderung der Geschäftslogik erforderlich ist.

Warum Entwickler Code kopieren

Das Verständnis der Ursachen von Copypaste hilft, eine angemessene Prävention aufzubauen. Meistens kopieren Entwickler Code nicht aus Faulheit, sondern aufgrund von Termindruck, mangelndem Wissen oder einer ungünstigen Architektur.

Der erste Grund sind Deadlines. Wenn ein Bildschirm in zwei Tagen erstellt werden muss und ein ähnlicher Bildschirm bereits existiert, kopiert der Entwickler ihn vollständig und ändert nur das, was der Benutzer sieht. Es bleibt keine Zeit zum Refaktorisieren und Extrahieren einer gemeinsamen Komponente — der Kunde fordert Ergebnisse. Als Ergebnis entsteht ein zweiter Bildschirm mit 80 Prozent gemeinsamem Code, aber einer unabhängigen Änderungshistorie.

Der zweite Grund ist das Fehlen einer einheitlichen Abstraktion. Wenn das Projekt keine gemeinsame Komponente für eine typische Aufgabe (z. B. einen Listenbildschirm mit Pull-to-Refresh) hat, wird jeder Entwickler seine eigene Implementierung schreiben oder die eines Kollegen kopieren. Architekturentscheidungen, die zu Beginn des Projekts getroffen werden, wirken sich direkt auf die Menge zukünftigen Copypastes aus.

Der dritte Grund ist die Angst, funktionierenden Code zu beschädigen. Der Entwickler weiß, dass das bestehende Modul funktioniert. Das Refaktorisieren zur Extraktion von gemeinsamem Code könnte die vorhandene Funktionalität beeinträchtigen. Wenn die Testabdeckung niedrig ist, überwiegt das Risiko einer Beschädigung den wahrgenommenen Nutzen des Refactorings, und der Entwickler wählt den sicheren Weg — das Kopieren.

Beheben Sie die Ursachen, nicht die Symptome. Das Verkürzen von Deadlines und die Einführung von Code-Reviews werden das Problem nicht lösen, wenn dem Projekt eine solide architektonische Grundlage fehlt. Investieren Sie Zeit in die Erstellung wiederverwendbarer Komponenten in frühen Phasen — das ist der einzige Weg, die Versuchung von Copypaste in der Zukunft zu verringern.

Tools zur Duplikaterkennung

Die Erkennung von Copypaste erfolgt durch automatische Analysatoren, die Codefragmente vergleichen und Übereinstimmungen oberhalb eines bestimmten Schwellenwerts identifizieren. Die besten Werkzeuge arbeiten auf AST-Ebene (Abstrakter Syntaxbaum) und ignorieren Formatierung, Variablennamen und Kommentare.

PMD CPD (Copy-Paste Detector) ist das gebräuchlichste Tool für Java, Kotlin, Swift, JavaScript, Python und C++. CPD analysiert die Token des Quellcodes und findet Duplikate, die länger als eine bestimmte Mindestanzahl von Token sind (Standard 100). Die Konfiguration des Schwellenwerts ist der Schlüssel zu qualitativ hochwertigen Ergebnissen: Ein zu niedriger Schwellenwert erzeugt viele Fehlalarme (häufige Muster wie Importe), ein zu hoher Schwellenwert übersieht echte Duplikate.

PMD CPD über Gradle ausführen

plugins {
    id 'pmd'
}

pmd {
    toolVersion = '7.0.0'
    ruleSetFiles = files("pmd-rules.xml")
}

tasks.register('cpd') {
    doLast {
        exec {
            workingDir = projectDir
            commandLine 'cpd',
                '--minimum-tokens', '75',
                '--language', 'kotlin',
                '--files', 'src/main/kotlin',
                '--format', 'xml',
                '--failOnViolation', 'true'
        }
    }
}

SonarQube bettet einen Duplikaterkenner direkt in das Quality Gate ein. Die Regel Duplicated Blocks (%) zeigt den Prozentsatz duplizierten Codes. Ein Schwellenwert von 5 Prozent gilt für kommerzielle Projekte als gesund. Eine Überschreitung blockiert die Promotion in den Release-Branch. SonarQube gruppiert Duplikate zusätzlich nach Typ: exakte Übereinstimmungen und strukturelle Kopien (mit umbenannten Bezeichnern).

Für JavaScript und TypeScript werden Duplikate mit ESLint und dem Plugin eslint-plugin-sonarjs (Regel no-duplicate-string) sowie dem Dienstprogramm jscpd erkannt, das über 150 Sprachen unterstützt. jscpd ist besonders praktisch für Monorepos: Es findet Duplikate zwischen Paketen, nicht nur innerhalb eines einzelnen Moduls.

Strategien zum Refactoring von dupliziertem Code

Das Refactoring von Copypaste läuft auf ein Prinzip hinaus: den gemeinsamen Teil extrahieren und die Unterschiede parametrisieren. Die spezifische Technik hängt vom Umfang der Duplikation und dem Kontext ab.

Der einfachste Fall ist die Duplikation innerhalb einer Klasse (z. B. zwei Methoden mit derselben Logik, aber unterschiedlichen Typen). Die Lösung ist die Verallgemeinerung mit Generics oder die Wiederverwendung einer Methode mit einem Typparameter. Wenn die Duplikation mehrere Klassen umfasst — extrahieren Sie den gemeinsamen Code in eine Utility-Klasse oder Erweiterungsfunktion.

Ein komplexerer Fall ist die Duplikation auf Bildschirm- oder Modulebene. Hier hilft das bloße Extrahieren einer Funktion nicht, weil die UI-Struktur, die Lebenszykluslogik und die Datenbindung alle dupliziert sind. Die Lösung besteht darin, eine gemeinsame Basis-Bildschirmklasse oder eine zusammengesetzte View-Komponente zu erstellen und die Unterschiede über Parameter oder ein Protokoll zu übergeben.

// before - two copies of the same UITableViewController
class UserListController: UITableViewController {
    private let viewModel = UserListViewModel()
    // 40 lines of code
}

class ProductListController: UITableViewController {
    private let viewModel = ProductListViewModel()
    // same 40 lines but with Product instead of User
}

// after - generic base class shared
class ListViewController<T: ListViewModel>: UITableViewController {
    let viewModel: T
    // 40 lines of code - once only

    init(viewModel: T) {
        self.viewModel = viewModel
        super.init(style: .plain)
    }
}

Der komplexeste Fall ist die Duplikation zwischen Microservices oder Bibliotheken. Das Extrahieren von gemeinsamem Code kann zu zirkulären Abhängigkeiten oder ungerechtfertigter Kopplung führen. In solchen Fällen kann Copypaste eine bewusste Entscheidung sein: Zwei Teams pflegen unabhängige Dienste, und eine gemeinsame Bibliothek schafft mehr Probleme, als sie löst. Entscheidend ist, eine solche Entscheidung zu dokumentieren und regelmäßig zu prüfen, ob die Kopien weit genug auseinandergegangen sind, um eine Vereinheitlichung zu rechtfertigen.

Prävention von Copypaste auf Teamebene

Die Prävention von Copypaste ist effektiver als das Refactoring von bereits dupliziertem Code. Die wichtigsten vorbeugenden Maßnahmen liegen in der Organisation des Entwicklungsprozesses, nicht in der Technologie.

Die erste Maßnahme ist das Code-Review mit Fokus auf Duplikation. Die Review-Checkliste sollte den Punkt enthalten: „Enthält dieser PR Code, der bereits im Projekt existiert?“ Wenn der Reviewer Copypaste sieht — blockiert er den Merge, bis die gemeinsame Komponente extrahiert wurde. Diese Anforderung sollte Teil der Definition of Done des Teams sein.

Die zweite Maßnahme ist eine gemeinsame Komponentenbibliothek. Jedes UI-Muster, das auf zwei oder mehr Bildschirmen erscheint, sollte in ein gemeinsames Modul extrahiert werden. Erstellen Sie ein Shared-Modul im Projekt und machen Sie es zum obligatorischen Einstiegspunkt für alle UI-Komponenten. Wenn eine Komponente nicht existiert — wird sie zuerst erstellt und dann auf dem Bildschirm verwendet.

Die dritte Maßnahme ist die Automatisierung in CI/CD. Fügen Sie dem Pipeline einen Schritt zur Prüfung auf duplizierten Code hinzu (PMD CPD, jscpd, SonarQube). Das Überschreiten des Schwellenwerts führt zu einem Build-Fehler. Der Entwickler kann keinen PR mergen, der das Copypaste-Verhältnis über das zulässige Maß erhöht. Dies verschiebt die Verantwortung vom Code-Review zur Automatisierung und stellt sicher, dass kein Duplikat übersehen wird.

Fördern Sie eine Kultur von „eine Implementierung — ein Ort.“ Wenn Sie eine Gelegenheit zur Wiederverwendung sehen — schieben Sie das Refactoring nicht auf später. Jeder Copypaste, der „für später“ zurückgestellt wird, vervielfacht sich und verwandelt sich in unkontrollierbare technische Schulden.