Seite 4 - PHPStorm

Wer phpcs, phpstan oder bin/magento cache:flush immer wieder im Terminal eintippen muss, verliert Zeit und Fokus. PhpStorm erlaubt es, jeden Composer-Script, jedes Shell-Kommando und jedes Docker-Wrapper-Skript als Button direkt in die IDE zu integrieren – klickbar, mit Ausgabe im Run-Fenster und optional per Tastenkürzel auslösbar.

Magento 2 bringt eine eigene Testinfrastruktur mit, die sich erheblich von einem Standard-PHPUnit-Projekt unterscheidet. Wer Integrationstests direkt aus PHPStorm starten, Coverage-Berichte in der IDE sehen und einzelne Testmethoden mit einem Klick debuggen will, braucht spezifische Konfigurationen – die dieser Artikel vollständig abdeckt.

Nicht jede Codezeile verdient eine eigene Datei im Projekt. PhpStorms Scratch Files erlauben schnelle Experimente mit voller Syntax-Hervorhebung und Sprachunterstützung, komplett losgelöst vom aktuellen Projekt, während Scratch Buffers für noch kürzere, unbenannte Zwischenablagen dienen. Wer beide gezielt einsetzt, hält das eigentliche Projekt sauber.

Das Standardprofil von PhpStorm ist fuer generisches PHP gedacht und passt selten eins zu eins zu den Konventionen eines gewachsenen Magento-Projekts. Wird jedes Inspection-Profil nur lokal angepasst, sieht jeder Entwickler andere Warnungen, was Code-Reviews unnoetig erschwert. Dieser Artikel zeigt, wie ein eigenes Profil als Team-Standard definiert und ueber .idea/inspectionProfiles im Projekt-Repository versioniert wird, damit alle Entwickler beim Checkout automatisch dieselben Code-Qualitaets-Warnungen sehen.

Ein HTML-Coverage-Report ist gut fuer den Ueberblick, aber schlecht zum Arbeiten. PhpStorm zeigt Testabdeckung direkt farbig im Editor-Gutter an, sodass ungedeckte Zeilen sofort dort sichtbar sind, wo gerade programmiert wird.

Code Vision blendet direkt ueber jeder Methode an, wie oft sie aufgerufen wird und ob zugehoerige Tests zuletzt gruen waren, waehrend Inline Hints Parameter- und Typinformationen mitten im Code einblenden. Beide Funktionen koennen enorm hilfreich sein, um Zusammenhaenge auf einen Blick zu erfassen, aber genauso gut den Editor optisch ueberladen, wenn sie unreflektiert ueberall aktiv sind. Dieser Artikel zeigt, wie beide Funktionen gezielt konfiguriert werden und wie ein Team eine gemeinsame Konvention dafuer festlegt, statt dass jeder Entwickler eine andere Ansicht sieht.

Acht Stunden vor dem Editor sind kein Ausnahmefall, sondern Alltag fuer PHP-Entwickler. Ein Farbschema, das morgens angenehm wirkt, kann am Nachmittag zur Belastung werden. Wir zeigen, wie granulares Tuning in PhpStorm ueber die Theme-Wahl hinausgeht.

Statische Analyse und Code-Style-Prüfungen erst in der CI-Pipeline zu sehen ist zu spät. PHPStan, Psalm und PHP_CodeSniffer lassen sich direkt in PhpStorm integrieren – als externe Tools, Run Configurations und File Watchers – sodass Feedback schon beim Speichern kommt, nicht erst beim Pull Request.

Handgeschriebene PHPDoc-Bloecke veralten fast garantiert, sobald sich eine Signatur aendert. PhpStorm kann Docblocks aus dem tatsaechlichen Code inferieren, veraltete Kommentare markieren und so die Grundlage schaffen, auf der PHPStan verlaesslich analysieren kann.

Standardmäßig zeigt PHPStorm so viele Inspektions-Warnungen, dass Entwickler sie kollektiv ignorieren. Das ist kontraproduktiv: Warnungen verlieren ihre Signalwirkung und echte Probleme gehen im Rauschen unter. Die Lösung ist nicht weniger Qualitätssicherung, sondern klügere Konfiguration.