Der Begriff Full-Stack-Entwickler fällt in letzter Zeit immer häufiger. Besonders in Diskussionen über Teamstruktur, Anforderungen für die Einstellung oder um auf die pure Großartigkeit einer Person zu schließen.

Wenn ich diese Art von Aussage in einem Lebenslauf sehe oder jemanden höre, der sich selbst als Full-Stack bezeichnet, kommen mir eine Reihe von Fragen in den Sinn:

• Was verstehen Sie unter Full-Stack-Entwicklung?
• Über welchen Stapel beanspruchen Sie die Meisterschaft?
• Wie umfangreich ist Ihr Wissen zu den einzelnen Elementen? Wie voll muss es sein?

• Ist der Full-Stack-Entwickler eine echte Sache? Gibt es sie wirklich?
• Wenn es sie gibt, warum sind sie nützlich?
• Ist Full-Stack eine andere Art zu sagen, Tausendsassa, Meister von nichts?

Hintergrund

Bevor wir ins Detail gehen, lohnt es sich zu definieren, was wir entwickeln und liefern wollen.

Die Behauptung, ein Full-Stack-Entwickler für einen PoC zu sein, der auf Ihrem Laptop läuft, ist wohl eine angemessene Beschreibung, da Sie die einzige Person sind, die jeden Teil dieser Lösung entwickelt. Der Maßstab ist sehr klein, und die Auswirkungen eines schlechten Designs oder einer schlechten Entwicklung sind sehr begrenzt. Grundsätzlich beweisen Sie ein Konzept, das keinen Service liefert, solange es für die einstündige Demo für den CIO funktionieren kann, ist es in Ordnung.

Wenn wir die Lösung als ein Produktionssystem definieren, das Live-Kundendaten verarbeitet und Erkenntnisse / Daten produziert, die die Generierung von Geschäftswert vorantreiben, ist die Situation anders, und die Auswirkungen von Programmierfehlern oder schlechten Praktiken sind viel größer.

Für die Zwecke dieses Beitrags betrachten wir ein System, das große Mengen (10 GB pro Tag) echter Kundendaten (einschließlich PII) verarbeitet und wichtige Geschäftsdienste mit einer Verfügbarkeit von mindestens 2 9 Sekunden bereitstellt.

Warum sind Full-Stack-Entwickler wertvoll?

Abgesehen von der Existenz solcher Menschen sind die Vorteile, die sie bieten, selbstverständlich. Sie sind in der Lage, eine Lösung ohne externe Unterstützung zu entwerfen, zu bauen und zu betreiben; Das bedeutet, dass all diese zeitaufwändigen und fehleranfälligen Design-Workshops, Komponentenintegrationen, Testzyklen und Betriebsübergaben weitgehend eliminiert werden. Es ist nicht erforderlich, ein Meeting oder noch schlimmer eine Reihe von Meetings zwischen den Sicherheits-, Plattform-, DB-, Operations-, … KMUs zu planen, da Sie in der Lage sind, die Lösung zu entwerfen, zu erstellen und zu betreiben. Eine kleine Anzahl dieser gottähnlichen Entwickler (kleines g) ist in der Lage, die Arbeit eines großen funktionsübergreifenden Teams zu liefern, und da der Aufwand für Übergaben entfällt, ist die Lieferung auch viel schneller und weniger fehleranfällig.

Also, basierend auf diesen klaren Vorteilen, warum gibt es nicht mehr Teams aus diesen Leuten in allen IT-Organisationen? Warum rekrutieren und trainieren Unternehmen nicht aktiv, um diese Ninja-Teams aufzubauen? Liegt es daran, dass es keine Entwicklungsäquivalente von Batman oder Tony Stark gibt?

Um diese Fragen zu beantworten, müssen wir uns ansehen, wie ein (sehr) vereinfachter Stack aussieht.

Vereinfachter Stapel

Ich lasse die Plattforminfrastruktur aus Gründen der Vereinfachung weg.

Wenn man sich die obigen Elemente ansieht, ist es offensichtlich, dass es eine Herausforderung sein wird, ein Experte auf jeder Ebene zu sein. Angenommen, ich muss nicht ALLES in jeder Schicht wissen , kann ich dann das erforderliche Wissen reduzieren und trotzdem als Full-Stack gelten? Wenn wir die Front-End-App als Beispieldomäne nehmen, könnten wir Android und iOS einfach entfernen und uns nur auf einen Webkanal konzentrieren und vielleicht noch weiter verfeinern und sagen, dass es auf React beschränkt ist, wie hilft das?

Was muss ich basierend auf unserem eingeschränkten Umfang über React-Web-Apps wissen?

Nun, zuerst müssen Sie verstehen, wie Single-Page-Apps funktionieren, insbesondere die Kernprinzipien, die zum Erstellen, Debuggen und Ausführen einer Web-App und der zugehörigen Tools erforderlich sind, z.

Sie müssen auch mit den von Drittanbietern bereitgestellten Funktionen, z. B. Material UI, Redux, Bootstrap, … und einer Paketverwaltungslösung wie npm (einschließlich der Verwaltung von Sicherheitslücken – normalerweise eine DevOps-Überlegung, siehe spätere Hinweise) sehr vertraut sein.

Was ist mit der Leistung, z. B. Zeit bis zum ersten Contentful Paint, Zeit bis zur Interaktion, Blockierungszeit, … Sollte ich eine fortschrittliche Web-App-Architektur einführen und/oder Servicemitarbeiter unterstützen? Sie müssen die Leistungsfaktoren verstehen und wissen, wie die verschiedenen Kernmuster bei der Verwendung von Tools zur Unterstützung der Analyse helfen können, z. B. React DevTools oder Lighthouse.

Barrierefreiheit ist ein Muss für alle Anwendungen, unabhängig davon, ob die App intern oder extern geliefert wird. Wie stelle ich die Einhaltung der WCAG-Richtlinien sicher?

Zusammenfassend lässt sich sagen, dass es gerade in der Front-End-Schicht eine Menge zu wissen gibt, und das hält es wohl leicht. Die restlichen Schichten sind nicht anders und in vielen Fällen nimmt die Komplexität zu. Und um die Sache noch schlimmer zu machen, überlappen sich die architektonischen Muster und Prinzipien, Best Practices und Frameworks NICHT .

Angenommen, ich habe es geschafft, die Muster, Standards, Best Practices und praktischen Fähigkeiten für jede Ebene in meinen Kopf zu stopfen, ohne dass es explodiert, was muss ich sonst noch wissen? Sind unterstützende Fähigkeiten erforderlich?

Unterstützende Fähigkeiten

Neben dem Tech-Stack gibt es eine Reihe unterstützender Funktionen, die zum Entwerfen, Erstellen, Bereitstellen und Ausführen aller Komponenten der Lösung erforderlich sind.

Architektur & SW-Engineering

Grundlegende Fähigkeiten zur Unterstützung des architektonischen Designs in allen Schichten, um eine gute Implementierung in jeder Sprache / jedem Framework zu schaffen

• SOLID (Einzelverantwortung, Offen/Geschlossen, Substitution, Schnittstellentrennung, Abhängigkeitsinversion)
• Wiederverwendbarkeit, Wartbarkeit, Portabilität, Erweiterbarkeit, …
• Horizontale und vertikale Skalierung
• Kodierungsstruktur
• Protokollierung
• Code-Reviews
• …

Jede der Ebenen und Komponenten innerhalb jeder Ebene (wobei das Front-End aus Sicht des Webkanals ignoriert wird, da es entweder vom Browser implementiert wird oder normalerweise außerhalb unserer Kontrolle liegt, da es sich auf der Clientseite befindet) im obigen vereinfachten Stapel erfordert eine sorgfältige Prüfung aus Sicherheitssicht z.B

• APIs : TLS, DDoS, Authentifizierung und Autorisierung, CORs, Inhaltssicherheitsrichtlinie, …
• Microservices : TLS (inkl. MA), Zugriffskontrollen, Secret Management, Validierung von Benutzereingaben, …
• Daten : Zugriffskontrollen, Verschlüsselung im Ruhezustand, Schlüsselverwaltung, Netzwerksicherheitsgruppen und Subnetze, …
• Plattform (zusätzlich) : Netzwerksicherheit, feste Komponentenkonfigurationen zB ChefInspec

Alle Entwickler benötigen grundlegende Testfähigkeiten. Es gibt keine Entschuldigung dafür, dass Sie Ihre eigenen Funktionen nicht testen können. Und in einer Full-Stack-Umgebung bedeutet das jede Komponente im obigen Diagramm.

Die unterschiedlichen Arten und Phasen des Testens verstehen und anwenden können (ohne eigene Hausaufgaben zu korrigieren):

• Funktional und nichtfunktional
• Blackbox gegen Whitebox
• Einheit, Integration, System, Benutzerakzeptanz, Regression, Rauch, …

Entwicklung und Pflege von Continuous Integration und Continuous Deployment Pipelines

Die wichtigsten Enabler für CICD werden oft von einem zentralisierten/dedizierten Team erstellt, aber jeder sollte zumindest in der Lage sein, die Pipelines zu aktualisieren und zu warten. (Ja, ich weiß; wenn Sie ein DevOps-Team haben, machen Sie kein DevOps, aber viele Organisationen tun es.)

Verwenden von Tools wie:

• Jenkins, TravisCI, Spinnaker
• GitHub, Bitbucket
• Sonarqube
• Zaproxy
• Veracode, Snyk
• Docker, Anker, Hafen
• …

Wenn wir den Ansatz „You build it, you run it“ ignorieren, werden die Anforderungen an einen Full-Stack-Entwickler rund um den Betrieb erheblich vereinfacht

Der Fokus muss darauf liegen, Ihre Anwendung so zu erstellen, dass sie funktionsfähig ist. Einschließlich aller erforderlichen Diagnose-Hooks, Ereignisprotokolle und eines Runbooks, sodass ein Laufteam in der Lage ist, Probleme zu sichten und möglicherweise zu lösen, ohne die Hilfe des Entwicklungsteams in Anspruch nehmen zu müssen

Natürlich hängt die Verantwortlichkeit für die oben genannten Funktionen wahrscheinlich davon ab, wie Ihre Organisation verwaltet wird – vielleicht besteht die Entwicklung ausschließlich aus Komponententests, oder alle Tests werden innerhalb des Scrum-Teams mit Ausnahme der Sicherheitstests durchgeführt. Aber wenn Sie in der Lage sind, die API-Entwicklung und das CICD-Pipeline-Management zu übernehmen, ohne Unterstützung von anderen zu benötigen, sparen Sie viel Zeit.

Wie bei den Schichten des Tech-Stacks ist der Umfang der unterstützenden Funktionen, die erforderlich sind, um den Full-Stack-Status zu beanspruchen, enorm.

Fazit

Ich glaube, dass der wahre Full-Stack-Entwickler (weitgehend) ein Mythos ist, und das schon, seit der Stack in den 1980er Jahren über die Ausführung von Assembler auf einem 6502 hinausging. Machen Sie sich nicht vor, dass Sie ein Full-Stack-Entwickler sind, wenn Sie ein Frontend zum Laufen bringen und mit ein paar APIs sprechen, die in Node geschrieben sind und auf einem K8-Knoten ausgeführt werden.

Diese Personen sind nicht nur wegen der Tiefe des Wissens und der Erfahrung, die sie in verschiedenen technischen Bereichen haben müssen, mythisch, sondern auch, weil dieser Umfang ständig zunimmt – jedes Jahr gibt es enorme Entwicklungen bei Technologien und Mustern in allen Bereichen, die Schritt halten bis heute ist sehr, sehr schwierig.

Außerdem werden diese Personen im Allgemeinen mehr Geld verlangen, als sich die meisten IT-Organisationen leisten können, aber wenn sie wirklich ein Full-Stack sind, sind sie es wert – wie die Werbung sagt.

Ich schlage vor, dass das Beste, was Sie erreichen können, die Beherrschung Ihres gewählten Bereichs (eine bestimmte Ebene mit einem begrenzten Technologiestapel innerhalb dieser Ebene) und bestenfalls Kompetenz und Bewusstsein für Ihren Mangel an Wissen in anderen Bereichen ist.

Ein besserer Weg für ein Team, erfolgreich zu sein, besteht darin, nicht zu versuchen, Full-Stack-Entwickler zu rekrutieren oder zu schulen, sondern stattdessen Domänen wie Front-End, Back-End, Datenbank usw der Stack wird begrenzt sein) mit überlappendem/übergreifendem Wissen in die anderen Domänen mit sehr klaren Schnittstellen, Standards, Best Practices und Frameworks zur Unterstützung einer qualitativ hochwertigen Entwicklung. Wenn Einzelpersonen in der Lage sind, mehrere Domänen auf Expertenebene zu überspannen, ist das großartig, aber meiner Erfahrung nach ist dies wirklich die Ausnahme.

Bonuskommentar:

Was müssen Sie wissen, um als Data-Science-Entwickler „mehr“ erfolgreich zu sein (beachten Sie die Verwendung des Wortes Entwickler dort anstelle des Begriffs Data Scientist – ich nehme an, Sie sind bereits ein guter Data Scientist? Und wenn Sie es nicht sind, ich da kann ich dir nicht helfen!). Wenn wir diesen Entwickler als jemanden definieren, der sich in jedem dieser Bereiche entwickeln kann, aber ein Experte im Data-Science-Teil* ist, dh mein reduziertes Ziel oben, ist die Industrialisierung des breiteren Stacks etwas, das ein Machine Learning Engineer tun würde … aber diese Diskussion ist es für ein anderes Mal.

*In unserem vereinfachten Stack können wir sagen, dass das Modell in das Microservices-Bit gehört … irgendwie