Typsicherheit heute mit PHPStan und Psalm

Im Review wirkt alles sauber, und kurz später taucht ein Typfehler an einer Stelle auf, die niemand erwartet hat.

Nach den letzten Beiträgen ist deshalb die wichtigste praktische Frage klar. Wie arbeite ich heute typsicher in PHP, wenn native Generics noch nicht umfassend verfügbar sind?

Meine kurze Antwort lautet: Mit konsequenter statischer Analyse.

Ich setze in Projekten dafür vor allem auf PHPStan und Psalm.

Warum statische Analyse für mich kein Nice-to-have ist

Ohne statische Analyse sehe ich viele Typfehler erst spät. Dann tauchen sie im Review, im Test oder im schlechtesten Fall erst im Betrieb auf.

Mit guter Analyse verschiebe ich diese Fehler nach vorne. Ich bekomme schnelleres Feedback, klarere Verträge und stabilere Refactorings.

Genau das brauche ich in Teams, die regelmäßig liefern.

Was PHPStan und Psalm besonders wertvoll macht

Beide Tools können generische Typbeziehungen über PHPDoc verstehen. Damit lassen sich viele Vorteile von Generics schon heute praktisch nutzen.

Wichtige Bausteine sind für mich:

@template für Typvariablen,
@extends und @implements für Vererbung mit Typbindung,
Type-Bounds wie @template T of Entity,
class-string<T> für saubere Factory- und Repository-Schnittstellen.

Das ist kein Ersatz für Sprachfeatures, aber ein sehr wirksamer Standard für produktive Codebasen.

Ein kompaktes Beispiel

/**
 * @template T of object
 */
interface ReadRepository
{
    /**
     * @param class-string<T> $type
     * @return T|null
     */
    public function find(string $type, string $id): ?object;
}
 
/**
 * @implements ReadRepository<User>
 */
final class UserRepository implements ReadRepository
{
    public function find(string $type, string $id): ?object
    {
        // ...
        return null;
    }
}

Damit wird für das Team transparent, welche Typen ein Repository wirklich bedienen darf. Das reduziert Missverständnisse in Reviews spürbar.

Wie ich das in Teams einführe

Ich versuche nicht, alles auf einmal zu typisieren. Ich gehe in klaren Stufen vor.

1) Kritische Pfade zuerst

Ich beginne bei Domänenobjekten, Repositories und Integrationsgrenzen. Dort sind falsche Typannahmen am teuersten.

2) Analyse als CI-Gate

PHPStan und Psalm laufen als verbindlicher Check in der Pipeline. Bei schwerwiegenden Findings gibt es keinen Merge.

3) Baseline bewusst abbauen

Wenn eine Baseline nötig ist, nutze ich sie nur als Übergang. Ich plane aktiv, sie schrittweise zu verkleinern.

4) Teamkonventionen dokumentieren

Ich halte fest, wann wir mixed akzeptieren, wie @template benannt wird und wo Union Types sinnvoll sind. So bleibt die Analyse konsistent statt individuell.

Drei typische Fehler, die ich vermeide

1) Tool einführen, aber Regeln offenlassen

Dann läuft zwar ein Check, aber jeder interpretiert die Ergebnisse anders.

2) Zu früh auf maximale Strenge schalten

Wenn ich sofort alles auf dem höchsten Level erzwinge, entsteht oft Frust statt Qualität. Ich erhöhe die Strenge schrittweise.

3) Findings nur wegkonfigurieren

Suppressions sind manchmal nötig, dürfen aber kein Dauerzustand werden. Sonst verliere ich genau die Sicherheit, die ich aufbauen wollte.

Welche Rolle native Generics später spielen können

Wenn PHP künftig mehr generische Sprachmittel liefert, ist das für mich ein Upgrade, nicht ein Neustart. Mit sauberer statischer Analyse sind Struktur und Denkweise bereits vorhanden.

Teams, die heute Typverträge ernst nehmen, können solche Neuerungen später deutlich leichter übernehmen.

Fazit

Typsicherheit in PHP ist heute schon möglich, auch ohne vollständige native Generics. Für mich sind PHPStan und Psalm der pragmatische Weg, um Qualität, Lesbarkeit und Refactoring-Sicherheit sofort zu erhöhen.

Ich warte nicht auf das perfekte Feature. Ich baue den verlässlichen Standard mit den Werkzeugen, die jetzt funktionieren.

Wenn du magst, kannst du mit dem Projekt-Check prüfen, wie robust eure Architektur-, Test- und Typsicherheitsbasis aktuell ist.