Code-Qualität automatisieren: PHPStan und PHP CS Fixer für Shopware (Teil 4)

Fehler im Code findest du entweder selbst — oder deine Kunden finden sie für dich. Code-Qualität zu automatisieren bedeutet nicht, dass du besser programmieren musst. Es bedeutet, dass Werkzeuge die Arbeit übernehmen, die Menschen unzuverlässig erledigen: jeden Namespace prüfen, jeden Typ kontrollieren, jede Datei auf Stil-Verstöße scannen. Jedes Mal. Ohne Ausnahme.

Warum Code-Qualität kein Luxus ist

Shopware entwickelt sich schnell weiter. Zwischen Minor-Versionen ändern sich Interfaces, Methoden werden deprecated, Parameter-Typen verschärft. Sauberer Code überlebt solche Updates deutlich besser als Code, der „irgendwie funktioniert“.

Ein paar Beispiele aus der Praxis:

• Ein Tippfehler im Namespace — das Plugin lädt nicht, der Shop zeigt eine weiße Seite. Kein Fehler im Browser, kein hilfreicher Hinweis. Nur ein kaputter Shop.
• Ein falscher Parameter-Typ — funktioniert in PHP 8.2, wirft einen TypeError in 8.3. Du merkst es erst beim Shopware-Update.
• Fehlende Null-Checks — der Code läuft monatelang fehlerfrei, bis ein Kunde ein Produkt ohne Hersteller aufruft. Dann knallt es.
• Sicherheitslücken — eine nicht typisierte Methode akzeptiert ungeprüfte Eingaben. Kein Reviewer hat es gesehen, kein Test hat es geprüft.

Code-Qualität ist keine Fleißaufgabe für Perfektionisten. Sie verhindert konkrete Probleme, die dich Zeit und Nerven kosten.

Warum automatisiert statt manuell?

Menschen sind gut darin, Architektur zu bewerten und Logik zu hinterfragen. Sie sind schlecht darin, in 50 Dateien jeden Typ-Hint zu prüfen. Genau dafür gibt es Werkzeuge:

• Automatische Tools prüfen jede Datei, jedes Mal — nicht nur die, die du gerade geändert hast
• Sie sind schneller als jedes manuelle Review
• Sie sind konsistent — kein „Heute bin ich großzügig“
• CI/CD kann das Deployment blockieren, wenn die Qualität nicht stimmt

PHPStan — Fehler finden ohne den Browser zu öffnen

PHPStan ist ein statischer Analyse-Tool für PHP. Es liest deinen Code, ohne ihn auszuführen, und findet dabei Typfehler, fehlende Klassen, falsche Parameter und undefined Variables. Du sparst dir das Klicken durch den Shop, um Fehler zu finden, die ein Tool in Sekunden erkennt.

Installation

ddev exec composer require --dev phpstan/phpstan

Konfiguration

Erstelle eine phpstan.neon im Plugin-Root:

parameters:
    level: 8
    paths:
        - src

PHPStan arbeitet mit Leveln von 0 bis 9. Level 0 prüft nur die gröbsten Fehler — fehlende Klassen, falsche Funktionsaufrufe. Level 9 erzwingt exakte Typisierung bis in generische Collections. Level 8 ist ein guter Standard für Shopware-Plugins: streng genug, um echte Fehler zu finden, ohne dich mit Edge Cases aufzuhalten.

Ausführen

ddev exec vendor/bin/phpstan analyse

Was PHPStan findet — und was du ohne PHPStan erst spät merkst

Ein Beispiel. Du hast diesen Code in deinem Plugin:

public function getProductName(ProductEntity $product): string
{
    return $product->getTranslation('name');
}

PHPStan meldet sofort: Method getTranslation() returns mixed, but string is expected. Ohne PHPStan merkst du das erst, wenn irgendwo im Shop ein TypeError fliegt — vielleicht erst nach Wochen, wenn ein Produkt ohne Übersetzung aufgerufen wird.

PHP CS Fixer — einheitlicher Code-Stil

Code-Stil klingt nach Kosmetik. Ist es nicht. Wenn jeder Entwickler anders einrückt, anders sortiert und anders klammert, wird jeder Git-Diff zum Suchspiel: Was hat sich inhaltlich geändert, was ist nur Formatierung? PHP CS Fixer löst das Problem, indem es einen verbindlichen Stil durchsetzt — automatisch.

Installation

ddev exec composer require --dev friendsofphp/php-cs-fixer

Konfiguration

Erstelle eine .php-cs-fixer.php im Plugin-Root:

<?php

$finder = PhpCsFixer\Finder::create()
    ->in(__DIR__ . '/src');

return (new PhpCsFixer\Config())
    ->setRules([
        '@PER-CS2.0' => true,
        '@Symfony' => true,
        'declare_strict_types' => true,
        'ordered_imports' => true,
    ])
    ->setFinder($finder);

Das Regelset @PER-CS2.0 folgt dem aktuellen PHP-Standard. @Symfony ergänzt Regeln, die in der Symfony-Welt — und damit auch bei Shopware — üblich sind. declare_strict_types erzwingt strikte Typisierung in jeder Datei, ordered_imports sortiert die Use-Statements alphabetisch.

Ausführen

# Nur prüfen (Dry-Run):
ddev exec vendor/bin/php-cs-fixer fix --dry-run --diff

# Automatisch korrigieren:
ddev exec vendor/bin/php-cs-fixer fix

Der Dry-Run zeigt dir, was geändert werden würde, ohne Dateien anzufassen. Wenn alles passt, lässt du den Fixer laufen und er korrigiert automatisch. Danach committen — fertig.

Composer Scripts — alles mit einem Befehl

Zwei Tools, zwei Befehle, die du dir merken musst. Bei drei Tools sind es drei Befehle. Das nervt. Composer Scripts bündeln alles in einen einzigen Aufruf.

Füge folgende Scripts in die composer.json deines Plugins ein:

"scripts": {
    "cs-check": "php-cs-fixer fix --dry-run --diff",
    "cs-fix": "php-cs-fixer fix",
    "phpstan": "phpstan analyse",
    "quality": ["@cs-check", "@phpstan"]
}

Ab jetzt reicht ein einziger Befehl, um Code-Stil und statische Analyse gleichzeitig zu prüfen:

ddev exec composer quality

Wenn cs-check oder phpstan Fehler findet, bricht Composer mit einem Fehlercode ab. Das ist wichtig für den nächsten Schritt.

Pre-Commit-Hooks — automatisch vor jedem Commit prüfen

Tools installieren ist einfach. Sie auch tatsächlich benutzen ist die Herausforderung. Pre-Commit-Hooks lösen das elegant: Ein Script, das automatisch vor jedem git commit läuft. Wenn die Prüfung fehlschlägt, wird der Commit abgelehnt. Kein schlechter Code im Repository — egal wie eilig es ist.

Hook einrichten

Erstelle die Datei .git/hooks/pre-commit:

#!/bin/bash

echo "Pre-Commit: Code-Qualität wird geprüft..."

# Debug-Ausgaben prüfen
if grep -rn "var_dump\|dump(\|dd(" src/; then
    echo "Debug-Ausgaben gefunden! Bitte entfernen."
    exit 1
fi

# PHPStan ausführen
vendor/bin/phpstan analyse
if [ $? -ne 0 ]; then
    echo "PHPStan hat Fehler gefunden."
    exit 1
fi

echo "Alle Prüfungen bestanden."

Dann die Datei ausführbar machen:

chmod +x .git/hooks/pre-commit

Was passiert im Alltag?

Du arbeitest an deinem Plugin, machst deine Änderungen und willst committen. Der Hook läuft automatisch:

• Keine Debug-Ausgaben, PHPStan findet nichts — Commit geht durch
• Ein vergessenes var_dump() — Commit wird abgelehnt, du entfernst es, commitest erneut
• PHPStan meldet einen Typfehler — Commit wird abgelehnt, du korrigierst den Fehler

Das klingt streng. Ist es auch. Aber es verhindert zuverlässig, dass halbfertiger oder fehlerhafter Code ins Repository gelangt.

Composer Audit — Sicherheitslücken in Abhängigkeiten

Dein Plugin-Code kann perfekt sein — wenn eine deiner Abhängigkeiten eine bekannte Sicherheitslücke hat, ist der Shop trotzdem verwundbar. Composer bringt dafür ein eingebautes Werkzeug mit:

ddev exec composer audit

Der Befehl prüft alle installierten Pakete gegen die GitHub Advisory Database. Wenn eine bekannte Schwachstelle existiert, zeigt er Paketname, betroffene Version und eine Beschreibung des Problems.

Mach dir eine Gewohnheit daraus, composer audit vor jedem Release auszuführen. Es dauert Sekunden und kann dich vor ernsthaften Problemen bewahren.

Zusammenfassung: Die Qualitäts-Checkliste

Vier Werkzeuge, ein Ziel: Fehler finden, bevor sie im Shop landen.

Tool	Was es prüft	Wann ausführen
PHPStan	Typfehler, fehlende Klassen, falsche Parameter	bei jedem Commit
PHP CS Fixer	Code-Stil, Formatierung, strict_types	bei jedem Commit
Composer Audit	Sicherheitslücken in Abhängigkeiten	vor jedem Release
Pre-Commit-Hook	Debug-Code, PHPStan-Fehler	automatisch bei jedem Commit

Der Aufwand für die Einrichtung liegt bei unter einer Stunde. Die Zeit, die du dir damit sparst — in Debugging, in Hotfixes, in peinlichen Kundengesprächen — ist ein Vielfaches davon.