Full Stack Confession: Beruf, Religion, Träume

Hallo, mein Name ist Pavel und ich bin Full-Stack bei Mad Devs * Applaus *.

Vor dem Hintergrund einer Vielzahl von Artikeln und Materialien über die Tatsache, dass keine vollständigen Stapel benötigt werden , keine vollständigen Stapel vorhanden sind , keine vollständigen Stapel schlecht sind , gibt es eine Meinung darüber, welche Vorteile ein vollständiger Stapel gegenüber spezialisierten Spezialisten hat und warum vollständige Stapel benötigt werden .

Ich wollte am Anfang des Artikels eine Liste mit Links zu anderen Artikeln über vollständige Stapel hinterlassen, aber es gab zu viele davon, also tut es mir leid. Ich möchte nur sagen, dass es genug Material darüber gibt, warum ein voller Stapel gut und warum ein voller Stapel schlecht ist. Und jeder von ihnen ist zu mindestens 50% wahr.
Es gibt wahrscheinlich persönliche Gefühle und Gedanken, die nicht behaupten, der letzte Ausweg zu sein.

Wie ich bereits sagte, mein Name ist Pavel, es wird bald 7 Jahre her sein, seit ich Geld für das Programmieren bekomme. Und die ganze Zeit habe ich mich im Lebenslauf, bei Interviews und an anderen Orten genannt: Backend-Entwickler mit Kenntnissen und Fähigkeiten in Frontend und DevOps . Auf die eine oder andere Weise arbeitete er in seiner beruflichen Laufbahn oft als Back-End für Projekte, aber er hatte nie Angst vor der Front oder den Ops. Deshalb fügte er dieser Beschreibung stolz diese beiden Bereiche hinzu. Mit der Ankunft von Mad Devs und nachdem ich mit unserem MadOps-Team an einem der Projekte gearbeitet habe, habe ich DevOps aus meiner Beschreibung entfernt, weil ich jetzt glaube, dass ich es überhaupt nicht verstehe. Alles im Vergleich ist bekannt, wie Sie wissen. Ich hoffe, eines Tages mit denselben Front-End-Spezialisten zusammenarbeiten zu können, die mich "überreden" werden, das Front-End-Postscript zu entfernen. Die Hauptsache ist, keinen Backender zu treffen, was Sie dazu zwingt, das Backend aus dem Lebenslauf zu entfernen, da sonst nichts mehr übrig bleibt.

Die häufigsten Argumente von Experten, die schreiben und glauben, dass ein Full Stack ein schlechter Sound ist, klingen wie folgt: Kein Eintauchen in einen der Bereiche . Sie können kein Senior Fullstack-Entwickler sein , enge, hochklassige Spezialisten verdienen mehr als starke Full Stacks usw. Und weißt du, ich stimme ihnen zu.
In den letzten Monaten habe ich am Peklo Tool-Projekt gearbeitet, das Ruby im Backend, VueJS im Frontend und Go verwendet, um einen Textgenerator zu implementieren.

Und ich fühle die Probleme:
  • Ich bin der Meinung, dass dieser Code on Go besser geschrieben werden kann und schneller funktioniert oder weniger Systemressourcen verbraucht.
  • Ich habe das Gefühl, dass meine Webpack-Konfiguration viel besser konfiguriert werden kann. Es ist jetzt viel Müll darin.
  • Ich bin der Meinung, dass dieses Layout mit modernem CSS, SCSS-Funktionen oder PostCSS oder anderen Erweiterungen erstellt werden kann.
  • Ich bin der Meinung, dass der Code auf den Schienen so optimiert werden kann, dass beispielsweise weniger Abfragen in der Datenbank durchgeführt werden.
  • Ich bin der Meinung, dass Indizes in der Datenbank menschlich konfiguriert werden müssen.
  • Ich bin der Meinung, dass diese Docker-Datei neu geschrieben werden muss, damit weniger (oder mehr) Ebenen vorhanden sind.
  • und so weiter, so weiter, so weiter ...


Ich kann alles fühlen. Außerdem möchte ich wirklich alles machen. Und wenn eine freie Minute erscheint, löse ich mindestens eines dieser Probleme teilweise.
Sie fragen mich: Warum verwenden Sie nicht sofort Ding N an dieser Stelle, damit es keine derartigen Probleme gibt?
Und ich werde antworten: Ich kenne das Ding N nicht so gut, dass ich es in einem bestimmten Fall schnell in einem Projekt anwenden kann. Ich nehme mir einfach die Zeit für die Entwicklung - lesen Sie das Problem: Es gibt kein vollständiges Eintauchen .
Und ich werde nicht lügen, weil das Projekt, an dem ich arbeite, Funktionen benötigt. PekloTool ist ein professionelles Tool zur Erstellung kontextbezogener Werbekampagnen. Das Tool ist jung, die Entwicklung läuft seit etwas mehr als einem Jahr, aber es wurde erst vor ein paar Monaten vollständig produziert. Infolgedessen machen wir jetzt alle Funktionen, die für ein solches Produkt nützlich sind.
Woher weiß ich, dass Funktionen benötigt werden und dass Funktionen nützlich sind? Sehr einfach, weil ich voll gestapelt bin . Ich sehe das ganze Projekt. Ich sehe die Ziele des Projekts, ich sehe, wie es funktioniert, ich sehe seine Pfosten, nicht nur die technischen, über die ich oben geschrieben habe, sondern auch die Pfosten, die Benutzer sehen werden.

Und hier kommen wir zum Hauptpunkt dieses Artikels: Ich glaube, dass ein moderner Full-Stack nicht nur ein Encoder sein sollte, der Backends, Frontends oder etwas anderes kann. Fullstack ist jemand, der an der Entwicklung eines Projekts beteiligt ist. Neben Backend-, Frontend- usw. Kompetenzen Full Stack sollte ein Verständnis für den Themenbereich des Projekts, UX / UI-Kenntnisse und sogar ein wenig Marketing haben. Fulstack muss wissen, wie das Projekt seine Hauptaufgabe erfüllt: ob es Geld verdient oder die Welt rettet. Full Stack sollte mit dem „Kunden“ des Projekts auf einem kurzen Fuß sein. Jedes Projekt hat einen „Kunden“, wenn ein Outsourcing-Unternehmen ein Kunde ist, in einem Produktunternehmen ein Stakeholder oder ein Produkt. Der "Kunde" sollte im vollständigen Stapel den Spezialisten sehen, mit dem Sie sich zu allen Fragen im Zusammenhang mit dem Projekt beraten können.

Im Handbuch des Newcomers Mad Devs (dasselbe Dokument, das Sie am ersten Tag des Unternehmens lesen müssen) befindet sich ein Artikel mit dem Namen: „Kundenaffinität“ (dt . - „Kundennähe“). Ich habe das Wesentliche des Begriffs im vorherigen Absatz beschrieben. Ein vollständiger Stapel sollte immer auf den Hut eines Kunden gesetzt werden. Die ideale Option ist, wenn der „Kunde“ Sprintaufgaben zusammen mit einem vollständigen Stapel ausführt. Das heißt, ein vollständiger Stapel versteht den Verlauf des Erscheinungsbilds jeder Aufgabe und löst nicht nur die ihm übertragenen Aufgaben. Ich glaube, wenn eine Person einfach Aufgaben erledigt und ihre Arbeit dort endet, selbst wenn sie ein Backend, Frontend, Mobiltelefon usw. erledigt, ist dies kein vollständiger Stapel. Dies ist nur ein Back-End, das Front-End ausführen kann, oder umgekehrt.

Also schreibe ich das alles und der Leser kann zwei Gedanken haben:
  • Was für ein Unsinn . Hier für jeden sein eigenes. Wenn Sie der Meinung sind, dass Sie höchstwahrscheinlich ein enger Spezialist sind, ist Ihre Meinung klar. Aber wenn Sie Full-Stack sind, werde ich Sie „glücklich machen“. Sie verlieren eine Vielzahl nützlicher Aktivitäten, die Ihrem Projekt zugute kommen, und verlieren auch die Möglichkeit, wichtige Kompetenzen zu erwerben, die die weitere Entwicklung Ihrer Karriere bestimmen können.
  • Sollte ein vollständiger Stapel für einen Product Owner so aussehen? Ja, Sie haben Recht. Mit Ausnahme einiger Punkte: Der Produktberater ist häufig der Teamleiter des gesamten Projekts. Ich werde einem vollen Stapel keine Führungsqualitäten zuschreiben. Hier geht es um etwas anderes. Nun, der Produktanbieter sollte in der Lage sein, die Kosten für die Entwicklung eines Projekts zu berücksichtigen. Ein vollständiger Stapel ist nicht erforderlich, um über Finanzen nachzudenken, die sich auf die Entwicklung beziehen. Von seiner Position aus gibt es bereits Geld für die Entwicklung. Natürlich kann er Optionen anbieten, um die Entwicklungskosten zu senken, aber nur in Prozent oder qualitativ, nicht in quantitativer Hinsicht. Vielleicht fehlen mir ein paar Momente einige, die das Produkt können sollte, aber ich kann, ich bin voll gestapelt.


Es gibt eine andere Seite der Medaille, die ich beschreiben möchte. Das ist traurig . Das Problem bei vollen Stapeln ist, dass sie überlastet sind. Das ist offensichtlich. In der Regel erledigen wir sehr umfangreiche Aufgaben, komplexe Funktionen. Wir haben immer noch Kommunikation mit dem Kunden, um Funktionen und Aufgaben zu entwickeln, über die ich oben geschrieben habe. Wenn Sie das gesamte Projekt aus technischer Sicht betrachten, arbeiten Sie häufig an Infrastruktur, Architektur und anderen Dingen. Je mehr Informationen, je mehr Ideen und je mehr Ideen, desto größer die Chance, dass sie wahr werden. Infolgedessen denken Sie oft: Vielleicht eine NoSQL-Datenbank oder GraphQL oder vielleicht etwas anderes. Hier zeigt sich die Beschäftigung von selbst. Ich spreche nicht von der Tatsache, dass ich sofort laufe, um alles auf das bedingte GraphQL zu übertragen, aber manchmal akzeptieren Sie einige kleinere Ideen selbst und implementieren sie. Kurz gesagt, sehr beschäftigt.

Willst du was Ich würde gerne eine neue Bibliothek ausprobieren, die Gitlab CI-Konfiguration genauer studieren, etwas Interessantes und relativ Neues für mich rauchen, zum Beispiel Logux. Aber es gibt keine Zeit, Sie sind für das Projekt verantwortlich. Ich werde nicht sagen, dass diese Traurigkeit , nur traurige Traurigkeit. Im Gegensatz dazu bekomme ich eine große Begeisterung: ab dem Zeitpunkt, an dem ich positive Nutzerbewertungen sehe; wenn sie freudig über eine Funktion schreiben, aufgrund derer Sie einige Tage lang nicht geschlafen haben; wenn die Anzahl der Benutzer wächst.

Abschließend drücke ich die Idee aus, dass enge und breite Spezialisten ihre eigenen Vorteile für das Projekt, ihre Karriere, ihr Umfeld und ihre Nachteile haben. Meiner Meinung nach werde ich in einem der folgenden Materialien spezifische berufliche Vor- und Nachteile beschreiben, es sei denn, dies wird natürlich sehr positiv aufgenommen.

Ich bin froh, dass ich Full-Stack bin, denn das ist die Arbeit, die ich mag, die ich am Wochenende gerne mache und die ich gerne mache.

Source: https://habr.com/ru/post/de446040/


All Articles