Wenn Programmierer das Konzept "Full Stack" sehen, haben sie wahrscheinlich zwei Reaktionen

1. Heilige Scheiße, das ist großartig, verdammt cool!

2. Was zum Teufel weißt du schon? Full Stack bedeutet nur, in allem mittelmäßig zu sein

Beide oben genannten Reaktionen sind eigentlich voreingenommen. Denn selbst wenn man nur eine Technologie lernt, gibt es genügend Leute, die darin furchtbar sind, und unter Full-Stack-Entwicklern gibt es nicht wenige, die alles machen und es gut machen. Ganz zu schweigen davon, dass es in dieser Welt eine andere Art von "Stack-Bursting"-Programmierern gibt, die in allem, was sie tun, herausragend sind.

Ausgehend von meiner persönlichen Praxis, mussein Full-Stack-Lehrlingmindestens die folgenden Fähigkeiten beherrschen:

• Web-Frontend-Entwicklung — mindestens ein Frontend-Framework beherrschen;
• Server-Backend-Entwicklung — mindestens ein Backend-Framework beherrschen;
• Serverbetrieb — Einrichtung und Wartung von Linux-Servern beherrschen;
• Client-Entwicklung — mindestens eines von iOS und Android beherrschen;
• Datenbanken — SQL- und NoSQL-Datenbanken beherrschen.

Und das Erlangendes „Full-Stack“-Titels sollte zumindest erfordern, eigenhändig den Aufbau eines Produkts abzuschließen, echte kommerzielle Abläufe erlebt zu haben und durch die eigeneDummheitunzählige Male hereingelegt worden zu sein.

Daran zeigt sich, dass die Hürde für Full-Stack ziemlich hoch ist. Es ist nicht so, dass man, wenn man die oben genannten fünf Fähigkeiten beherrscht, schon als Full-Stack qualifiziert ist; mindestens muss man „Lehrling“ davorsetzen. Gerade weil zu viele Lehrlinge sich selbst Full-Stack nennen, denken andere, „Full-Stack“ sei ein Synonym für „in allem mittelmäßig“.

Der Titel dieses Artikels lautet jedoch – warum duversuchen solltest,Full-Stack auszuprobieren, also geht es mir nicht darum, ob man Full-Stack sein sollte, sondern um das Ausprobieren.

Außenstehende und Insider

In den letzten paar Jahren habe ich mit vielen Teams gesprochen und festgestellt, dass die überwiegende Mehrheit der Teamkonflikte entsteht, weil –

• Server-Leute verstehen den Client nicht, also faseln sie nach dem Entwerfen einer API einfach Unsinn;
• Designer verstehen den Client nicht, also entwerfen sie Interaktionen und faseln dabei Unsinn;
• Client-Leute verstehen den Server nicht, also faseln sie Unsinn über die API;
• Client-Leute verstehen das Produkt nicht, also faseln sie Unsinn über die Anforderungen;
• Produktmanager verstehen die Anforderungen nicht, also faseln sie Unsinn gegenüber dem Team.

Abgesehen davon, dass Produktmanager im letzten Fall auf dem Scheiterhaufen verbrannt werden sollten, sind die ersten vier Konflikte noch zu retten.

Programmieren ist ein God-Mode-Beruf; die tägliche Arbeit ist Schöpfung, deshalb wirkt dieser Beruf sehr cool. Doch genau deshalb sind Programmierer mehr oder weniger ein bisschen arrogant.Das Ergebnis von Arroganz ist, mit seinem eigenen begrenzten Wissen darüber zu spekulieren, wie die Arbeit anderer erledigt werden sollte.。

Wenn die Serverseite den Client nicht versteht, ist es sehr einfach, eine API zu entwerfen, die nicht den Client-Mechanismen entspricht. Zu diesem Zeitpunkt ist es noch akzeptabel, wenn der Client-Programmierer geduldig erklärt und jede API ein bis zwei Tage braucht, um sie auszufeilen; wenn nicht, führt das zu Streitigkeiten.

Aber serverseitige Programmierer liegen nicht immer falsch. Die Clientseite möchte, dass alle Daten geliefert werden, ohne dass eine weitere Verarbeitung nötig ist, aber wenn die Daten so strukturiert sind, wie der Client sie braucht, können einige Abfragen ein oder zwei Sekunden dauern. Wenn die Clientseite die serverseitigen Mechanismen nicht versteht und blind nach dem Prinzip fordert, dass „der Server existiert, um dem Client zu dienen“, lassen sich Streitigkeiten wieder kaum vermeiden.

Wenn Auseinandersetzungen zwischen technischen Leuten Kaltwaffenkrieg sind, dann bedeutet die Begegnung mit einem noch unprofessionelleren Produktmanager oder Chef, dass ein Atomkrieg ausbricht.

„Du änderst doch nur eine Webseite — schaffst du das in zehn Minuten?“

„Wie kann der Effekt denn schwer umzusetzen sein? Lass mich das für dich machen!“

„Morgen starten, beeil dich!“

„Es ist mir egal, welche technischen Schwierigkeiten du hast, du musst es einfach hinkriegen!“

Und solche Szenen spielen sich in fast jedem Unternehmen ständig ab.

Versuche, die Technologie der anderen Seite zu verstehen

Lass mich zuerst über meinen technischen Werdegang sprechen.

Ich begann in der Mittelschule, Linux zu verwenden; mein Hauptsystem war Ubuntu. Später wechselte ich zu ArchLinux, dann zurück zu Ubuntu, und ich verwendete es weiter bis zu meinem ersten Studienjahr. Diese Jahre der Linux-Erfahrung legten den Grundstein für meine Server-Architektur. In meinem ersten Studienjahr begann ich zu versuchen, ein eigenes Produkt zu bauen.

Damals dachte ich, ich sollte zuerst eine Web-Version schreiben und dann einen Client.

Also begann ich mit dem Backend, wobei Django mein Ausgangspunkt war, aber ich wechselte bald ins Rails-Lager. Rails' agile Entwicklung senkte die Entwicklungskosten erheblich, und seine auf Konventionen basierenden Gewohnheiten ermöglichten es auch Neulingen, viele gefährliche Bereiche sicher zu überfliegen.

Als ich anfing, das Web-Frontend zu schreiben, wusste ich nicht, dass es Frontend-Frameworks gibt. Erst nachdem ich mit Rails fertig war, entdeckte ich etwas namens Ember.js, also begann ich, mit Ember.js neu zu schreiben. Mein anfängliches Verständnis war noch, wie man Rails verwendet, um das Frontend zu rendern, aber später erkannte ich, dass Rails' Rolle nach der Einführung eines Frontend-Frameworks bereits zu einem API-Server geworden war.

Also begann ich von dort aus, aus einer neuen Perspektive darüber nachzudenken, wie man Rails' API entwirft. Ich las viele Materialien zum API-Design — wie man das Frontend benutzerfreundlich gestaltet, wie man die Abfragezeit reduziert, Server-Caching, Redis, Sicherheit und so weiter.

Rails' Automatisierung half sehr; sie hatte sich bereits um viele Dinge gekümmert, von denen ich nicht einmal wusste. Und wenn man sie verstehen will, stellt man fest, dass die Implementierung so genial ist. Ganz zu schweigen von Rails' Aufgeschlossenheit gegenüber neuen Technologien, was bedeutete, dass es immer etwas Neues zum Ausprobieren gab. CoffeeScript und Sass wurden ursprünglich von Rails als Standard-Frontend-Technologien seines Frameworks übernommen.

Später wechselte ich von Ember.js zu Angular.js und schrieb alles mit Angular neu. In dieser Zeit kam ich auch mit dem Frontend-Tool Grunt in Kontakt (Frontend-Änderungen im rasanten Tempo; die heute verwendeten Tools sind nicht mehr dieses).

Schließlich begann ich, einen iOS-Client zu entwickeln. Zu diesem Zeitpunkt war die iOS-UI-Implementierung ganz anders als Web-HTML und CSS, also verbrachte ich viel Zeit damit, iOS-UI-Konzepte zu verstehen und mein Denken von der Webentwicklung auf die iOS-Oberflächenentwicklung umzustellen.

In dieser Zeit wechselte auch die Datenbank von MySQL zu MongoDB, weil der Trend jener Jahre genau dieser Wandel war.

Zum Glück war ich der Einzige in diesem praktischen technischen Prozess, also gab es niemanden, mit dem ich mich streiten konnte. Andernfalls hätte es, denke ich, in jeder Phase reichlich Stoff zum Streiten gegeben.

Nachdem das Projekt, das ich entwickelt hatte, live ging und als die Komplexität des Betriebs allmählich zunahm, kam ich mit automatisierten Betriebstools wie Chef und Ansible in Kontakt. Danach kamen auch Monitoring-Dienste wie NewRelic hinzu, und für eine stabile Entwicklungsumgebung nutzte ich Vagrant.

All dies geschah innerhalb nur eines Jahres.

Interessanterweise verstand ich, während ich den iOS-Client schrieb, plötzlich die Implementierungsprinzipien von HTML und CSS; während ich an Rails arbeitete, fielen mir plötzlich bessere Ansätze für die iOS-Architektur ein. Das Gefühl, Analogien zwischen verschiedenen Technologien zu ziehen, hatte ich jeden Tag.

In der späteren Phase machte diese Erfahrung für mich die Kommunikation mit verschiedenen technischen Leuten sehr einfach, denn letztes Jahr,für MiaoshisFilterentwicklung, begann ich, openGL zu erforschen, und nachdem ichBlender, viele Stellen, die ich zuvor nur halb verstand, wurden plötzlich so einfach umzusetzen wie Hello World. Also begann ich einfach, auch mit Unity zu spielen. Nach all dieser Ansammlung wurde das Erlernen von Unity sehr einfach, und es wurde mein abendliches Freizeitprojekt. Vielleicht siehst du bald ein Spiel von mir (es könnte ein RPG sein).

Ich glaube nicht, dass Full Stack einen in allen Bereichen mittelmäßig macht. Wenn man mit jeder Technologie arbeitet, kann sie Ideen für andere Technologien liefern. Und unter der Voraussetzung, dass man verschiedene Technologien versteht, kann ein tiefes Eintauchen in eine von ihnen oft auf andere Technologien zurückwirken. Im Gegenteil: Wenn die Technologien, die man versteht, sehr eng begrenzt sind, ist das wahrscheinlich der wahre Grund, der das eigene Potenzial einschränkt.

Respekt und Frieden

In der Teamkommunikation kann das Verständnis der Technologie der anderen Seite die Kommunikationskosten erheblich senken und Respekt und Frieden bringen.

Es ist selten, dass Meister darüber streiten, wer nachgeben sollte. Im Gegenteil, meist sind es diejenigen, die gerade erst einen Blick auf das Feld erhascht haben, die den ganzen Tag endlos streiten und beim geringsten Anlass explodieren.

Obwohl es schwer zu sagen ist, dass sich das Niveau der gesamten Branche schnell qualitativ ändern kann, denke ich, dass, wenn Produktanforderungen klar und detailliert beschrieben und die Gründe erklärt werden können, technische Leute voneinander lernen und geduldig diskutieren können und Designer die technische Dimension respektieren und Prototypen entwerfen können, die besser zur Gegenwart passen, dann wird sich alles in eine gute Richtung entwickeln. Alles beginnt damit, die Arbeit des anderen zu verstehen.

Autor:Zhou Kaiwen

Originalartikel-URL: http://www.ifanr.com/551905