Interview mit Sascha Di Bernardo

Sascha Di Bernardo studierte Information Systems an der WWU Münster und arbeitete als Werkstudent bei der viadee. Sein Aufgabenbereich hier bei uns war die weitere Entwicklung und Wartung des viadee Process Application Validators. Zu diesem Thema haben wir ihm drei Fragen gestellt:  

Was war Deine Rolle in diesem Zusammenhang?

Meine Rolle entsprach der des Entwicklers in einer agilen Projektumgebung wie Scrum. D. h. zu Beginn eines Sprints wurden die Anforderungen mit Claus und Frank, also dem Product Owner und dem Scrum Master, abgestimmt und priorisiert. Nach einer Einschätzung des Arbeitsaufwandes wurde der Sprint, der immer über zwei Wochen geht, gestartet. Innerhalb eines Sprints wurden die Anforderungen umgesetzt, d. h. klassische Programmierarbeit. Erwähnenswert ist an dieser Stelle, dass viele Anforderungen mittels Test-Driven-Development umgesetzt wurden, um eine hohe Testabdeckung und damit Stabilität zu erreichen. Anforderungen waren typischerweise neue Features, Bugfixes oder Erweiterungen bisheriger Features. Am Ende des Sprints wurde dann eine neue Version veröffentlicht und man fand Elemente des Releasemanagements wieder (Versionierung, Deployment und Synchronisation der Artefakte mit Maven Central, Aufführen der Release Notes etc.).

Wie groß ist denn die Einstiegshürde in so ein Projekt für Student:innen?

Der viadee Process Application Validator wurde von der viadee ins Leben gerufen und ist seit Release der Version 2.0.0 als Open-Source-Projekt bei GitHub zu finden – das macht die Hürde erst einmal niedrig. Als Benutzer:in lässt sich vPAV als Maven Dependency leicht und elegant in einen Unit Test einbinden, sodass man nach 5-10 Minuten seine ersten Modelle testen kann. Wenn man dem Projekt etwas beisteuern möchte, gibt es zwei Möglichkeiten: neue individuelle Checker zu erstellen oder anderweitige Kontributionen. Die Voraussetzungen, einen neuen Checker zu implementieren, hat man ebenfalls in gut 5-10 Minuten erledigt, abgesehen von der Komplexität der gewünschten Funktionalität. Andere Teile des vPAVs bedürfen deutlich mehr Zeit, da man an dieser Stelle aktiv in den Lifecycle eingreift und sich über die Auswirkungen im Klaren sein muss. Dafür sollte man das gesamte Ablaufverhalten des Tools kennen und verstehen.

Was hast Du in der Projektzeit gelernt?

In meiner Tätigkeit als Werkstudent habe ich viele verschiedene Facetten kennengelernt. Generelle Dinge, die sich vermutlich Arbeitsplatz-übergreifend bewahrheiten, wie oft wechselnde Anforderungen je nach Kundenansicht, das Projektmanagement, welches selbst in Kleinstgruppen elementar war, um effiziente Kommunikation und Arbeit zu gewährleisten, die selbstständige Arbeitsweise in einer agilen Umgebung, die Wichtigkeit softwarearchitektonischer Gestaltung und auch die offene Fragekultur, die es erlaubt, sein Wissen und Verständnis diverser Ansichten auf den Prüfstand zu stellen und ggf. durch profundes Wissen zu ersetzen. Technologisch habe ich mir ein Grundgerüst bereits vorab erarbeitet, konnte dieses aber noch deutlich erweitern und vertiefen. Mit aktuellen Technologien wie Spring, Maven, JUnit, SonarQube, Jenkins, Git und Camunda konnte ich einerseits auf etablierte Standards zurückgreifen, zusätzlich die Ansätze des CI/CD Paradigmas anwenden und durch Tests und Codeanalysen die Qualität auf einem steten Niveau halten.