Frontend bei Sportmaster Lab

Hallo! Mein Name ist Sergey, ich bin der Leiter der Front-End-Entwicklungsabteilung. Zu einer Zeit, als Profil-Offline-Konferenzen üblich waren, hatten wir Abzeichen: den Namen des Unternehmens - "Sportmaster" - Vor- und Nachname. Wenn Kollegen anderer Unternehmen auf uns zukamen, waren sie überrascht, als sie sich diese Abzeichen ansahen: "Sportmaster" ist ein Geschäft, das Sportgeräte verkauft. Was hat die IT damit zu tun?



Nur wenige Menschen wissen, dass Sportmaster eine ganze Gruppe von Unternehmen vereint, darunter Ostin, FunDay und andere. Die SMLab-Abteilung, die fast 1.500 Mitarbeiter beschäftigt, ist für die Aufrechterhaltung des Betriebs dieser gesamten Maschine verantwortlich. Davon sind etwa 400 Entwickler und 25 bis 30 Front-End-Entwickler. Der Rest ist in den IT-Support für Fertigung, Logistik, Finanzen involviert. Dazu gehören auch die Abteilungen Webentwicklung, Qualitätssicherung und viele andere.



Alle unsere Entwickler machen ungefähr das Gleiche wie Kollegen in anderen großen Unternehmen: Entwicklung neuer Systeme und Wartung alter Systeme. Wir haben einen sehr großen Technologie-Stack sowie einen großen Anwendungsbereich, den wir unterstützen und entwickeln. Auf unseren Schultern liegt die Entwicklung und Unterstützung solcher Websites: Sportmaster, Ostin, FunDay, Columbia, Fila, Demix, UrbanVibes. Darüber hinaus haben wir ein großes Standbein für die interne Automatisierung. Im Allgemeinen gibt es für Entwickler einen Ort, an dem sie ihre Fähigkeiten einsetzen können.



Interne Küche



Bild








Wie ich bereits den Entwicklern in unserer Abteilung mit etwa 400 Mitarbeitern sagte, hat das Unternehmen vor zwei Jahren einen Transformationsprozess gestartet, um eine so große Abteilung effektiv zu verwalten. Jetzt arbeiten wir an Agile, wir haben derzeit etwa 30 Produktteams und bis zu 100 werden voraussichtlich ihre Projekte entwickeln und warten. Jedes Team verfügt über eine Vielzahl von Kompetenzen: Unternehmen, Analysten, Entwickler, Tester, Automatisierungsingenieure und Methodologen. Wir haben ein spezielles Portal erstellt, in dem wir Teammetriken verfolgen und Methodologen wiederum Teams beim Einrichten von Flows unterstützen. Sobald das Team unabhängig genug ist, wechseln die Methodologen zu anderen Teams.



Frontend wurde in seinem guten Verständnis vor zwei oder drei Jahren in SMLab geboren. Davor gab es einen Zoo von Frameworks, eine große Anzahl verschiedener Bibliotheken wie Knockout, JQuery. All dies führte zu zahlreichen Einschränkungen bei der Entwicklung, der Suche nach neuen Mitarbeitern und der Rotation zwischen den Projekten.



Als erstes haben wir die gesamte Software des Unternehmens zerlegt, woraus sie besteht und worauf sie geschrieben sind, und ein technologisches Radar erstellt, dank dessen wir derzeit die Liste der verfügbaren Technologien im Unternehmen kontrollieren. Wir haben klare Regeln für das Hinzufügen neuer Technologien zur Liste der verfügbaren. Wenn neue Technologien in das Radar eingeführt werden müssen, wird ein RND gebildet und ein Team von Spezialisten für die Durchführung dieser Studie eingestellt. Basierend auf den Ergebnissen erstellt das Team eine Präsentation der Technologie, erstellt die RND-Dokumentation und verteidigt sie anschließend im technischen Komitee. Wenn das Komitee entscheidet, dass eine Technologie für die weitere Entwicklung wichtig ist, erweitert es den Umfang der verfügbaren Technologien im gesamten Unternehmen.



Wir haben auch viel über die Wahl des Frameworks für das gesamte Unternehmen recherchiert, was zur Wahl von Vue führte. Jetzt wird neue Software darauf geschrieben und alle alten werden nach und nach neu geschrieben.



Für den gesamten Sportmaster verwenden wir mehr als 200 Systeme, die alle internen Aktivitäten des Unternehmens automatisieren. Zum Beispiel haben wir den gesamten Merchandising-Geschäftsprozess automatisiert: das Anzeigen von Waren im Geschäft, das Überprüfen usw. Jetzt arbeiten wir an der Automatisierung von Fotostudios und einem Callcenter. Viele Leute sind in diesem Bereich involviert.



Der gesamte E-Commerce in Sportmaster ist in zwei große Gruppen unterteilt:

Die erste Gruppe sind die riesigen Websites: Sportmaster und Austin, und die zweite Gruppe besteht aus gleich wichtigen Websites, jedoch mit viel geringerer Auslastung, wie FunDay und der Gruppe von Monomarken-Websites.



Ostin war der erste Riese, der sich ausschließlich mit neuen Technologien wie NodeJS, Vue, SSR, Kotlin usw. befasste. und ging in Produktion. Die aktuelle Version der Sportmaster-Website wurde vor ungefähr 4 Jahren geschrieben. Jetzt wird eine neue Version 3.0 für neue Technologien mit neuem Design entwickelt, die bald die alte ersetzen wird. Ähnlich verhält es sich mit der Funday-Site aus der zweiten Gruppe. Die Site wird derzeit aktiv mit einem neuen Stack entwickelt. Wir werden bald eine neue Site sehen.



Die Monomarken-Site-Gruppe war die zweite Iteration der Site-Entwicklung auf dem neuen Stack. Ich wurde in der Phase seiner Gründung vorübergehend in das Team eingeführt und hatte die Position eines Teamleiters inne. Derzeit habe ich das Team verlassen und arbeite weiterhin als Kurator mit dem Team zusammen.



Monobrand-Websites



Bild



Ein kleiner Hintergrund. Bevor ich zur IT wechselte, war ich ungefähr 5 Jahre im Geschäft tätig. Mehr als einmal stieß ich auf neu erstellte Software, von der aus man das Gefühl hatte, dass Programmierer sie ausschließlich für sich selbst schreiben. Und dann kam ich zu dem Schluss, dass das Produkt für alle geeignet sein sollte: für Benutzer außerhalb und für alle Teilnehmer am Entwicklungsprozess von innen.



Als Mono-Brand-Sites an der Reihe waren. Tatsächlich haben mein Team und ich einen Monat vor Beginn der Entwicklung Websites untersucht, die bereits von anderen Unternehmen erstellt wurden, und zwei Hauptprobleme herausgearbeitet.



Erstens vernachlässigen Unternehmen Benutzerkennzahlen: Wir haben festgestellt, dass beispielsweise eine Produktkarte 20 Sekunden lang geöffnet wird und jeder Filter 10 bis 15 Sekunden lang angewendet wird. Das heißt, es stellt sich nicht als Kauf heraus, sondern als eine Art Kampf mit der Website.



Zweitens gibt es Probleme mit der Anzeige der Site auf Mobilgeräten. Sie sind alle krumm.



Als wir an die Reihe kamen, haben wir zunächst ein Komponentendiagramm erstellt, alle Blöcke und Verbindungen gezeichnet, die hätten sein sollen, und dann begonnen, jeden Block einzeln und seine Verbindungen mit anderen Blöcken zu optimieren. Wir waren uns mit dem Backend einig, dass die gesamte Logik, die mit Microservices, Berechnungen, notwendigen Aggregationen usw. arbeitet, auf ihre Schultern fällt und die Front sich mit der Anzeige und Logik der Interaktion mit Benutzern befasst.



Dank dessen haben wir die Größe der Antwort minimiert und die API erheblich standardisiert, was dem Team die Navigation im Prozess erleichtert und uns bei der Arbeit an neuen Funktionen sehr schnell auf einen Vertrag einigt.



Im zweiten globalen Geschäft haben wir im Team diskutiert und vereinbart, wie wir mit der Anwendungsstatik arbeiten. Static verursachte uns mehr als einmal Probleme bei anderen Projekten, als es plötzlich unüberschaubar wurde und seine Größe in Gigabyte berechnet wurde. Im Allgemeinen haben wir vereinbart, diesen Ordner zu verlassen: Er wird automatisch von unserer Anwendung generiert und gesammelt. Das Projekt ist bereits ungefähr ein Jahr alt und alle statischen Daten wiegen nicht mehr als 30 MB.



Als wir zum Layout kamen, beschlossen wir, die Entwicklung so durchzuführen, dass kein Code dupliziert wurde. Wir haben das Layout erstellt, damit wir es an verschiedene Geräte anpassen können. SEO-Spezialisten haben in dieser Angelegenheit großartige Arbeit geleistet und festgestellt, welche Blöcke von der SEO abhängig sind und welche nicht. Wir haben das kritische CSS hervorgehoben. All diese minimalen Aktionen haben dazu geführt, dass die Seite auf der Monomarken-Website im Durchschnitt nicht mehr als 20 KB wiegt und fast sofort geöffnet wird.



Es gab auch unerwartete Ergebnisse. Zu Beginn des Projekts haben wir begonnen, die Dokumentation nicht in der Form zusammenzustellen, wie sie normalerweise jeder schreibt, mit einer Liste der Komponenten und einer Liste ihrer Funktionen. Wir haben alles im Allgemeinen dokumentiert: Startbefehle, Abhängigkeiten, Umgebungen, Codestile usw. Und das alles im Großen und Ganzen nur für sich. Aber als alles gerade erst anfing, waren fünf Leute im Projekt, und jetzt sind es 20.



Und jetzt ist es für uns viel einfacher, neue Mitarbeiter auf den neuesten Stand zu bringen - wir lassen sie nur ein paar Tage lang die Dokumentation studieren, danach sind sie bereit, sich selbst auf Kampfeinsätze einzulassen.



All Articles