Freiberuflichen Symfony-Entwickler einstellen: Worauf Sie bei einem Legacy-Projekt achten sollten

Ihre Symfony-Anwendung läuft seit Jahren und trägt das Geschäft, und die Person, die sie gebaut hat, ist nicht mehr da. Sie brauchen schnell jemanden, also schreiben Sie eine Stelle aus, um einen freiberuflichen Symfony-Entwickler einzustellen, und die Bewerbungen kommen herein. Die meisten sehen auf dem Papier gut aus: ein ordentliches Portfolio, ein paar Jahre Symfony unter den Fähigkeiten, vielleicht eine Zertifizierung oder zwei. Nichts davon sagt Ihnen, ob diese Person in eine sechs Jahre alte Codebasis einsteigen, verstehen kann, was bereits da ist, und sie am Laufen halten kann, während sie sie repariert. Einen freiberuflichen Symfony-Entwickler für ein Legacy-Projekt einzustellen ist eine andere Übung als einen für einen Neubau einzustellen, und die Screening-Fragen sollten entsprechend anders sein. Der Rest dieses Leitfadens behandelt, was tatsächlich eine Einstellung, die mit Ihrer Codebasis zurechtkommt, von einer unterscheidet, die monatelang auf Ihre Kosten damit kämpfen wird.

Warum die Einstellung eines freiberuflichen Symfony-Entwicklers für Legacy-Arbeit eine eigene Fähigkeit ist

Ein Entwickler, der hervorragend neue Projekte beginnt, kann bei einem geerbten Projekt trotzdem stark ins Schwimmen kommen. Neuen Code zu schreiben erlaubt es, eigene Muster zu wählen und im eigenen Tempo zu arbeiten. Legacy-Arbeit bedeutet, die Entscheidungen einer anderen Person zu lesen, oft vor Jahren unter Zeitdruck getroffen, und herauszufinden, welche Teile tragend sind, bevor man irgendetwas anfasst. Der Entwickler muss dem Drang widerstehen, alles neu zu schreiben, womit er nicht einverstanden ist, denn eine Neuentwicklung bringt ein Risiko mit sich, das das Unternehmen nicht angefragt hat.

Bitten Sie den Kandidaten im ersten Gespräch, zu beschreiben, wann er zuletzt eine Codebasis übernommen hat, die er nicht selbst geschrieben hat. Achten Sie darauf, wie er die erste Woche angegangen ist. Jemand, der davon erzählt, Tests um die Teile zu schreiben, die er vor dem Refactoring ändern musste, gibt Ihnen ein gutes Signal. Jemand, der hauptsächlich davon erzählt, wie er es anders gebaut hätte, sagt Ihnen auch etwas, nur nicht das, was Sie hören wollen.

Fragen Sie nach dem Versionsverlauf, nicht nur nach der aktuellen Version

Symfony hat seit den 2.x-Tagen große Veränderungen durchlaufen, und eine Codebasis, die mit Symfony 2 oder 3 begann und nie vollständig modernisiert wurde, trägt Narben aus jedem Release auf dem Weg. Ein Entwickler, der Symfony 6 oder 7 nur von Neubauprojekten kennt, hat möglicherweise nie mit dem Bundle-System der 2.x-Ära zu tun gehabt, mit den Änderungen am Service-Container, die in 3.x und 3.4 eingeführt wurden, oder mit dem Sprung von Annotationen zu Attributen für Routing und Konfiguration.

Bitten Sie den Kandidaten, Ihnen zu erklären, was sich an jeder großen Symfony-Versionsgrenze geändert hat und was bei einem Upgrade üblicherweise bricht. Hat Ihre eigene Anwendung einen verschlungenen Versionsverlauf, deckt unser Leitfaden zur Migration von Symfony 2/3 zu Symfony 7 in Etappen den Weg ab, den die meisten Legacy-Projekte tatsächlich gehen müssen, und es lohnt sich, ihn mit einem Kandidaten zu teilen, um zu sehen, wie er reagiert. Jemand, der zustimmend nickt und anfängt, nach Ihrer konkreten Bundle-Liste zu fragen, ist weiter als jemand, der annimmt, jede Symfony-Anwendung ließe sich auf dieselbe Weise aktualisieren.

Doctrine-Migrationen sagen mehr aus als ein Lebenslauf

Kaum etwas entlarvt echte Symfony-Erfahrung schneller als ein Gespräch über Doctrine-Migrationen. Ein Legacy-Projekt hat selten eine saubere Migrationshistorie. Meist gibt es Lücken, in denen Migrationen manuell ausgeführt und nie protokolliert wurden, Schemaänderungen, die während eines Vorfalls direkt in der Produktion vorgenommen wurden, oder eine Migrationstabelle, die nicht mehr mit der Realität übereinstimmt.

Fragen Sie, wie der Kandidat bestätigen würde, dass das tatsächliche Datenbankschema eines Projekts dem entspricht, was die Migrationsdateien behaupten, und was er tun würde, wenn das nicht der Fall ist. Ein Entwickler mit echter Legacy-Erfahrung wird erwähnen, das Schema gegen die Entity-Definitionen zu diffen, nach verwaisten Migrationsdateien zu suchen und vorsichtig zu sein, doctrine:migrations:migrate blind auf einer Datenbank auszuführen, der er noch nicht vollständig vertraut. Lautet die Antwort schlicht "Ich würde die Migrationen ausführen", suchen Sie weiter.

Testgewohnheiten zeigen, wie sie mit Ihrer Codebasis umgehen werden

Sie erben wahrscheinlich kein Projekt mit starker Testabdeckung. Das ist normal für Legacy-Symfony-Anwendungen, und ein guter freiberuflicher Entwickler wird nicht verlangen, dass Sie für eine vollständige Testsuite bezahlen, bevor er etwas anfasst. Entscheidend ist, wie er an das Testen rund um den konkreten Bereich herangeht, den er ändern muss.

Fragen Sie, was er tut, bevor er ein ungetestetes Stück Legacy-Code ändert. Die ehrliche, erfahrene Antwort beinhaltet meist das Schreiben von Charakterisierungstests zuerst: Tests, die dokumentieren, was der Code aktuell tut, Fehler eingeschlossen, damit eine Änderung gegen bekanntes Verhalten überprüft werden kann, statt erraten zu werden. Sagt ein Kandidat, er würde einfach vorsichtig refaktorieren und manuell testen, in einer Legacy-PHP-Anwendung mit echten Kunden darauf, ist das ein Risiko, das Sie sorgfältig abwägen sollten, bevor Sie irgendetwas unterschreiben.

Fragen, die sich im ersten Gespräch lohnen

Eine kurze Liste direkter Fragen kann Ihnen später Wochen an Schmerz ersparen.

• Erzählen Sie mir vom ältesten Symfony-Projekt, an dem Sie gearbeitet haben, und mit welcher Version es begann.
• Wie bestätigen Sie, dass ein Legacy-Datenbankschema tatsächlich mit den Doctrine-Entities übereinstimmt, bevor Sie Änderungen vornehmen?
• Wie gehen Sie vor, um Tests zu Code hinzuzufügen, der keine hat, bei einem Projekt, das bereits in Produktion ist?
• Mussten Sie schon einmal ein Deployment auf einem Legacy-System zurückrollen, und was ist schiefgelaufen?
• Wie entscheiden Sie, was Sie in Ruhe lassen und was sofort behoben werden muss?

Die Antworten selbst zählen weniger als wie konkret sie ausfallen. Vage, allgemeine Antworten bedeuten meist, dass der Kandidat die Situation, für die Sie ihn einstellen wollen, noch nicht tatsächlich durchlebt hat.

Warnzeichen, bei denen Sie innehalten sollten

Ein paar Muster deuten häufig auf Probleme bei einem Legacy-Symfony-Engagement hin:

• Eifer, große Teile der Anwendung neu zu schreiben, bevor vollständig verstanden wurde, warum sie so gebaut wurde.
• Keine Fragen zu Ihrer aktuellen PHP- und Symfony-Version oder Ihrem Hosting- und Deployment-Setup, bevor ein Preis genannt wird.
• Zuversicht, die losgelöst wirkt von der Komplexität, die Sie bereits beschrieben haben.
• Keine Erwähnung von Backups, Staging-Umgebungen oder Rollback-Plänen, wenn Sie fragen, wie er die ersten Wochen angehen würde.

Keines davon ist für sich allein ein automatisches Ausschlusskriterium. Zusammen sagen sie Ihnen, ob jemand diese Arbeit tatsächlich schon einmal gemacht hat oder auf Ihrem Produktivsystem erst lernt.

Was das kosten sollte, und warum das billigste Angebot selten das sicherste ist

Die Sätze für freiberufliche Symfony-Entwickler variieren stark, und das niedrigste Angebot kostet am Ende meist mehr, sobald man einrechnet, was passiert, wenn das Engagement auf einem System schiefgeht, das Sie sich nicht leisten können offline zu haben. Ein Entwickler, der tatsächlich schon mit Legacy-Symfony gearbeitet hat, wird in der Regel um Zeit bitten, die Codebasis zu erkunden, bevor er Ihnen ein Festpreisangebot macht, denn unbekannte Legacy-Arbeit genau zu schätzen, ohne hineingeschaut zu haben, kommt Rätselraten nahe. Seien Sie vorsichtig bei jemandem, der allein aus einer Stellenbeschreibung einen festen Preis und Zeitplan nennt, ohne eine Zeile Ihres Codes gesehen oder nach Ihrer Datenbankgröße, Ihren Traffic-Mustern oder dem, was sonst neben der Symfony-Anwendung läuft, gefragt zu haben.

Eine kurze, bezahlte Discovery-Phase, selbst ein oder zwei Tage, ist eine vernünftige Bitte und für sich genommen ein guter Filter. Sie gibt dem Entwickler einen echten Blick in Ihre Codebasis, bevor er sich auf eine Zahl festlegt, und gibt Ihnen eine risikoarme Möglichkeit zu sehen, wie er arbeitet, bevor Sie ihm die Schlüssel zu etwas übergeben, auf das sich das Geschäft verlässt.

Diese Einstellung richtig hinbekommen

Eine Legacy-Symfony-Codebasis trägt meist etwas, auf das sich das Geschäft verlässt, genau deshalb ist die falsche Einstellung teuer. Der richtige freiberufliche Entwickler behandelt Ihren bestehenden Code mit Respekt, auch wenn er innerlich denkt, dass Teile davon neu gebaut werden sollten, und kann Ihnen klar sagen, was er geändert hat, warum und wie er überprüft hat, dass es weiterhin funktioniert. Unser Legacy-Code-Optimierungsservice existiert für die Version dieses Problems, die über ein einzelnes freiberufliches Engagement hinausgeht, wenn die Codebasis einen strukturierten Sanierungsplan braucht statt einer weiteren helfenden Hand.

Wenn Sie eine zweite Meinung möchten, bevor Sie einen Vertrag mit einem Kandidaten unterschreiben, oder Hilfe dabei brauchen, abzugrenzen, was ein Legacy-Symfony-Engagement tatsächlich umfassen sollte, melden Sie sich unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io. Ein kurzes Gespräch über Ihre konkrete Codebasis ist kostenlos, und es bringt meist die Fragen zutage, die Sie stellen sollten und die dieser Beitrag nicht abgedeckt hat.