14. September 2017 // von Nathalie

Praktikum bei Thomann in Berlin

Im Bachelorstudiengang Medieninformatik an der Beuth Hochschule für Technik ist im letzten Semester, kurz vor der Abschlussarbeit, ein Betriebspraktikum vorgesehen. Über einen Kommilitonen bin ich auf Thomann in Berlin aufmerksam geworden. Die Stellenausschreibung passte genau zu dem Technologiestack, den ich während meines Praktikums vertiefen wollte, dazu noch die attraktive Lage des Büros mitten in der Stadt und dann noch… Thomann! Noch am selben Abend war die Bewerbung eingereicht, eine Woche später hatte ich die Zusage: 12 Wochen Praktikum konnten beginnen.

Bereiche und Aufgaben

Einerseits konnte ich während des Praktikums die grundlegenden Kenntnisse, die mir in meinem bisherigen Studium vermittelt wurden, anwenden und erweitern. Andererseits wurde mir ein fundierter Einblick in den Alltag der Entwicklerpraxis gewährt und ich konnte erleben, was es bedeutet, kontinuierlich an einem einzigen Großprojekt zu arbeiten, anstatt, wie es in meiner Studienzeit üblich war, immer wieder neue, dafür sehr kleine Projekte aufzusetzen. Mir wurden Aufgaben aus unterschiedlichen Kontexten gestellt und alle Mitglieder des Teams unterstützten mich immer hilfsbereit und konstruktiv bei der jeweiligen Lösung.

Tech Stack

Die Programmiersprache, mit der ich während meiner Praktikumszeit hauptsächlich arbeitete, war PHP. Dies war insofern eine Herausforderung, als dass in meiner Studienzeit PHP nur sehr selten eine Rolle spielte und ich daher kaum Erfahrung darin hatte. Doch da die Webservices von m.thomann.de in PHP implementiert sind, war dies eine gute Gelegenheit, mich einzuarbeiten und weiterzubilden. Sie repräsentieren die Controller-Schicht der Model-View-Controller-Architektur des Projektes und sind daher die Schaltzentrale zwischen Client und den verschiedenen APIs. Daher spielte PHP bei meinem Hauptprojekt eine wesentliche Rolle, wo es darum ging, m.thomann.de eine ganz neue Funktionalität hinzuzufügen.

Middleware und Renderer sind node.js Anwendungen und demnach in JavaScript geschrieben. Sie sind allerdings infrastrukturelle Komponenten und übernehmen grundlegende Aufgaben wie Routing, Aufrufen des richtigen Webservices und Erzeugen der HTML-Elemente auf Basis von Templates und schicken schließlich die vollständig zusammengesetzte Webseite zum Client zurück.

Eine größere Rolle spielte für mich die Arbeit mit der Template-Engine dust.js, die zusammen mit Less den strukturellen und optischen Aufbau jeder einzelnen HTML-Seite generiert. Zwar war dust.js ein Tool, das ich vorher nicht kannte, doch, wie auch bei der Einarbeitung in PHP, konnte ich meine hilfsbereiten Kollegen jederzeit um Rat fragen.

Für mich persönlich am wichtigsten war jedoch die intensive Arbeit mit Git. m.thomann.de ist in viele kleine Projekte unterteilt, die jeweils in einem eigenen Repository verwaltet werden. Es ist wichtig (und zu Beginn mühselig) zu überblicken, wie die einzelnen Projekte miteinander zusammenhängen und welche Änderungen in welchem Repository vorgenommen werden müssen um den jeweils gewünschten Effekt zu erzielen. Die einzelnen Bestandteile der Arbeit mit Git wurden mir zwar im Studium vermittelt und ich konnte sie auch rudimentär anwenden. Für den gesamten Prozessablauf, vom Clonen eines Projektes über das Pushen von Änderungen bis hin zum Ablauf eines Pull-Requests, konnte ich jedoch erst während des Praktikums beginnen, eine Routine zu entwickeln.

Des Weiteren spielten auch Entwicklertools während meiner Zeit bei Thomann eine große Rolle. Beispielsweise erhielt ich eine Einführung in Tools wie Jenkins, die das Prinzip der continous integration und continous delivery möglich machen. Selbst wenn ich nicht aktiv damit gearbeitet habe, so wurde mir dadurch, dass ich immer wieder mit in den Prozess einbezogen wurde, klar, wie die Deployment-Kette eines so großen Projektes von statten geht und verwaltet werden kann.

Scrum

Im Praktikum hatte ich zum ersten Mal die Möglichkeit, den Scrum-Prozess (inklusive Jira als Ticketsystem) aus der Sicht eines Entwicklers mitzuerleben. Von Anfang an wurde ich als neues Teammitglied betrachtet und in alle Aktivitäten wie Daily Scrum, Estimation-Meeting oder Sprint-Planung mit einbezogen. Auch wenn ich zu Beginn nicht viel beitragen konnte und nur wenig von der Projektstruktur verstand, so wusste ich doch, woran die Teammitglieder gerade arbeiten, welche Aufgaben als nächstes anstehen und vor allem, wie sich die Zusammenarbeit gestaltet. Mit voranschreitender Zeit und der Arbeit an meinem Hauptprojekt konnte ich mich jedoch immer stärker einbringen und aktiv an der Teamarbeit teilhaben. Dabei arbeitete ich allerdings zu jedem Zeitpunkt unabhängig, da meine Tickets nicht mit in die Sprints gepackt wurden. Somit hatte ich nie den Druck mit meinen Aufgaben innerhalb einer vorgegebenen Zeit fertig werden zu müssen, sondern konnte mir die Zeit lassen, die ich brauchte.

Verwandte Blogposts