Senior Frontend Developer

1/2022 – 12/2022

Hierbei handelte es sich um ein sich bereits beim Kunden im Einsatz befindendes System zur Produktempfehlung anhand bestimmter Eingabeparameter. Des Weiteren gibt es hier einen geschützten Bereich mit Login-Funktion, Benutzerverwaltung und weiteren administrativen Funktionalitäten. Das Produkt ist Multisprachen-Fähig und unterstützt sowohl das metrische als auch das imperiale System. Es besteht aus mehreren Komponenten, einer MySQL Datenbank, einem PHP-Backend, einem Webkomponenten-basierten Frontend (lit-element), einer ReactNative-App, einer OAuth-konformen Authentifizierungs-Anwendung und einer Anwendung zum Bearbeiten der Übersetzungen.
Wir übernahmen das Projekt von einer anderen Agentur, ohne jegliche Art von Dokumentation, nur mit einer mündlichen Übergabe, mit dem Ziel des Bugfixings und der Feature-Weiterentwicklung. Zuerst sorgte ich dafür per Docker eine dokumentierte, lokale Entwicklungsumgebung zur Verfügung zu stellen um im Anschluss das Bugfixing und die Feature-Entwicklung mit zwei Entwicklern zu koordinieren. Um eine funktionierende, produktive Anwendung garantieren zu können, entschieden wir uns vor dem Go-Live der Änderungen ein Staging-System hochzufahren, welches ich aufsetzte und ein simples Deployment via git-hooks einrichtete.
Bei der NativeScript-App entschiedene wir uns aus Gründen einer sehr veralteten Codebasis und des geringen Umfangs, diese mit einer moderneren Technologie, Flutter, neuzuschreiben. Dazu musste ich die Funktionalitäten mittels Reverse-Engineerings herausfinden und neu implementieren. Für das State Management verwendete ich GetX. Den Feedback-Prozess koordinierte ich anschließend mit dem Kunden um eine qualitativ verbesserte App zu gewährleisten.
Nach dem Bugfixing der Web-Anwendung koordinierte ich die Feature-Entwicklung dieser. Wir entschiedene uns aufgrund der Tatsache, dass das entsprechende Feature die Datenbasis ändern können sollte, die Funktionalität mittels automatisch integrierten E2E-Tests (Cypress) sicherzustellen.

Angewendete Tools/ Technologien: TypeScript, Webkomponeneten (lit-element), Redux, Webpack, Flutter, GetX, Docker, MySQL, Apache 2, PHP, OAuth, REST, GitLab

DevOps, mySQL, PHP, React (JavaScript library), Softwareentwicklung (allg.)

7/2021 – 12/2021

Das Projekt war als Neuentwicklung angesetzt. Die Anwendung war als tablet-optimierte Browseranwendung angesetzt und sollte über einen Login-Bereich, den eigenetlichen Preisrechner für die Kunden, einen Feedbackbereich und einen administrativen Bereich zum Verwalten der User verfügen.
Zusammen mit dem Kunden kümmerten wir uns um die Konzeption, Projektplanung, Design und Umsetzung. In Zusammenarbeit mit dem Produkt-Owner konzipierte ich die Anwendung und sprach den Feature-Umfang mit dem Kunden ab um den vorgegebenen Zeitplan einhalten zu können. Anschließend designte ich die Anwendung anhand der CI des Unternehmens mithilfe von Figma und Material UI.
Ich traf die Entscheidung über die Infrastruktur und die zu verwendenden Technologien. Dabei viel meine Wahl aufgrund der Datenstruktur auf MySQL, als REST-Backend verwendete ich Nest.JS, als SQL-client typeorm und für die Authentifizierung mittels JWT Passport.js. Das Frontend schrieb ich mit React (tsx) und Material UI für React. Um eine gute Dokumentation zu gewährleisten, entschied ich mich komponentenbasiert zu arbeiten und diese mittels Storybook zu dokumentieren.
Um eine möglichst autarke Entwicklung zu gewährleisten definierte ich zuerst die API mit dem OpenAPI-Schema und setzte eine lokale Entwicklungsumgebung mittels Docker auf. Dabei setzte ich einen sogenannten Mock-Server auf, der anhand des API-Schemas Dummy-Endpunkte zur Verfügung stellte, damit das Frontend parallel zum Backend entwickelt werden konnte. Ich koordinierte die Entwicklung des Backends und entwickelte die Frontend-Komponenten selber. Nach Fertigstellung dieser Schritte, stellte ich das Frontend zusammen mit zwei Entwicklern fertig. Den Feedback-Prozess mit dem Kunden koordinierte ich anschließend.
Mittlerweile ist die Anwendung bei rund 200 internen Mitarbeitern im Einsatz.

Angewendete Tools/ Technologien: TypeScript, Nest.JS, Passport.js, React, Redux, Storybook, Material UI, Figma, MySQL, Docker, Nginx, GitLab

Node.js, React (JavaScript library), Responsive Webdesign, Software Architektur / Modellierung, Software Design, Softwareentwicklung (allg.), TypeScript

4/2021 – 9/2022

Das Herzstück vom Kunden ist das Windel-Abonnement. Dieses kann über die Webseite mit dem sogenannten “Konfigurator” erworben werden. Dieser sollte grundlegend verändert werden um mehr Flexibilität zu ermöglichen, was eine Neuentwicklung nötig machte. Diese Neuentwicklung war rein Frontend-seitig und wurde mit Vue 2.6 und Redux erstellt. Getestet wurden die Funktionalitäten mit Jest. Da mehr als 50% der Nutzer den Service über das Smartphone nutzten, erfolgte die Entwicklung auch mobile-first.

Außerdem war ein solcher Konfigurator auch für ein weiteres Produkt zukünftig angedacht. Das war der Grund warum ich in enger Zusammenarbeit mit den anderen Frontendlern in meinem Team und dem Design-Team eine Vue-Komponenten-Bibliothek einrichtete. Gebaut wurden die Komponenten mit Rollup, veröffentlicht wurden sie mit GitLab-Pipeline und Lerna. Ich verwendete conventional commits um automatisch zu versionieren und changelogs zu generieren. Dokumentiert wurden die Komponenten mit Storybook. Außerdem richtete ich darauf basierend Chromatic ein um bei jedem merge request die Änderungen visuell zu testen. Logisch getestet wurden die Komponenten mit Jest. Außerdem richteten wir mit dem Design-Team ein wöchentliches standup ein, damit wir regelmäßig über entsprechende Anpassungen am Design die aus der Erstellung dieser Komponenten-getriebenen bzw. sich am Atomic Design anlehnenden Entwicklung ergeben, besprechen konnten. Ich beriet andere Entwickler regelmäßig und zeigte wie diese Bibliothek verwendet werden kann und was es für neue Komponenten gibt. Auch dafür richteten wir ein regelmäßiges, zweiwöchentliches, teamübergreifendes Meeting ein.

Wir arbeiteten in zweiwöchigen Sprints nach dem SCRUM-System. Zusätzlich definierten wir zwischenzeitliche Meilensteine, für die wir eigene Feedback-Phasen mit dem Design-Team hatten. Im Nachhinein haben wir die Erkenntnis gewonnen, dass wir hier hätten mehr mit den Stakeholdern kommunizieren müssen. Sowohl was die Änderungen bezüglich der Komponenten als auch was die zwischenzeitlichen Feedback-Phasen angeht. Das sorgte am Ende doch für ein etwas anderes Ergebnis als das, was anfänglich kommuniziert wurde, und dadurch konnte es die Erwartungen teilweise nicht erfüllen, was die finale Feedback-Phase deutlich langwieriger und chaotischer gestaltete als nötig. Bei dieser verwendeten wir Asana, was durch ein intelligenteres tooling, wie Userback, deutlich einfacher hätte gestaltet werden können.

Heute befindet sich der neue Konfigurator hier im Einsatz: -Hyperlink entfernt-. Täglich nutzen ihn mehrere hundert Kunden und er hat eine Conversion-Rate von über 30%.

Nach Livegang setzte ich mich dafür ein, dass das Nutzerverhalten detaillierter erfasst wird und erstellte daraufhin in Zusammenarbeit mit dem Marketing-Team Ansichten in Google Analytics damit man das Nutzerverhalten in Zusammenhang mit den neuen Funktionalitäten des Konfigurators analysieren kann. Zusätzlich setzte ich auch AB-Testing mit Google Optimize auf um neue Features datengetrieben entwickeln zu können.
Außerdem sorgte ich dafür, dass all die clientseitigen Anwendungen Sentry nutzen um Fehler zu erkennen sobald sie auftreten.

Angewendete Tools/ Technologien: JavaScript, Vue 2.6, Redux, Rollup, Lerna, Storybook, Chromatic, REST, GitLab, GA4, Google Optimize, Sentry

SCRUM, Softwareentwicklung (allg.), Vue.js

12/2015 – 3/2021

found in reference description 6
Neuentwicklung Kontowechsel-Service 05.2020 - 03.2021
Der Kontowechselservice war das Herzstück der [...] GmbH. Über die Jahre hatte sich viel technische Schuld angesammelt, der Code war veraltet und auch die Optik war nicht mehr zeitgemäß. Aus diesen Gründen begannen wir mit einer kompletten Neuentwicklung des Kontowechselservices, ich war hierbei verantwortlich für den Frontend-Teil.
Großen Wert wurde hierbei, aufgrund der hohen mobilen Nutzerzahlen, auf eine responsive Anwendung gesetzt.
Hierfür wurde als Frontend-Framework Angular verwendet. Alle Komponenten kamen aus der unten separat erklärten UI Library, basierend auf Bulma. Ein Teil des Kontowechselservices war der Kontologin. Dieser war bereits entwickelt und war eine separate Anwendung mit eigenem Front- und Backend, das Frontend ebenfalls basierend auf Angular. Hier wollten wir allerdings nicht mit einem redirect in diese Anwendung und zurück arbeiten, da das die UX negativ beeinflussen könnte. Also wählte ich hierbei den Ansatz der Micro-Frontends. Ich bettete die Kontologin-Anwendung per git submodule ein und importierte ihr AppModule per lazyloading als separate Route. So wurde der Kontologin automatisch in die Kontowechselservice-Anwendung beim build integriert. Wollte man diesen updaten, musste man nur den entsprechenden git branch aktualisieren.
Eine weitere Besonderheit war das UI-Fehlerhandling. Dieses leitete automatisch auf eine Fehlerseite sollte ein Backend-Fehler auftreten, der nicht gehandelt wurde, von welcher man den Prozess neustarten konnte. Es gab allerdings entsprechende Komponenten und directives, die einen Fehler fangen und handeln konnten und im Fehlerfall ihren content automatisch renderten.
Für das State Management verwendeten wir simple Dekoratoren, da dieser nicht sehr komplex war und somit kein Framework notwendig.
Der Kontowechselservice ist eine B2B-Anwendung und wird von vielen verschiedenen Banken eingesetzt. Ein Beispiel dafür ist hier zu finden: -Hyperlink entfernt-. Deshalb unterstützt er auch whitelabeling. Dafür werden die ebenfalls in der UI Library enthaltenen Styles bei jedem build für verschiedene Mandanten gebaut und anhand eines Host-Matchings zur runtime geladen. Diese Build-Mechanik unterstützt auch Vererbung um das Duplizieren von Konfigurationen zu verhindern.
Für das testing der Anwendung setzten wir ein E2E-Test-Tool, endtest.io, ein, mit dem auch jeden einzelnen Mandanten abgetestet haben.
Als Entwicklungsmodus verwendeten wir klassisches SCRUM mit 14-tägigen Sprints, wir waren ein Team aus 3 Backend-Entwickler, zwei Frontend-Entwicklern, zwei Designer und einem Product-Owner.

Im Zuge des Kontowechselservice-Neuentwicklung entwickelte ich auch verschiedene Angular Schematics Module um die Installation von bestimmten Basis-Funktionalitäten, wie Internationalisierung und Mandantenfähigkeit, mit einem CLI-Befehl bei neuen Anwendungen zu ermöglichen.

Angewendete Tools/ Technologien: TypeScript, Angular, Bulma, Micro-Frontend, REST, GitLab, Docker, Kubernetes

UI Library 06.2019 - 03.2021
Im Zuge einer rasant wachsenden Anwendungslandschaft entschieden wir uns Atomic Design zu adaptieren und eine einheitliche Komponenten-Bibliothek zu implementieren. Hierbei war ich der Hauptverantwortliche und kümmerte mich um die allgemeine Architektur, die Implementierung der ersten Komponenten, die Dokumentation und das Einweisen der anderen Entwickler.
Die Komponenten-Bibliothek bestand zum einen aus den Grundlegenden Styles, die als Basis das Framework Bulma verwendeten, einfache, atomare Komponenten wie Buttons oder Input-Felder und komplexere Komponenten wie eine Autocomplete-Banksuche oder ein Translation-Modul. Alle Komponenten basierten auf Angular und wurden mit dem “ng”-Befehl generiert. Zum Bauen verwendeten wir den ng-packagr für Libraries. Aufgrund der Whitelabel-Fähigkeiten der Anwendungen, konnte die Styles nicht vorgebaut werden, sondern wurden als SCSS integriert und dann von jeder Anwendung separat gebaut. Alle Komponenten und die Styles wurden unter einem npm scope einzeln veröffentlicht. Sie befanden sich alle in einer Storybook-Anwendung, in der sie entwickelt wurden oder konnten per npm link direkt in der Zielanwendung entwickelt werden. Gepublisht wurden sie per GitLab-Pipe und Lerna. Lerna kümmerte sich dabei darum, dass eventuelle voneinander Abhängige Pakete in der richtigen Reihenfolge gebaut werden, sowie um die automatische Versionierung und das Generieren der changelogs mittels conventional commits.
Wir verwendeten unser eigenes Icon-Set, welches wir per icomoon pflegten und in das Style-Package der Bibliothek inkludierten.
Nachdem die Basis dieser Komponenten-Bibliothek fertiggestellt war und die wichtigsten Komponenten wie Form-Felder und Buttons existierten, rief ich ein regelmäßiges Treffen aller Frontendler ins Leben um ihnen die Verwendung der Bibliothek zu erklären und zu besprechen in welchen Fällen sie eingesetzt werden soll, was momentan entwickelt wird und über eventuell für die Bibliothek relevante Neuentwicklungen zu sprechen. Das Einbinden in bereits bestehende Projekte gestaltete sich dabei als sehr schwierig, da oftmals die Zeit fehlte grundlegende Dinge wie Buttons oder Form-Felder auszutauschen. Auch war des Öfteren die Dokumentation nicht ganz vollständig, was ein Weiterkommen ohne mich unmöglich machte und den Prozess verlangsamte. Um dem entgegenzuwirken bot ich regelmäßige Pair-Programming-Sessions den Entwicklern an um sie bei der Einbindung direkt zu unterstützen und fehlende Dokumentation in Zuge dessen nachzutragen.
Am Ende wurde die Bibliothek bei fast allen älteren Projekten verwendet und war Standard bei Neuentwicklungen.

Angewendete Tools/ Technologien: TypeScript, Angular, Lerna, Storybook, GitLab, conventional commits, icomoon

Mandantenverwaltung 09.2019 - 03.2020
Aufgrund der Whitelabel-Fähigkeit der Anwendungen von fino ergab sich schnell eine hohe Anzahl an JSON-Konfigurationen um die einzelnen Mandanten zu pflegen. Aus diesem Grund entschied ich ein selfhosted CMS aufzusetzen um eine bessere Übersichtlichkeit zu erreichen und die Konfiguration auf von nicht technisch affinen Leuten pflegbar zu machen. Nach einiger Zeit der Recherche fiel meine Wahl aufgrund der Flexibilität und des Feature-Umfangs auf das Tool Directus. Ich setze es in Zusammenarbeit mit unserem DevOps-Engineer in Kubernetes auf, richtete es ein und importierte per node-Skript alle Konfigurationen der JSON-Dateien. Des Weiteren baute ich einen Adapter um zur Build-Zeit die Konfigurationen zu laden und für die Frontend-Anwendungen die entsprechenden ge-whitelabelten Styles zur Verfügung zu stellen.
Späte baute ich mit Koa eine API um den Backend-Services die entsprechenden Konfigurationen zur Verfügung zu stellen und integrierte diese Schnittstelle auch.
Leider kam es beim finalen Einsatz durch Downtimes im Service, bei Directus direkt oder andere Probleme häufiger dazu, dass viele builds dadurch blockiert waren oder es in den Live-Systemen Fehler gab. Aufgrund der Tragweite dieser Funktionalität und des damit verbundenen Risikos durch die Komplexität eines weiteren Service und dessen Infrastruktur, entschieden wir uns letztendlich diesen Ansatz nicht weiter zu verfolgen. Im Nachhinein bin ich der Überzeugung, dass man zu diesem Entschluss hätte deutlich früher kommen können, wenn man ihn end to end erstmal für einen Mandanten eingebaut hätte, anstatt es direkt für alle zu versuchen.

Angewendete Tools/ Technologien: JavaScript, Directus, REST, JSON, node

Finanzmanager 08.2017 - 04.2020
Das Projekt Finanzmanager war eine Webanwendung und App, welche auf Basis der Kontotransaktions-Daten des Benutzers automatisch seine finanzielle Situation einschätzen und verbessern sollte. Angefangen haben wir damit aus den Transaktionen die Verträge des Benutzers zu erkennen und ihm seine monatlichen Vertragsausgaben anzuzeigen. Wir arbeiteten dabei mit der Microservice-Architektur, die Kontoverbindung, die Vertragsanalyse, die Finanzmanager-API, all das waren eingeständige Services. Geschrieben waren die Services in Go, die API in TypeScript und benutzte das Framework Koa. Als Datenbank wurde von der API eine mongoDB verwendet. Als Übertragungs-Technologie entschieden wir uns aufgrund der Komplexität der Daten für graphQL, als Framework dazu nutzten wir im Backend wie auch in der Webanwendung Apollo.
Für die Webanwendung war ich verantwortlich und nutzt dafür die aktuelle Version von Angular. Für die UI entschied ich mich alle Styles selber zu entwickeln um eine möglichst Design-getreue Umsetzung zu garantieren. So lernte ich eine Menge über browserspezifisches Verhalten, browsernative Funktionalitäten, aber hatte gerade bei Inputfeldern und dem Layout sehr häufig mit Bugs zu kämpfen. Diese Entscheidung würde ich heutzutage so nicht mehr treffen.
Um bei dem mobilen Layout möglichst flexibel zu sein, entschied ich mich dazu zwei verschiedene Anwendungen zu produzieren, eine für mobile System und eine für Desktop-Systeme. Die Anwendung für mobile System nutzte dieselbe Codebasis wie die Desktop-Anwendung, hatte jedoch einen Schritt für dem eigentlichen build, der es möglich machte bestimmte templates der Desktop-Browseranwendung zu überschreiben. Anhand der Browserdimensionen wurde dann am Ende die jeweilige Anwendung geladen. Das hatte natürlich einige Nachteile, zum einen eine leicht verlängerte Boot-Zeit, zum anderen doppelte Build-Zeiten und erhöhte Entwicklungskomplexität.
Im Laufe des Projektes kam aus aufgrund fehlender Entwicklerkapazitäten auch ab und zu zu der Situation, dass ich bei verschiedenen Features im Backend aushelfen musste, damit ich im Frontend weitermachen konnte. Hier habe ich dann lieber mit angepackt um schneller voranzukommen als abzuwarten bis das Backend soweit ist.
Neben Änderungen meines Aufgabenfeldes, kam es im Laufe des Projektes auch zur Änderung des Nutzerfokus’. Startete der Finanzmanager anfänglich als B2C-Projekt, wurde daraus 2019 ein B2B-Pilotprojekt mit einer großen Bank. Diese verwendete unsere Vertragserkennungs-API um die Verträge des Benutzers direkt in ihrem Online-Banking anzuzeigen und leitete bei Interaktion damit dann auf eine ge-whitelabelte Version des Finanzmanagers, in der der Benutzer seine Verträge bearbeiten, vergleichen, wechseln und kündigen konnte. Das brachte natürlich neue Probleme in der Kommunikation mit der Webanwendung der Bank mit sich, die es zu lösen galt. Dabei sammelte ich auch Erfahrungen im Kundenkontakt als ich mit dem Kunden zusammen Features für diese Integration konzipierte.
Als letztes Feature baute ich eine Vertragsempfehlung, die anhand verschiedener vom Benutzer ausgewählten Kriterien, beispielsweise Geschwindigkeit und Preis bei einem Internetvertrag, den optimalen Vertrag für dich vorschlägt. Dabei sammelte ich erste Erfahrung in der Programmiersprache Go, da ich den Service für die Empfehlungen in dieser Sprache programmierte um ihn dann in der API anzusprechen.

Angefangen haben wir bei dem Projekt mit 4 Leuten im Kanban-Modus. Zwischenzeitlich waren es 12 Leute, wobei wir dann zu SCRUM mit 14-tägigen Sprints gewechselt sind.

Angewendete Tools/ Technologien: TypeScript, Angular, SCSS, Koa, Go, mongoDB, graphQL, Apollo, GitLab, Docker, Kubernetes, Nginx

Vertragsvergleich 01.2017 - 07.2017
Dieses Projekt war ein Pilotprojekt in enger Zusammenarbeit mit einer großen, deutschen Bank und diente dazu einen Vertragsvergleich in das Online-Banking jener zu integrieren. Frontend-seitig setzten wir dabei auf AngularJS als eine Whitelabel-Lösung.
Das Spannende an diesem Projekt war die Arbeitsumgebung. Da wir sehr eng mit dem Kunden arbeiten, teilweise 2-3 Meetings pro Woche hatten, arbeiteten in dieser Zeit in der Nähe vom Kunden, in Hamburg, in einem CoWorking-Space, dem Betahaus. Dort lernten wir viele motivierte Programmierer kennen und es wurden einige interessante Events veranstaltet.
Durch den regelmäßigen Austausch mit dem Kunden fühlte sich das Projekt sehr agil und dynamisch an.
In diesem Projekt waren wir zwei Entwickler und ein Product-Owner.

Angewendete Tools/ Technologien: JavaScript, AngularJS, REST

Kontowechsel-Service 12.2015 - 12.2016
Der Kontowechselservice war zu dem Zeitpunkt ein fertiges Produkt und bereits produktiv im Einsatz. Damals bestand es aus einem AngularJS-Frontend, einem PHP-Backend, einen Java-Service zum Abfragen der Kontotransaktionen und Versenden von E-Mails und einer mongoDB.
Dieses Projekt half mir besonders dabei Grundlagen der Frontend-Programmierung zu Verstehen und zu vertiefen, beispielsweise wie man gulp und Webpack verwendet, Kommunikation mit REST-backends, das Verwalten von state im Frontend, uvm. Hierbei half mir mein damaliger Kollege und Mentor schnell Fuß zu fassen und zu lernen. Dabei lernte ich nebenbei auch, dass so ein Mentor unfassbar wertvoll ist, weil das Lernen somit deutlich schneller und angenehmer ist.
Der Großteil meiner Aufgaben in diesem Projekt bestand aus Bugfixing und dem Entwickeln neuer Features. Eines der Features war die Eingabe einer digitalen Unterschrift. Dafür entwickelten wir eine separate Seite, die nur auf mobilen Geräten sichtbar war und ein Canvas-Element zum Zeichnen enthielt. Der Benutzer, der die Webanwendung auf dem Desktop-Browser geöffnet hatte, konnte dann entweder mit seinem Smartphone einen QR-Code scannen oder sich eine SMS schicken lassen um auf der Unterschriften-Seite zu laden. Die Session wurde mittels eines zufällig generierten codes synchronisiert. Das Smartphone schickte die Unterschrift als BLOB data zusammen mit dem code an das backend. Die Desktop-Browseranwendung fragte diesen code per long polling ab, so lange bis es ein Ergebnis gab. websockets waren aus Gründen der Browserkompatibilität keine Option.

Das Vorgehensmodell war in diesem Projekt KANBAN und das Team bestand aus 10-15 Leuten, davon 70% Entwickler.

Angewendete Tools/ Technologien: JavaScript, AngularJS, REST, Microservices

Angular, SCRUM, Software Design, Softwareentwicklung (allg.), TypeScript