Duplicate Code (auf Deutsch: "doppelter Code" oder "Code-Duplizierung") bezeichnet das mehrfache Vorhandensein identischer oder sehr ähnlicher Codeabschnitte in einem Programm. Es wird als schlechte Praxis angesehen, weil es zu Problemen in der Wartbarkeit, Lesbarkeit und Fehleranfälligkeit des Codes führen kann.

Typen von Duplicate Code

1. Exakter Duplikat: Der Code ist vollständig identisch. Dies tritt häufig auf, wenn ein Entwickler denselben Code kopiert und an mehreren Stellen einfügt.

Beispiel:

def calculate_area_circle(radius):
    return 3.14 * radius * radius

def calculate_area_sphere(radius):
    return 3.14 * radius * radius  # Identischer Code

2. Strukturelle Duplikate: Der Code ist nicht exakt gleich, aber in seiner Struktur und Funktionalität ähnlich. Lediglich Variablen oder Namen wurden geändert.

Beispiel:

def calculate_area_circle(radius):
    return 3.14 * radius * radius

def calculate_area_square(side):
    return side * side  # Ähnlich strukturiert

3. Logische Duplikate: Der Code macht funktional das Gleiche, sieht aber syntaktisch unterschiedlich aus.

Beispiel:

def calculate_area_circle(radius):
    return 3.14 * radius ** 2

def calculate_area_circle_alt(radius):
    return 3.14 * radius * radius  # Funktional gleich, aber anderer Stil

Nachteile von Duplicate Code

1. Wartungsprobleme: Änderungen an einer Stelle erfordern, dass alle Duplikate angepasst werden müssen, was Fehleranfälligkeit erhöht.
2. Erhöhte Codegröße: Mehr Code bedeutet mehr Komplexität und potenziell längere Entwicklungszeiten.
3. Inkonsistenzrisiko: Wenn nicht alle Duplikate korrekt aktualisiert werden, kann es zu unerwarteten Bugs kommen.

Wie kann man Duplicate Code vermeiden?

1. Refactoring: Ähnlichen oder identischen Code in eine gemeinsame Funktion oder Methode auslagern.

Beispiel:

def calculate_area(shape, dimension):
    if shape == 'circle':
        return 3.14 * dimension * dimension
    elif shape == 'square':
        return dimension * dimension

2. Modularisierung: Funktionen und Klassen verwenden, um Wiederholungen zu reduzieren.

3. DRY-Prinzip anwenden: "Don't Repeat Yourself" – Entwickle so, dass keine Information oder Logik doppelt implementiert wird.

4. Tools verwenden: Tools wie SonarQube oder CodeClimate können Duplicate Code automatisch erkennen.

Duplicate Code zu reduzieren, verbessert die Codequalität, erleichtert die Wartung und minimiert das Risiko von Fehlern in der Software.

Renovate ist ein Open-Source-Tool, das den Prozess der Abhängigkeitsverwaltung automatisiert. Es überwacht kontinuierlich die Abhängigkeiten eines Softwareprojekts (wie npm, Maven, Docker) und erstellt Pull Requests, um veraltete Pakete zu aktualisieren. So bleibt das Projekt auf dem neuesten Stand und sicher.

Hauptfunktionen umfassen:

1. Automatische Abhängigkeits-Updates: Renovate erkennt veraltete oder unsichere Abhängigkeiten und erstellt Pull Requests mit den Updates.
2. Anpassbare Konfiguration: Man kann konfigurieren, wann und wie Updates durchgeführt werden sollen, z.B. nach Zeitplänen oder mit automatischem Zusammenführen.
3. Unterstützung für Monorepos: Ideal für große Projekte oder Teams mit mehreren Paketen.
4. Sicherheitswarnungen: Renovate integriert Datenbanken zu Sicherheitslücken und informiert über Probleme bei Abhängigkeiten.

Es hilft, technische Schulden zu reduzieren und Sicherheitslücken durch Drittabhängigkeiten zu minimieren, was es besonders bei GitHub, GitLab und Bitbucket beliebt macht.

Composer Unused ist ein Tool für PHP-Projekte, das verwendet wird, um nicht genutzte Abhängigkeiten in der composer.json-Datei zu finden. Es hilft Entwicklern, ihre Abhängigkeitsliste zu bereinigen und sicherzustellen, dass keine überflüssigen Bibliotheken in einem Projekt verbleiben, die den Code unnötig aufblähen.

Funktionen:

• Scannen nach ungenutzten Abhängigkeiten: Composer Unused durchsucht den Quellcode eines Projekts und vergleicht die tatsächlich verwendeten Klassen und Funktionen mit den in der composer.json definierten Abhängigkeiten.
• Auflisten ungenutzter Pakete: Es listet alle Pakete auf, die in der composer.json als Abhängigkeiten definiert sind, aber im Projektcode nicht verwendet werden.
• Bereinigung der composer.json: Mit dem Tool können nicht verwendete Abhängigkeiten identifiziert und entfernt werden, um das Projekt schlanker und effizienter zu machen.

Verwendung:

Composer Unused wird in der Regel in PHP-Projekten eingesetzt, um sicherzustellen, dass nur tatsächlich genutzte Abhängigkeiten vorhanden sind. Dies kann zu einer besseren Performance und einem geringeren Wartungsaufwand führen, da unnötige Bibliotheken entfernt werden.

Ein Monorepo (kurz für "Monorepository") ist ein einziges Versionsverwaltungssystem (z.B. ein Git-Repository), in dem der Code für mehrere Projekte oder Dienste gespeichert wird. Im Gegensatz zu einem "Multirepo", bei dem jedes Projekt oder jeder Dienst in einem eigenen Repository verwaltet wird, umfasst ein Monorepo alle Projekte in einem einzigen Repository.

Merkmale und Vorteile eines Monorepos:

1. Gemeinsame Codebasis: Alle Projekte teilen sich eine einzige Codebasis, was die Zusammenarbeit zwischen verschiedenen Teams erleichtert. Änderungen, die sich auf mehrere Projekte auswirken, können gleichzeitig gemacht und getestet werden.

2. Einfache Code-Synchronisation: Da alle Projekte denselben Versionsverlauf nutzen, ist es einfacher, gemeinsame Bibliotheken oder Abhängigkeiten konsistent zu halten.

3. Wiederverwendbarkeit: In einem Monorepo ist es einfacher, wiederverwendbare Module oder Bibliotheken zwischen Projekten zu teilen.

4. Integrierte Versionskontrolle: Es gibt eine zentrale Versionskontrolle, sodass Änderungen in einem Projekt sofort auch andere Projekte betreffen können.

5. Skalierbarkeit: Große Unternehmen wie Google oder Facebook nutzen Monorepos, um Tausende von Projekten und Entwicklern unter einem einzigen Repository zu organisieren.

Nachteile eines Monorepos:

• Komplexität des Builds: Der Build-Prozess kann komplizierter werden, da er die Abhängigkeiten zwischen vielen verschiedenen Projekten berücksichtigen muss.

• Leistungsprobleme: Bei sehr großen Repositories können Versionskontrollsysteme wie Git langsamer arbeiten, da sie mit der Größe des Repos kämpfen.

Ein Monorepo ist besonders sinnvoll, wenn verschiedene Projekte eng miteinander verzahnt sind und es oft zu Überschneidungen oder Abhängigkeiten kommt.

Closed Source (auch Proprietary Software genannt) bezeichnet Software, deren Quellcode nicht öffentlich zugänglich ist und nur vom Eigentümer bzw. Entwickler eingesehen, geändert und weitergegeben werden kann. Im Gegensatz zu Open Source-Software, bei der der Quellcode offengelegt wird, bleibt der Quellcode bei Closed Source streng vertraulich.

Eigenschaften von Closed Source Software:

1. Geschützter Quellcode: Der Quellcode der Software ist nicht für die Öffentlichkeit einsehbar. Nur der Entwickler oder das Unternehmen, das die Software besitzt, hat Zugriff darauf. Dadurch wird verhindert, dass Dritte die Funktionsweise der Software nachvollziehen oder Änderungen daran vornehmen können.

2. Lizenzrechtliche Beschränkungen: Closed Source Software wird häufig unter restriktiven Lizenzen vertrieben, die die Nutzung, Modifikation und Weitergabe streng regulieren. Dies bedeutet, dass Nutzer die Software nur innerhalb der durch die Lizenz erlaubten Rahmenbedingungen verwenden dürfen.

3. Zugangsbeschränkung: Nur autorisierte Entwickler oder Teams innerhalb des Unternehmens, das die Software besitzt, haben die Berechtigung, den Code zu modifizieren oder neue Funktionen hinzuzufügen.

4. Kommerzielle Nutzung: Closed Source Software wird oft als kommerzielles Produkt angeboten. Nutzer müssen in der Regel eine Lizenz erwerben oder Abonnements abschließen, um die Software zu nutzen. Typische Beispiele sind Anwendungen wie Microsoft Office oder Adobe Photoshop.

5. Geringere Transparenz: Nutzer haben keine Möglichkeit, den Quellcode auf Sicherheitslücken oder versteckte Funktionen (z. B. Backdoors) zu überprüfen. Dies kann ein Risiko darstellen, wenn Vertrauen in die Software-Sicherheit ein kritischer Faktor ist.

Vorteile von Closed Source Software:

1. Schutz des geistigen Eigentums: Unternehmen schützen ihren Quellcode, um ihre Geschäftsgeheimnisse, Algorithmen oder speziellen Implementierungen vor Nachahmung zu bewahren.
2. Stabilität und Support: Da der Entwickler oder das Unternehmen die Kontrolle über den Code hat, kann die Qualitätssicherung strenger durchgeführt werden. Außerdem bieten viele Anbieter von Closed Source Software umfassenden technischen Support und regelmäßige Updates.
3. Geringeres Risiko von Code-Manipulation: Da Dritte keinen Zugriff auf den Quellcode haben, ist die Gefahr geringer, dass unerwünschte Änderungen oder Sicherheitslücken von außen eingefügt werden.

Nachteile von Closed Source Software:

1. Keine Anpassungsmöglichkeiten: Nutzer können den Code nicht an ihre eigenen Bedürfnisse anpassen oder Fehler eigenständig beheben, da der Zugriff auf den Quellcode fehlt.
2. Kosten: Closed Source Software ist oft mit Lizenzgebühren oder Abo-Kosten verbunden, die insbesondere für Unternehmen teuer sein können.
3. Abhängigkeit vom Hersteller: Nutzer sind vollständig auf den Hersteller angewiesen, um Fehler zu beheben, Sicherheitslücken zu schließen oder neue Funktionen bereitzustellen.

Beispiele für Closed Source Software:

Einige bekannte Closed Source Programme und Plattformen sind:

• Microsoft Windows: Das Betriebssystem ist Closed Source, und der Quellcode ist Eigentum von Microsoft.
• Adobe Creative Suite: Photoshop, Illustrator und andere Adobe-Produkte sind proprietäre Software.
• Apple iOS und macOS: Auch die Betriebssysteme von Apple sind Closed Source, was bedeutet, dass Nutzer nur die offiziell bereitgestellten Versionen verwenden können.
• Proprietäre Datenbanken wie Oracle Database: Diese sind Closed Source und bieten keine Möglichkeit, den Quellcode einzusehen oder anzupassen.

Unterschied zwischen Open Source und Closed Source:

• Open Source: Der Quellcode ist frei verfügbar, und jeder kann ihn einsehen, ändern und weitergeben (unter bestimmten Bedingungen, abhängig von der Lizenz).
• Closed Source: Der Quellcode ist nicht zugänglich, und die Nutzung und Verteilung der Software ist stark eingeschränkt.

Zusammenfassung:

Closed Source Software ist proprietäre Software, deren Quellcode nicht öffentlich zugänglich ist. Sie wird in der Regel von Unternehmen entwickelt und kommerziell angeboten. Nutzer können die Software verwenden, aber weder den Quellcode einsehen noch modifizieren. Dies bietet Vorteile in Bezug auf den Schutz des geistigen Eigentums und die Qualitätssicherung, geht jedoch zulasten der Flexibilität und Transparenz.

Quellcode (auch Quelltext oder Code genannt) ist die für Menschen lesbare Anweisungssammlung, die von Programmierern geschrieben wird, um die Funktionsweise eines Programms zu definieren. Er besteht aus einer Abfolge von Befehlen und Anweisungen, die in einer bestimmten Programmiersprache geschrieben sind, wie z. B. Java, Python, C++, JavaScript und vielen anderen.

Merkmale von Quellcode:

1. Menschlich lesbar: Quellcode wird von Entwicklern geschrieben und ist so gestaltet, dass er für Menschen lesbar und verständlich ist. Oft wird er mit Kommentaren und gut strukturierten Anweisungen versehen, um seine Logik nachvollziehbar zu machen.

2. Programmiersprachen: Quellcode wird in verschiedenen Programmiersprachen geschrieben, die unterschiedliche Syntax und Regeln haben. Jede Programmiersprache hat spezifische Zwecke und Anwendungsbereiche.

3. Maschinenunabhängig: Quellcode ist in seiner Rohform nicht direkt ausführbar. Er muss in eine maschinenlesbare Form (Maschinencode) übersetzt werden, damit der Computer ihn verstehen und ausführen kann. Diese Übersetzung erfolgt durch einen Compiler oder Interpreter.

4. Bearbeitung und Wartung: Entwickler können Quellcode bearbeiten, erweitern und verbessern, um neue Funktionen hinzuzufügen oder Fehler zu beheben. Der Quellcode bildet die Grundlage für alle weiteren Entwicklungs- und Wartungsarbeiten eines Softwareprojekts.

Beispiel:

Ein einfaches Beispiel in Python, das zeigt, wie Quellcode aussieht:

# Ein einfacher Python-Quellcode, der "Hello, World!" ausgibt
print("Hello, World!")

Dieser Code besteht aus einer einzigen Anweisung (print), die den Text "Hello, World!" auf dem Bildschirm ausgibt. Obwohl es nur eine Zeile ist, muss der Interpreter (in diesem Fall der Python-Interpreter) den Quellcode lesen, verstehen und in Maschinencode umwandeln, damit der Computer die Anweisung ausführen kann.

Verwendung und Bedeutung:

Quellcode ist das Herzstück jeder Softwareentwicklung. Er definiert die Logik, das Verhalten und die Funktionalität einer Software. Einige wichtige Aspekte des Quellcodes:

• Programmsteuerung: Der Quellcode steuert die Ausführung des Programms und enthält Anweisungen für den Ablauf, Berechnungen und Datenverarbeitungen.
• Zusammenarbeit: In Softwareprojekten arbeiten oft mehrere Entwickler zusammen. Der Quellcode wird daher in Versionierungssystemen wie Git gespeichert und verwaltet, um die Zusammenarbeit zu erleichtern.
• Offen oder geschlossen: Manche Softwareprojekte veröffentlichen ihren Quellcode als Open Source, damit andere Entwickler ihn einsehen, bearbeiten und nutzen können. Bei proprietärer Software bleibt der Quellcode oft geheim (Closed Source).

Zusammenfassung:

Quellcode ist der grundlegende, menschenlesbare Text, aus dem Softwareprogramme bestehen. Er wird von Entwicklern geschrieben, um die Funktionalität eines Programms zu definieren und muss von einem Compiler oder Interpreter in Maschinencode umgewandelt werden, bevor ein Computer ihn ausführen kann.

CaptainHook ist ein Git-Hook-Manager für PHP, der es Entwicklern ermöglicht, automatisierte Aufgaben im Zusammenhang mit Git-Repositories durchzuführen. Es erleichtert das Einrichten und Verwalten von Git-Hooks, also Skripten, die zu bestimmten Zeitpunkten im Git-Workflow automatisch ausgeführt werden (z. B. vor dem Committen oder Pushen von Code). Dies ist besonders nützlich, um Codestandards durchzusetzen, Tests laufen zu lassen, Commit-Nachrichten zu überprüfen oder fehlerhaften Code zu verhindern.

CaptainHook lässt sich einfach über Composer in Projekte integrieren und bietet Flexibilität, um benutzerdefinierte Hooks und Plugins zu erstellen. Es unterstützt verschiedene PHP-Versionen, wobei die neueste Version PHP 8.0 erfordert​.

Breaking Changes (auf Deutsch etwa "brechende Änderungen") sind Änderungen an einer Software, einem API oder einer Bibliothek, die dazu führen, dass bestehender Code oder Abhängigkeiten nicht mehr wie erwartet funktionieren. Diese Änderungen brechen also die Abwärtskompatibilität, wodurch ältere Versionen des Codes, die auf die vorherige Version angewiesen sind, nicht mehr ohne Anpassungen laufen.

Typische Beispiele für Breaking Changes sind:

1. Änderung oder Entfernung von Funktionen: Eine Funktion, die zuvor vorhanden war, wird entweder entfernt oder verhält sich anders.
2. Änderung von Schnittstellen: Wenn die Parameter einer Methode oder API geändert werden, kann bestehender Code, der diese Methode nutzt, Fehler werfen.
3. Änderungen in der Datenstruktur: Änderungen an Datenformaten oder Datenmodellen können dazu führen, dass bestehender Code inkompatibel wird.
4. Änderung des Verhaltens: Wenn das Verhalten eines Codes sich grundlegend ändert (z.B. von synchron zu asynchron), erfordert dies oft Anpassungen im aufrufenden Code.

Um mit Breaking Changes umzugehen, müssen Entwickler ihre Software oft aktualisieren oder anpassen, um mit den neuen Versionen kompatibel zu bleiben. In der Regel werden Breaking Changes in Major-Versionen einer Software veröffentlicht, um die Nutzer auf die Inkompatibilitäten aufmerksam zu machen.

Conventional Commits sind ein einfacher Standard für Commit-Nachrichten in Git, der ein konsistentes Format für alle Commits vorschlägt. Dies erleichtert die Automatisierung von Aufgaben wie der Versionskontrolle (Versioning), der Changelog-Erstellung und der Rückverfolgung von Änderungen.

Das Format der Conventional Commits besteht aus einer speziellen Struktur der Commit-Nachricht, die typischerweise folgendermaßen aussieht:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Komponenten eines Conventional Commits:

1. Type (Pflichtfeld): Beschreibt die Art der Änderung im Commit. Es gibt standardisierte Typen:

   • feat: Eine neue Funktion oder ein Feature.
   • fix: Eine Fehlerbehebung.
   • docs: Änderungen an der Dokumentation.
   • style: Änderungen am Code-Stil (z. B. Formatierung), die aber die Logik nicht beeinflussen.
   • refactor: Änderungen am Code, die weder Fehler beheben noch Funktionen hinzufügen, aber den Code verbessern.
   • test: Hinzufügen oder Ändern von Tests.
   • chore: Änderungen am Build-Prozess oder an Hilfswerkzeugen, die keinen Einfluss auf den Quellcode haben.

2. Scope (optional): Beschreibt den betroffenen Teil des Codes oder der Anwendung, z. B. ein Modul oder eine Komponente.

   • Beispiel: fix(auth): corrected password hashing algorithm

3. Description (Pflichtfeld): Eine kurze, prägnante Beschreibung der Änderung. Diese sollte in der Gegenwartsform formuliert sein (z. B. „add feature“ statt „added feature“).

4. Body (optional): Eine ausführlichere Beschreibung der Änderung. Dies kann genutzt werden, um mehr Kontext oder technische Details anzugeben.

5. Footer (optional): Hier können Hinweise zu Breaking Changes oder Referenzen zu Issues oder Tickets stehen.

   • Beispiel: BREAKING CHANGE: remove deprecated authentication method

Beispiel einer Commit-Nachricht im Conventional Commit-Format:

feat(parser): add ability to parse arrays

The parser now supports parsing arrays into lists.
This allows arrays to be passed as arguments to methods.

BREAKING CHANGE: Arrays are now parsed differently

Vorteile von Conventional Commits:

• Konsistenz: Ein einheitliches Format für Commit-Nachrichten erleichtert es, den Projektverlauf zu verstehen.
• Automatisierung: Tools können automatisch Versionen erzeugen, Changelogs erstellen und sogar Veröffentlichungen basierend auf Commit-Nachrichten vornehmen.
• Rückverfolgbarkeit: Es wird leichter, den Zweck einer Änderung nachzuvollziehen, insbesondere bei Fehlerbehebungen oder neuen Funktionen.

Conventional Commits sind besonders in Projekten hilfreich, die SemVer (Semantic Versioning) verwenden, da sie es ermöglichen, automatisch neue Versionen basierend auf Commit-Typen zu erstellen.

In der Softwareentwicklung bezeichnet eine Pipeline eine automatisierte Abfolge von Schritten, die ausgeführt werden, um Code von der Entwicklungsphase bis zur Bereitstellung in einer Produktionsumgebung zu bringen. Diese Pipelines sind ein zentraler Bestandteil von Continuous Integration (CI) und Continuous Deployment (CD), zwei Praktiken, die darauf abzielen, Software schneller, zuverlässiger und konsistenter zu entwickeln und bereitzustellen.

Hauptkomponenten einer Softwareentwicklungs-Pipeline:

1. Quellcode-Verwaltung (Source Control):

   • Der Prozess beginnt normalerweise, wenn Entwickler neuen Code in ein Versionskontrollsystem (z. B. Git) einchecken. Dieser Code-Commit löst oft automatisch den nächsten Schritt in der Pipeline aus.

2. Build-Prozess:

   • Der Code wird automatisch kompiliert und gebaut. Dabei wird der Quellcode in ausführbare Dateien, Bibliotheken oder andere artefakte umgewandelt. In diesem Schritt werden auch Abhängigkeiten aufgelöst und Pakete erstellt.

3. Automatisierte Tests:

   • Nach dem Build-Prozess wird der Code automatisch getestet. Dazu gehören Unit-Tests, Integrationstests, Funktionstests und manchmal auch UI-Tests. Diese Tests stellen sicher, dass neue Änderungen keine bestehenden Funktionen beschädigen und dass der Code den Anforderungen entspricht.

4. Bereitstellung (Deployment):

   • Wenn die Tests erfolgreich sind, wird der Code automatisch in eine bestimmte Umgebung bereitgestellt. Dies kann eine Staging-Umgebung sein, in der weitere manuelle oder automatisierte Tests stattfinden, oder es kann direkt in die Produktionsumgebung gehen.

5. Monitoring und Feedback:

   • Nach der Bereitstellung wird die Anwendung überwacht, um sicherzustellen, dass sie wie erwartet funktioniert. Fehler und Performance-Probleme können schnell identifiziert und behoben werden. Feedback-Schleifen helfen den Entwicklern, Probleme frühzeitig zu erkennen und kontinuierlich Verbesserungen vorzunehmen.

Vorteile einer Pipeline in der Softwareentwicklung:

• Automatisierung: Reduziert manuelle Eingriffe und minimiert die Fehleranfälligkeit.
• Schnellere Entwicklung: Änderungen können schneller und häufiger in die Produktion überführt werden.
• Konsistenz: Durch festgelegte Prozesse wird sichergestellt, dass alle Änderungen denselben Qualitätsanforderungen genügen.
• Kontinuierliche Integration und Bereitstellung: Macht es möglich, Code kontinuierlich zu integrieren und schnell in die Produktion zu bringen, was die Reaktionszeit auf Fehler und neue Anforderungen verkürzt.

Diese Pipelines sind somit entscheidend für die moderne Softwareentwicklung, insbesondere in Umgebungen, die auf agile Methoden und DevOps-Praktiken setzen.