Rector PHP: Die 10 wichtigsten Fragen zur automatisierten Code-Modernisierung

Ihr steht vor einem Berg von Legacy-Code und fragt euch, wie ihr den effizient auf PHP 8.4 bringen sollt? Bei unserem letzten Symfony-Upgrade haben wir genau diese Herausforderung gemeistert – mit Rector PHP. Das Tool hat uns Wochen an manueller Arbeit erspart und dabei über 500 Dateien automatisch modernisiert. Hier findet ihr die Antworten auf die wichtigsten Fragen, die uns Developer und Entscheider immer wieder stellen.

1. Was ist Rector PHP und wofür braucht ihr es wirklich?

Rector PHP ist kein simpler Code-Formatter – es ist ein intelligentes AST (Abstract Syntax Tree) Tool, das PHP-Code versteht und transformiert. Stellt euch vor, ihr müsstet in 300 Dateien alle DocBlock-Annotations durch PHP 8 Attributes ersetzen. Manuell? Drei Wochen Arbeit. Mit Rector? 30 Sekunden.

Das Tool analysiert euren Code auf semantischer Ebene und wendet Transformationsregeln an. Bei unseren Projekten setzen wir Rector hauptsächlich für drei Szenarien ein:

PHP-Version-Upgrades: Von PHP 7.4 auf 8.3 in einem Durchgang
Framework-Migrationen: Symfony 5 auf 6, Laravel 9 auf 11
Code-Quality-Verbesserungen: Type-Hints, Return-Types, moderne Patterns

Der echte Mehrwert zeigt sich in der Praxis: Ein Kunde mit einer 8 Jahre alten Symfony-Applikation konnte durch Rector die Modernisierung in 3 Tagen abschließen – geplant waren ursprünglich 3 Monate.

2. Wie installiert ihr Rector in eurem bestehenden PHP-Projekt?

Die Installation ist bewusst simpel gehalten. Ihr benötigt nur Composer:

composer require rector/rector --dev
vendor/bin/rector init

Der init-Befehl erstellt automatisch eine rector.php Konfigurationsdatei. Hier ein praxiserprobtes Setup für Symfony-Projekte:

use RectorConfigRectorConfig;
use RectorSetValueObjectLevelSetList;
use RectorSymfonySetSymfonySetList;

return static function (RectorConfig $rectorConfig): void {
    $rectorConfig->paths([
        __DIR__ . '/src',
        __DIR__ . '/tests'
    ]);

    $rectorConfig->sets([
        LevelSetList::UP_TO_PHP_82,
        SymfonySetList::SYMFONY_64,
    ]);
};

Pro-Tipp aus der Praxis: Startet klein! Wendet Rector erst auf einen einzelnen Ordner an, bevor ihr das ganze Projekt transformiert.

3. Welche PHP-Versionen werden von Rector unterstützt?

Rector selbst benötigt mindestens PHP 7.2 zum Ausführen, kann aber Code von PHP 5.3 bis PHP 8.4 bearbeiten. Das ist der Clou: Ihr könnt auf einem alten Server mit PHP 7.2 Rector laufen lassen und euren Code für PHP 8.4 vorbereiten.

Unsere Erfahrung zeigt: Die besten Ergebnisse erzielt ihr mit typisiertem, objektorientiertem Code. Proceduraler Spaghetti-Code wird auch modernisiert, aber die Transformationen sind limitierter.

Die unterstützten Upgrade-Pfade:

PHP 5.3 → 5.4 → 5.5 → 5.6 → 7.0 → 7.1 → 7.2 → 7.3 → 7.4 → 8.0 → 8.1 → 8.2 → 8.3 → 8.4

Jeder Schritt bringt spezifische Rules mit. Aktuell gibt es 39 Rules nur für den Sprung von PHP 7.4 auf 8.x.

4. Kann Rector auch Legacy-Code (PHP 5.x) modernisieren?

Absolut! Wir haben schon Projekte von PHP 5.3 auf PHP 8.2 gebracht. Der Trick: Ihr müsst schrittweise vorgehen. Rector transformiert dabei:

// PHP 5.3 Code
class UserService {
    /**
     * @var EntityManager
     */
    private $entityManager;

    /**
     * @param array $data
     * @return User|null
     */
    public function createUser($data) {
        // ...
    }
}

// Nach Rector (PHP 8.2)
class UserService {
    private EntityManager $entityManager;

    public function createUser(array $data): ?User {
        // ...
    }
}

Wichtig aus unserer Erfahrung: Bei sehr altem Code empfehlen wir einen zweistufigen Prozess. Erst auf PHP 7.4, dann auf 8.x. Das macht die Fehlersuche einfacher.

5. Wie lange dauert eine komplette Code-Migration mit Rector?

Die Antwort hängt von drei Faktoren ab:

Codebasis-Größe: 10.000 Zeilen oder 1 Million?
Code-Qualität: Sauberer OOP-Code oder Spaghetti?
Zielversion: Ein Major-Version-Sprung oder mehrere?

Aus unserer über 15-jährigen Erfahrung in der Softwarequalität können wir folgende Richtwerte geben:

Kleines Projekt (< 50.000 LOC): 1-3 Tage
Mittleres Projekt (50.000 – 200.000 LOC): 1-2 Wochen
Enterprise-Anwendung (> 200.000 LOC): 4-8 Wochen

Der eigentliche Rector-Durchlauf dauert nur Minuten bis Stunden. Die Zeit geht für Testing, manuelle Anpassungen und Edge-Cases drauf.

6. Was ist der Unterschied zwischen Rector und anderen Code-Formattern?

PHP CS Fixer, PHPStan, Psalm – alles tolle Tools. Aber Rector spielt in einer anderen Liga:

PHP CS Fixer: Formatiert Code (Leerzeichen, Klammern)
PHPStan/Psalm: Analysiert und findet Fehler
Rector: Transformiert und modernisiert Code strukturell

// PHP CS Fixer würde nur formatieren:
if($user!=null){return$user->getName();}
// Zu:
if ($user != null) {
    return $user->getName();
}

// Rector transformiert zusätzlich:
if ($user instanceof User) {
    return $user->getName();
}

Rector versteht den semantischen Kontext. Es weiß, dass $user ein User-Objekt sein sollte und passt den Check entsprechend an.

7. Könnt ihr eigene Rector-Rules schreiben?

Ja, und das ist einer der mächtigsten Features! Wenn ihr projektspezifische Patterns habt, schreibt ihr eigene Rules. Hier ein Beispiel aus einem unserer Projekte:

use RectorCoreRectorAbstractRector;
use PhpParserNode;

class ReplaceOldServiceCallsRector extends AbstractRector
{
    public function getNodeTypes(): array
    {
        return [NodeExprMethodCall::class];
    }

    public function refactor(Node $node): ?Node
    {
        if (!$this->isName($node->name, 'oldMethod')) {
            return null;
        }

        $node->name = new NodeIdentifier('newMethod');
        return $node;
    }
}

Wir nutzen Custom Rules hauptsächlich für:

Firmenspezifische Coding-Standards
Migration eigener Frameworks
Deprecation-Handling in internen Libraries

8. Wie testet ihr Rector-Änderungen sicher (Dry-Run)?

Goldene Regel: Niemals Rector ohne --dry-run auf unversioniertem Code ausführen!

# Erst analysieren
vendor/bin/rector process --dry-run

# Output prüfen
[OK] 168 files would be changed

# Dann ausführen
vendor/bin/rector process

# Immer: Git-Diff prüfen
git diff

Unser bewährter Workflow:

Feature-Branch erstellen
Rector mit --dry-run testen
Schrittweise einzelne Ordner bearbeiten
Nach jedem Schritt: PHPUnit-Tests laufen lassen
Code-Review im Team
Merge nur nach grüner CI-Pipeline

Pro-Tipp: Nutzt --debug für detaillierte Einblicke, welche Rules was ändern.

9. Funktioniert Rector mit Symfony, Laravel und anderen Frameworks?

Rector hat dedizierte Rule-Sets für alle großen Frameworks:

Symfony: Von 2.8 bis 7.0
Laravel: Von 5.8 bis 11.0
Doctrine: ORM 2.x zu 3.x
PHPUnit: Von 6.0 bis 10.0
TYPO3: Core und Extension-Upgrades

Ein Symfony-Upgrade-Beispiel aus unserer Praxis:

// rector.php
$rectorConfig->sets([
    SymfonySetList::SYMFONY_60,
    SymfonySetList::SYMFONY_61,
    SymfonySetList::SYMFONY_62,
    SymfonySetList::SYMFONY_63,
    SymfonySetList::SYMFONY_64,
]);

Das Geniale: Rector kennt die Breaking Changes jeder Framework-Version und passt euren Code automatisch an. Annotations zu Attributes, Service-Definitionen, Routing – alles wird transformiert.

10. Was kostet Rector und gibt es Enterprise-Support?

Rector selbst ist Open Source und kostenlos (MIT-Lizenz). Ihr könnt es sofort in euren Projekten einsetzen.

Für Unternehmen gibt es verschiedene Support-Optionen:

Community-Support: GitHub Issues, kostenlos
Rector Pro: Cloud-Version mit Web-UI (ab $39/Monat)
Enterprise-Support: Individuelle Betreuung durch das Rector-Team

Aus unserer Beratungspraxis: Die meisten Teams kommen mit der Open-Source-Version bestens zurecht. Enterprise-Support lohnt sich bei kritischen Migrationen mit strikten Deadlines.

Unser Fazit nach über 15 Jahren Erfahrung

Rector PHP ist kein Nice-to-have – es ist ein Game-Changer für moderne PHP-Entwicklung. In unseren Remote-Consulting-Projekten setzen wir es standardmäßig ein. Die Zeitersparnis ist enorm, die Code-Qualität steigt messbar.

Ihr wollt Rector in eurem Projekt einsetzen und braucht Unterstützung? Mit unserer Expertise in Softwarequalität und Open-Source-Technologien begleiten wir euch gerne. Keine Hochglanz-Präsentationen, sondern hands-on Unterstützung von Entwicklern für Entwickler.

Kontakt aufnehmen ist einfach: Schreibt Roland direkt an roland@nevercodealone.de

Wir zeigen euch, wie ihr Rector optimal einsetzt, helfen bei komplexen Migrationen und schulen euer Team. Remote, effizient und auf Augenhöhe.

Never Code Alone PHP Software-Qualität Tests Webdevelopment