it-swarm.com.de

Ist es üblich, Back-End und Front-End bei Webentwicklungsprojekten in zwei Positionen zu trennen?

Ist es bei einem Web-Startup üblicher, dass ein Techniker das Front-End UND das Back-End des Features bearbeitet (im Grunde genommen ist er für das gesamte Feature verantwortlich)? Oder haben Ingenieure zwischen Backend und Frontend getrennt?

Welche sind vorteilhafter und für welche Situationen?

Ich habe festgestellt, dass der Nachteil, dass ein Techniker für das gesamte Feature verantwortlich ist, darin besteht, dass die Person möglicherweise nur in der Frontend- oder Backend-Entwicklung besonders stark ist, aber nicht in beiden, was manchmal zu einer Verringerung von Geschwindigkeit und Qualität führt.

Frontend- und Backend-Entwickler für ein Feature erhöhen die Geschwindigkeit des Features und die Qualität UND fördern die Zusammenarbeit. Ich bin jedoch besorgt darüber, dass zwei Ingenieure an einer Funktion arbeiten, was möglicherweise zu einem schlechten Ressourcenverbrauch führt, da der eine Ingenieur für eine andere Funktion eingesetzt werden kann, an der gearbeitet werden soll.

Was ist die gängige/bewährte Methode für die Zuweisung von Backend-/Frontend-Engineering-Ressourcen bei einem kleinen Startup in einem frühen Stadium? Und wie wird es sich dann ändern, wenn es wächst?

31
lamp_scaler

Hier ist meine Weisheit aus 14 Jahren Erfahrung:

  • wenn Sie ein Startup haben, weisen Sie keine Rollen zu. Besser hoffen, dass Sie ein gutes selbstorganisierendes Team zusammengestellt haben. Wenn sich alle kennen, weiß jeder, wer was am besten kann. Ein Projektmanager steht nur im Weg.
  • später macht die Unterscheidung zwischen Frontend und Backend Sinn. Im Backend steht Qualität an erster Stelle. Code muss performant, sicher und transaktionssicher sein. Im Frontend ist die Implementierungszeit wichtig. Und Sie müssen sich auf ein gutes Backend verlassen können. Die unterschiedlichen Ziele von Front- und Backend funktionieren nicht gut zusammen.
  • das Back-End sollte bereits vorhanden sein, bevor der Front-End-Codierer zu arbeiten beginnt. Andernfalls wird der Front-End-Codierer zu stark verlangsamt.
  • das Backend muss in der Lage sein, schnell auf Front-End-Anforderungen zu reagieren, um sie nicht zu verlangsamen
30
rdmueller

Die beste Antwort kommt von @Shark, aber nur der letzte Teil "Es kommt darauf an." Nach meiner Erfahrung von ungefähr 16 Jahren habe ich beide Optionen in verschiedenen Konfigurationen versucht. Als Full-Stack-Entwickler habe ich Folgendes gelernt:

* (BE = Back End, FE = Front End)

Allgemeine Vorsichtsmaßnahmen bei der Entwicklung von Split-Stacks:

  1. Agile Entwicklungspraktiken (heutzutage eine gängige Strategie) empfehlen die Entwicklung von Funktionen, bei denen die Funktion aus Kundensicht ein einziges wertvolles Funktionsfutter darstellt. Aus dieser Perspektive sollte Ihr Entwickler beide implementieren.

  2. Durch Aufteilen des Stapels entlang der Servergrenze wird ein Integrationspunkt zwischen den beiden Entwicklern erstellt. Wenn sie nicht effektiv kommunizieren und gut zusammenarbeiten, führt dies zu einer Reihe von Fehlern, wenn die beiden Funktionen zusammenkommen.

  3. Wenden Sie die n (n-1)/2-Kommunikationsregel aus dem Mythical Man-Month an, und Sie werden sehen, dass die Aufteilung von Funktionen in zwei Teile zwischen zwei Personen Ihre Gesamtarbeitsbelastung erhöht. Zugegeben, diese Regel gilt auch für Features, aber das Aufteilen des Stapels verdoppelt den Kommunikationsaufwand.

  4. Ein Designer wird die Probleme von BE-Entwicklern lösen, die nicht in der Lage sind, attraktive Schnittstellen von Grund auf neu zu erstellen. Dies setzt voraus, dass sie zumindest HTML und CSS kennen und eine Benutzeroberfläche erstellen können, die den vom Designer erstellten Screenshots entspricht.

  5. Features sind normalerweise isolierte Komponenten, die nur sehr wenig mit anderen Features interagieren. Dies ist nicht immer der Fall, aber normalerweise befindet sich der Interaktionspunkt auf einer niedrigen Ebene wie bei einer Datenbank oder einem Dateisystem. Es gibt also nicht viel, was einen Full-Stack-Entwickler daran hindert, seine Funktion zu implementieren. Wenn ein FE-Entwickler jedoch auf einen BE-Entwickler warten muss, um eine Aufgabe abzuschließen, wird zusätzlich zu dem Produktivitätsverlust in Punkt 3 noch mehr Verzögerung hinzugefügt.

  6. Web2.0 verwischt die Unterscheidung zwischen FE & BE noch weiter. Da MVC-Frameworks und ganze Anwendungen clientseitig erstellt werden, ist jetzt viel BE-Wissen erforderlich, um sichere und effiziente FE-Anwendungen zu implementieren.

  7. Mein größter Kritikpunkt an dieser Praxis ist, dass sie die Fähigkeiten aller am Projekt Beteiligten einschränkt. Obwohl dies in den frühen 2000er Jahren eine gängige Praxis war, wurde dies aus der Notwendigkeit heraus getan, da es ziemlich schwierig war, Entwickler zu finden, die beides konnten (nur wegen der Neuheit, nicht wegen einiger intrinsischer Schwierigkeiten, beide zu lernen). Was von der Praxis übrig bleibt, ist Ein Jahrzehnt später haben wir immer noch "Webentwickler", die CSS nicht kennen.

  8. Mein zweitgrößter Kritikpunkt ist, dass es ein Entwicklungsteam leicht segmentieren kann. Ein FE-Entwickler erstellt nach dem Ändern des BE-Codes einen Fehler, und das Team stimmt ab, um die Cross-Stack-Entwicklung im Großhandel einzuschränken. Während Codeüberprüfungen und Aufklärung das Problem lösen könnten, werden die Menschen stattdessen territorial.

Vorteile/Anwendungsfälle der Split-Stack-Entwicklung:

  1. RESTful APIs sind perfekt für diese Abgrenzung, da es keine FE gibt. Oft arbeitet ein Unternehmen zuerst an einer RESTful-API und entwickelt dann seine Webanwendungen. In diesem Fall gibt es gute Gründe, das BE-Team auf die nächste Hauptversion zu konzentrieren, während die FE die Anwendung beendet. Die Gefahr der Abwanderung besteht jedoch weiterhin - insbesondere dann, wenn neue Informationen, die in der FE-Entwicklungsphase entdeckt wurden, nicht triviale Änderungen an der BE-API erfordern.

  2. Unausgeglichene Arbeitslasten zwischen FE & BE sind auch ein guter Fall für die Schaffung eines FE-Teams. Auch dies ist sehr situativ, wenn die Hauptentwicklung möglicherweise über eine Desktop-Anwendung erfolgt und das Unternehmen versucht, eine 'Lite'-Weboberfläche zu entwickeln.

  3. Schulung neuer/junger Entwickler. Wenn Sie einen Praktikanten oder einen Junior-Entwickler einstellen und sich Sorgen machen, ihn in die Tiefe zu treiben, ist es eine gute Option, einen Teil dieser Kommunikations-/Integrationskosten in ein Peer-Entwicklungssystem zu investieren.

Bedenken hinsichtlich der von @ Ralf akzeptierten Antwort auf dieser Seite:

  1. Der erste Punkt ist ziemlich kühn - und er wird schnell scheitern, wenn Sie nicht eines dieser "guten selbstorganisierenden Teams" haben. Selbst wenn Sie dieses Team haben, liegt es in Ihrem und ihrem Interesse, ihre Grenzen zu erweitern. Und gute selbstorganisierende Teams sind nicht immer selbst motiviert, dies zu tun.

  2. Ihr zweiter Punkt ist einfach falsch. Moderne Webentwicklung erfordert FE-Code, der performant, sicher, asynchron, sicher, XSS-sicher, browserübergreifend und schnell entwickelt ist. Die Ziele konkurrieren einfach nicht mit BE, sie sind effektiv gleich.

  3. Der dritte Punkt ist ebenfalls eine schlechte Annahme - die FE-Entwicklung kann mit reinem HTML/CSS/JS ohne BE-Grundlagenarbeit beginnen. Von dort aus ist es nur eine triviale Anstrengung, es in Vorlagen für das BE-Rendering zu zerlegen. Oft ist es am besten, mit der FE-Arbeit zu beginnen, da dies den Stakeholdern ein warmes und verschwommenes Gefühl vermittelt, den visuellen Fortschritt im Voraus zu sehen.

Fazit:

Wenn Sie ein Startup sind und nicht viel Zeit oder Geld zum Brennen haben, sollten Sie keine FE- oder BE-Entwickler einstellen. Stellen Sie hochrangige Webentwickler und einen guten UX/Designer ein, damit Ihre Anwendung so schnell wie möglich in Betrieb genommen werden kann. Sie kosten mehr, sind aber weitaus produktiver und Sie benötigen weniger davon.

26
Marcus Pope

Ich denke die Frage ist falsch.

Alle Startups, an denen ich teilgenommen habe, hatten keine FE-BE-Architektur.

Die meisten Startups, die ich kenne, haben:

  • Kern - das eigentliche Produkt, das eine Schnittstelle verfügbar macht
  • UI - BE und FE. Das BE verwendet die API des Kerns.

APIs sind zustandslos und können leicht verspottet werden - auch ohne die Notwendigkeit eines Core-Entwicklers. Zum Teufel, wenn ich ein Projekt von Grund auf neu starten müsste, könnte ich mit einer ganzen Benutzeroberfläche beginnen, die nur mit Mocks funktioniert - was sich hervorragend für Präsentationen eignet. Das meiste Feedback ist auf die Benutzeroberfläche zurückzuführen. Kunden bemerken, dass mehr hängt von Ihrer Zielgruppe ab.)

Beispiel: Die Google-Suche verfügt über die Kernkomponente, mit der das Web gecrawlt, indiziert usw. wird. Die Google-Benutzeroberfläche ist eine völlig andere Welt. Dieser Kern kann problemlos Nicht-WWW-Suchvorgänge unterstützen, die Benutzeroberfläche jedoch nicht.

Auf diese Weise ist Ihre Benutzeroberfläche "steckbar" und Sie haben Bedenken.

Sie haben sich auf Entwicklungswissen bezogen, übersehen jedoch Aspekte des Projektmanagements. Während das Kernteam möglicherweise eine Sprintdauer von 2 Wochen benötigt, verwendet das UI-Team CI - alles wird ständig hochgeladen. Das Kernteam benötigt Abwärtskompatibilität, die Benutzeroberfläche nicht.

Die Sprache ist unterschiedlich. Sie werden wahrscheinlich C-Entwickler für die Core-Komponente benötigen - und Sie werden in Ordnung sein, wenn sie auf einem einzelnen Betriebssystem ausgeführt wird, wobei die Benutzeroberfläche in einer betriebssystemübergreifenden Sprache geschrieben wird.

Tests unterscheiden sich. Die UI-Testwelt ist eine der komplexesten, die ich in der Softwareentwicklung kenne. Die meisten Startups vernachlässigen dies und bedauern diese Entscheidung später. Sie können BE und FE beim Testen nicht trennen. Es muss eine einzelne Einheit sein, die damit umgeht.

Open Source-Benutzeroberfläche - Einer der größten Vorteile der Trennung der beiden ist, dass Sie Ihre Benutzeroberfläche als Open Source-Benutzeroberfläche verwenden können. UI-Projekte benötigen Open Source-Unterstützung.

Ich kann mir keinen UI-Entwickler vorstellen, der die Funktion --- (gesamtsession nicht verstehen kann. Sie wissen, wo Sie sich anmelden und zwischen verschiedenen Anforderungen angemeldet bleiben. Zwar wissen sie vielleicht PHP und nicht Java .., aber das BE-Konzept sollte klar sein (z. B. ein verschlüsseltes Cookie verwenden). Die spezifische Sprachbarriere ist falsch - jeder Entwickler sollte bereit sein, in einem beliebigen zu arbeiten Wer hätte gedacht, dass sie BE vor ein paar Jahren in JavaScript schreiben würden?

Wenn Sie weiterhin 3 Teams haben: Core, BE und FE, ist dies imho eine Verschwendung von Ressourcen. Was ist mit DB? sollten Sie DBAs haben? Warum sollte ein BE-Entwickler DB kennen und ein FE-Entwickler BE und DB nicht kennen? Es gibt keine Grenzen.

Wenn Sie Experten benötigen und dies auch tun, funktioniert das Outsourcing ziemlich gut. Sie liefern normalerweise Qualitätscode und tun dies ziemlich schnell. Sie wollen sie nicht unbedingt im Haus haben, weil Sie sich verlaufen, wenn sie gehen. Außerdem können Sie heute online großartige Ratschläge erhalten. Für hochmoderne Produkte ist möglicherweise ein anderer Ansatz erforderlich.

Das Ergebnis ist also im Grunde ein sehr dünnes BE in der Benutzeroberfläche, das jeder FE-Entwickler entwickeln kann. Wenn Sie ein dickes BE in der Benutzeroberfläche haben, verfügen Sie höchstwahrscheinlich über einige API-Funktionen, die im Core erforderlich sind.

Es gibt immer mindestens einen Entwickler, der sich von den anderen abhebt. Angesichts einer so dünnen FE kann er/sie es schaffen, andere Entwickler in BE-Code zu unterstützen (nicht zu entwickeln). Meiner Meinung nach ist dieser Entwickler in einer sehr guten Position und sollte angemessen ausgezeichnet werden (allerdings nicht im Gehalt, etwas anderes). Ich vertraue auch darauf, dass sie in der Lage sein werden, den Build-Prozess zu handhaben und richtig zu bauen.

Dieses Modell bietet Ihnen eine große Flexibilität bei der BE-Entwicklung. Die BE-Welt hat in den letzten Jahren mehrere Turnarounds erlebt, daher empfehle ich, mich sowieso nicht zu sehr auf die BE-Stabilität zu verlassen. Kern ist eine andere Geschichte.

Es bleibt noch die Frage - sollten FE und BE gleich sein Projekt? Sie sollten Folgendes beachten

  • Statische Ressourcen werden am besten vom Front-Server aus bereitgestellt. Da Front-End-Server (z. B. Nginx) sehr leistungsfähig sind und Sie den Cache für statische Ressourcen verwenden können, können Sie Ihre statischen Ressourcen mit einer einzigen Bereitstellung verwalten (dies sollten alle HTML-Inhalte, JS, CSS, Bilder sein).
  • Backend-Code hat nicht den gleichen Luxus, daher müssen Sie über ein verteiltes System verfügen, das auch von einem Front-Server verwaltet wird.
  • FE-Code muss unbedingt mit allen neuen Technologien wiederverwendet werden, die JavaScript unterstützen. Sie können jetzt Desktop- und Mobile-Anwendungen mit JavaScript schreiben.
  • Der Erstellungsprozess ist völlig anders - und das kann sogar die Bereitstellung, Aktualisierung, Installation usw. von Patches umfassen.

Ich kann weitermachen, aber ich hoffe, es ist klar, dass BE und FE das gleiche Team sein sollten, aber vielleicht unterschiedliche Projekte.

5
guy mograbi

Ich denke, die erfolgreiche Implementierung könnte ein paar Dinge sein. Wenn es einen einzigen Entwickler gibt, der ein starkes Backend hat, aber auch ein gutes Verständnis für die Benutzeroberfläche und alle "Front-End" -Stücke hat, dann könnte dies wahrscheinlich erfolgreich sein. Dies ist jedoch normalerweise nicht der Fall (nach meiner persönlichen Erfahrung). Zum Beispiel betrachte ich mich als Back-End-Entwickler. Aber ich arbeite selbst an vielen Projekten. Arbeite ich an der Präsentation und den clientseitigen Stücken? Sicher. Sehen sie so gut aus, wie es ein wirklich talentierter Designer und clientseitiger Entwickler machen würde? Absolut nicht.

Es ist alles Geben und Nehmen. Aber lassen Sie sich nicht von der Zusammenarbeit zweier Entwickler zögern. Es gibt bewährte Möglichkeiten, die Produktion zwischen einem Entwickler und einem Designer zu maximieren.

Mit anderen Worten ...Es kommt darauf an

0
user29981