Alle paar Monate veröffentlicht jemand "50 Tools, die jeder Entwickler braucht". Ich habe viele davon gelesen. Ich habe aus keiner je mehr als zwei Dinge installiert.
Das hier ist also die andere Liste: was tatsächlich wieder auf die Maschine kommt, wenn ich eine von Grund auf aufsetze, in der Reihenfolge, in der ich es installieren würde. Sie ist kurz, und sie ist absichtlich kurz.
Die Regel, die die Liste kurz hält
Nichts wird auf dem Host installiert, außer es kann unmöglich in einem Container laufen.
Diese eine Regel streicht etwa 80 % jeder normalen Tool-Liste. Kein PHP auf der Maschine, kein Node, kein Composer, keine Datenbank, kein CLI-Werkzeug, das zufällig Python 3.11 braucht. All das läuft in einem Container, auf das Projekt zugeschnitten, das es braucht, und verschwindet mit dem Projekt.
Übrig bleibt das, was mit der Hardware, dem Display oder den Containern selbst reden muss. Das ist die echte Liste.
Docker und docker-compose
Das Erste auf der Maschine, weil alles andere es voraussetzt. Jedes Projekt bekommt eine docker-compose.yml mit einem Service pro Aufgabe, und das Entwicklungs-Image wird auf dem Produktions-Image gebaut, damit die beiden nicht auseinanderlaufen können.
Das ist auch der Grund, warum ich keine vorgefertigte lokale Umgebung wie DDEV nutze — die lange Version dieses Arguments steht hier, und das Setup, das es ersetzt, hier.
PhpStorm
Das eine bezahlte Werkzeug, das ich nicht hergeben würde. Nicht wegen Syntax-Highlighting, sondern wegen zwei Dingen, die wirklich schwer zu ersetzen sind: die Debugger-Integration, und dass es das Framework gut genug versteht, um von einer Service-Definition zur implementierenden Klasse zu springen.
Ich kenne die Argumente für VS Code. Es ist ein guter Editor und kostenlos. Aber sobald du einen ordentlichen Teil deiner Woche in Symfony oder TYPO3 verbringst, ist der Unterschied darin, wie viel die IDE tatsächlich über deinen Code weiß, keine Geschmacksfrage mehr.
Xdebug
Xdebug lebt im Container, nicht auf dem Host, gehört aber wegen dem, was es ersetzt, auf diese Liste: var_dump, die(), und die Angewohnheit, durch das Hinzufügen von Ausgaben zu "debuggen", bis irgendetwas Sinn ergibt.
Durch einen Request zu steppen, die Variablen sich ändern zu sehen und in den Service hineinzuspringen, der sie erzeugt hat, ist eine völlig andere Tätigkeit als Raten. Wenn du es nie eingerichtet hast, ist das ein Nachmittag, der sich in einer Woche bezahlt macht — das habe ich anderswo ausführlich begründet.
Git, und Hooks, die ungefragt laufen
Git ist für sich genommen nicht interessant; hat jeder. Was sich im Setup seinen Platz verdient, ist core.hooksPath, das auf einen versionierten Ordner zeigt, damit jeder Clone dasselbe Pre-Commit-Verhalten bekommt, ohne dass sich jemand an einen Einrichtungsschritt erinnern muss. Das gehört zu einer etwas größeren Liste von Dingen, die ich am ersten Tag jedes PHP-Projekts einrichten würde.
Ein Mailcatcher
Mailcatcher oder Mailpit, in der Compose-Datei, in jedem einzelnen Projekt. Es kostet eine Servicedefinition und macht es strukturell unmöglich, dass eine Entwicklungsumgebung eine echte E-Mail an eine echte Person schickt. Das ist keine Bequemlichkeit, das ist ein Geländer.
curl und openssl
Zwei Dinge, die auf jeder Linux-Maschine ohnehin da sind und nach denen ich ständig greife — meistens, um die Frage zu beantworten: "Macht der Server wirklich das, was ich denke, oder lügt mein Browser?"
Browser cachen aggressiv und verstecken Redirects, sie sind bei Infrastrukturänderungen also die denkbar schlechteste Art zu prüfen, ob die Änderung angekommen ist. curl -I und openssl s_client sagen dir, was der Server wirklich geschickt hat. Aufgeschrieben habe ich das in warum ich Infrastrukturänderungen nicht im Browser teste und wie du SSL-Zertifikate auf der Kommandozeile prüfst.
Ein REST-Client
Postman oder der Client in der IDE, je nach Projekt. Für APIs, die ich selbst baue, lasse ich ihn meistens weg und schreibe stattdessen den Funktionstest — aber um die API von jemand anderem zu erkunden, gibt es nichts Besseres. Welchen du nimmst, ist ein eigener Artikel.
ngrok
Das einzige Werkzeug auf dieser Liste, das ich widerwillig installiere. Es existiert für ein einziges Problem: OAuth-Provider weigern sich, auf localhost umzuleiten, ein lokales Backend braucht also eine öffentliche HTTPS-URL. Nichts anderes löst das sauber. Details hier.
wmctrl
Ein unglamouröses X11-Werkzeug, mit dem du Fenster auflisten und von der Kommandozeile aus auf exakte Pixelkoordinaten schieben kannst. Ich nutze es, um Bildschirmaufnahmen reproduzierbar aufzusetzen, damit jeder Clip denselben Bildausschnitt hat, ohne dass ich ein Fenster von Hand zurechtziehe. Dieser Ablauf steht hier.
Was bewusst nicht auf der Liste steht
Kein Terminal-Multiplexer, kein Shell-Framework mit 200 Plugins, kein Dotfiles-Repository. Nicht weil die schlecht wären — viele gute Entwickler schwören darauf —, sondern weil jedes davon etwas ist, das du pflegen, migrieren und der nächsten Person erklären musst, die sich an deine Maschine setzt.
Auch keine KI-Codevervollständigung im "zuerst installieren"-Satz. Ich nutze KI intensiv, aber um Arbeitsstücke zu erzeugen und zu prüfen, die ich danach ordentlich lese — nicht als Autovervollständigung, die ich irgendwann nicht mehr kontrolliere.
Das ehrliche Fazit
Neun Dinge, und drei davon sind ohnehin auf der Maschine. Der Grund, warum die Liste so kurz ist, ist nicht Minimalismus um seiner selbst willen — es ist, dass jedes Werkzeug auf dem Host eine Abhängigkeit ist, die das Projekt überlebt, für das es installiert wurde.
Die Werkzeuge, auf die es ankommt, sind nicht die, die du sammelst. Es sind die, deren Fehlen dir innerhalb einer Stunde auffallen würde.