André Hoendgen, Senior Web Developer bei Justix

− in Kooperation mit der Justix GmbH −

André gibt uns einen Einblick in die Entwicklung des LegalTech-Produkts „HelloLaw“. Er erklärt was Immutable Deploys sind und warum ihre Frontend-Developer auch etwas von DevOps verstehen müssen.

Hallo André, welche Rolle hast du bei Justix?

Als Web Developer kümmere ich mich mit meinem Team um das komplette Frontend der Webseite, also all das, was der Kunde sieht. Außerdem sind wir für das Backoffice unseres CRMs verantwortlich. In unserem CRM für unser Produkt „HelloLaw“ arbeiten die Call Center Agents und die Legal Advisors aus Holland.

Wie viele Entwickler arbeiten bei Justix?

Wir haben etwa vier Backend-Entwickler, vier Ops-Leute, die sich um die Infrastruktur kümmern, und zwei, die an der Webseite arbeiten. Jan, der Designer, ist für die User Experience zuständig und läuft bei den Sprints mit. Die Grenzen verwischen sich bei uns ein bisschen, denn uns ist es wichtig, dass die Frontend-Developer etwas von DevOps verstehen. Sie müssen nicht gleich die ganze Infrastruktur aufbauen oder sich ums Load Balancing kümmern. Aber man sollte die ganze Struktur kennen. Es macht keinen Sinn, jedes Mal jemanden von den Ops-Leuten anzuhauen, weil man irgendein PHP-Paket per Dockerfile installieren möchte. Wir setzen daher auch auf Immutable Deploys.

Was sind Immutable Deploys und warum habt ihr euch für die entschieden?

Bei Immutable Deploys geht es darum, die Application Container nicht mehr zu verändern, nachdem diese auf den Host-Systemen deployed wurden. Um diese Container zu erzeugen, arbeiten wir mit Docker. Das ermöglicht es uns, recht einfach einen Überblick über alle Änderungen zu haben. Alles, was dort passiert, liegt als Code in unserer Versionsverwaltung.

Wenn wir etwas an den Containern verändern möchten, ändern wir die zugrunde liegenden Dateien und erzeugen neue Container, welche die alten austauschen. So ist es nicht mehr nötig, unnachvollziehbar direkt per SSH auf den einzelnen Systemen zu arbeiten.

Welche Rolle kommt Dir im Team zu?

Ich sorge für einen vernünftigen Aufbau der Software-Architektur und bin auch als Feuerwehr unterwegs, wenn wir relativ zügig etwas gefixt haben wollen. Ein anderer Teil meiner Aufgabe ist es, mich um die anderen Entwickler zu kümmern. Ich kümmere mich zum Beispiel um den Onboarding-Prozess, den wir für neue Entwickler so einfach wie möglich halten wollen. Ich erkläre dann, wie wir uns das alles vorstellen und wie unser System aufgebaut ist. Uns ist wichtig, dass die Entwickler sich immer weiter fortbilden. Dementsprechend wechseln wir demnächst von Symfony 3.3 auf 3.4. Symfony Flex nutzen wir als Tool, um das Symfony-Framework zusammenzubauen.

Wie häufig bist du im Gespräch mit dem CTO?

Eher weniger. Ich stimme mich viel mit unserem Product Owner Chris ab. Er ist der Puffer zwischen Entwicklungsteam und dem C-Level. So hat man dann Luft zu programmieren.

Wie viel programmierst du?

Momentan so ungefähr 65 Prozent. Wobei es dabei weniger um Programmieren, sondern ums Entwickeln geht. Denn es gibt ja auch Phasen, in denen man nur mit Planen beschäftigt ist, bevor es an die Umsetzung geht. Den Rest der Zeit bin ich als einziger Senior Developer mit dem Team beschäftigt.

Woran arbeitest du aktuell? Was sind die größten Baustellen?

Momentan befinden wir uns ein wenig im Umbruch. Ich bin zum Team kurz vor dem Live-Gang hinzugestoßen und da musste erst mal relativ viel glattgezogen werden. Weil es zum Launch vor allem schnell gehen musste, ist nicht alles optimal gelaufen. Das merken wir jetzt zum Beispiel am Check-out-Prozess, bei dem wir den Point-of-no-Return erreicht haben.

Dann haben wir noch das Web-Office, was eine eigene Applikation ist, und über das unser Call Center und die Legal Advisors telefonieren. Da hatten wir auch einiges zu tun, weil die Plattform, die wir dafür ausgewählt hatten, nicht optimal war. Webseite, Check-out und Web-Office sind drei separate Systeme und wir sind gerade dabei, die Architektur aufzuräumen.

Wie geht ihr an ein Problem heran?

Ich kann das ja mal am Check-out erklären. Wir haben gemerkt, dass es sich nicht mehr lohnt, am aktuellen System zu arbeiten, und beschlossen, das alte System Schritt für Schritt zu ersetzen.

Was genau war denn das Problem mit dem Check-out?

Wir hatten den Check-out komplett mit Event Sourcing gebaut, was eine ganz nette Technik ist, um alles zu entkoppeln. Das Problem lag bei der Implementierung. Das äußerte sich so, dass du beim Check-out ein Produkt in den Warenkorb legst, bezahlst und dann geht nachher ein Callback raus, um zum Beispiel eine Subscription zu erstellen. Wenn du aber einen bestimmten Teil anders haben willst, der abhängig von einem bestimmten Teil der Subscription ist, dann ging das nicht. Wir mussten es irgendwie möglich machen, dass du am Anfang schon weißt, wo du am Ende landest, was bei einigen Konstellationen aber nicht möglich war.

Wie seid ihr weiter vorgegangen?

Wir haben die alten Planungsunterlagen genommen und sind nochmals alles durchgegangen. Dabei haben wir uns gefragt, was davon funktioniert hat, was wir gerne hätten, und haben dann angefangen zu planen. Das geht dann über den CTO, den CEO und das Marketing, die natürlich auch ihr Feedback geben. Wir sammeln alle Informationen und schneiden daraus dann die Stories.

Bist du bei diesem Schritt schon dabei?

Da noch nicht. Später aber, wenn es darum geht zu schauen, ob die Stories eine brauchbare Größe haben. Wir sagen, wir wollen keine Stories, die mehr als 20 Story Points haben. Das ist eigentlich auch schon zu viel, weil du während des Sprints keinen Fortschritt sehen kannst.

Nachdem wir alles durchgeguckt und sichergestellt haben, dass alle Informationen vorhanden sind, geht es in die Sprint-Planung.

Dafür haben wir alle zwei Wochen immer mittwochs den ganzen Tag eingeplant, an dem wir uns zusammensetzen und dem Product Owner und dem Business Analyst die Stories vorstellen: Wie heißt die Story eigentlich? Was soll darin gemacht werden? Was ist wirklich Out of Scope? Wichtig ist, dass die Story nicht zu groß wird, auch nicht in den Köpfen der einzelnen Entwickler. Wir bewerten die Stories nach Komplexität und wenn wir merken, dass die Abweichungen zu groß sind, dann diskutieren wir darüber, warum das so ist. Das ist im Grunde der erste Teil der Sprint-Planung.

Wie sieht der zweite Teil aus?

Im zweiten Teil setzen wir uns dann ohne PO und Business Analyst zusammen und gehen die Stories nochmal durch. Dabei pullt sich jeder die Stories, von denen er denkt, dass er sie umsetzen möchte. Wichtig ist, dass sie nicht verteilt werden, sondern jeder nach seinem Wissen und seiner Erfahrung das nimmt, von dem er denkt, dass er es entsprechend umsetzen kann. Jeder sollte sich auf seine Arbeit committen. Zum Schluss schauen wir uns noch mal an, wie viele Storys und Punkte jeder hat. Zwischen 40 und 50 Story Points ist eigentlich eine ganz gute Messlatte.

Wo kommt das Scrum-Board ins Spiel?

Das baut sich als Nächstes zusammen. Chris, der PO, schaut sich das alles noch mal an, um festzustellen, dass nichts, was wichtig ist, hintenübergefallen ist, oder ob wir die Prios noch mal neu sortieren müssen. Dann kommen die Stories ins Sprint Board rein und wir erstellen Tasks. Eine Task sollte nicht länger als drei bis vier Stunden gehen, sodass man über den Tag einen Fortschritt merkt. Wichtig ist, dass man hier schon auf die Spezialisierung eingeht. Die Leute vom Backend setzen sich zum Beispiel zu einem Backend-Thema zusammen und besprechen, wie man ein Ticket am besten umsetzen könnte. Wir sind ja größtenteils ein Remote-Team, dementsprechend machen wir das alles über Google Hangout.

Das klang bislang so, als würdet ihr alle in einem Raum zusammen sitzen!

Das hat sich alles in der Zwischenzeit sehr gut eingeruckelt und mit Jira kann jeder von überall auf das Scrum Board zugreifen. Einer macht einen Screen Share und die Leute, die hier sind, sitzen zusammen vor dem Beamer und gehen alles durch. Im Kleinen machen wir das so auch jeden Morgen zu unserem Daily Stand-up.

Habt ihr euch schon mal in echt gesehen?

Ja, normalerweise sind die Externen so alle zwei bis vier Wochen mal für eine Woche hier, sodass man sich von Angesicht zu Angesicht sieht. Da kann man dann auch mal abends zusammen ein Bier trinken gehen.

Wie lange habt ihr für die Umsetzung dann gebraucht?

Innerhalb von anderthalb Wochen hatten wir eine komplett neue Applikation implementiert, mit der wir das neue Feature umsetzen konnten. Das hat sich für uns gelohnt. Denn es zeigt, dass wir nicht an Altem festhalten, nur weil wir es haben, sondern wir können auch Sachen in Frage stellen und es austauschen. Wichtig ist, dass man den Business Case nicht aus den Augen verliert.

Welche Tools habt ihr dafür eingesetzt?

Wir sind relativ offen, was die Tools angeht, und jeder Entwickler kann sich selber aussuchen, was er am liebsten nutzt. Du gibst einem Koch ja auch nicht irgendwelche Messer, sondern die kann er sich selber kaufen oder aussuchen. Die Entwickler müssen halt in ihrer Welt arbeiten können. Standard bei uns ist PhpStorm und GitLab, womit wir unsere Versionsverwaltung machen. Wenn man aber lieber mit Sublime oder vi arbeitet, ist das auch okay. Wir bauen außerdem mit PHP, nginx und PostgreSQL. Als Grundsystem nutzen wir PHP 7.1. Für 7.2 machen wir demnächst Tests und schauen, ob wir das alles vernünftig auf 7.2 upgraden können.

Zudem nutzen wir komplett Docker. Das heißt, angefangen bei der lokalen Entwicklungsumgebung über das Staging System bis zum Produktivsystem haben wir fast ein 1:1-System. Terraform nutzen wir für die Infrastruktur. Das Ganze läuft auf AWS und um die Container zu verwalten nutzen wir Rancher.

Welche weiteren Tools verwendet ihr?

Slack und Hangouts für die Teamkommunikation. Jira für das Scrum Board, wobei wir auch ein physikalisches Board im Office hängen haben. Christian kümmert sich darum, dass das immer synchron ist. Mit Confluence dokumentieren wir und da haben wir auch solche Späße wie den Styleguide drin.

Welche Tools brauchst du persönlich?

Ich persönlich entwickle am liebsten mit PhpStorm. Die IDE kannst du so gut einstellen, wie man es haben möchte. Ein feines Werkzeug. Sonst habe ich nicht viele Tools. Im Terminal bewegt es sich einfach am schnellsten. Ich arbeite am liebsten auf dem Mac, weil du auf Windows die Oberfläche nicht gebrauchen kannst, und auf Linux musst du dich um sehr viel kümmern. Mac ist eine gute Mischung aus beidem. Oh-My-Zsh habe ich auf dem Terminal selber liegen. Da kannst du eigene Erweiterungen reinpacken. Mit Alfred kann man die Workflows gut vereinheitlichen. Und manche Tools schreibe ich mir selber, weil ich es nicht mag, stupide Sachen mehrmals machen zu müssen.

Lass uns hier mal einen Schritt weg von Tools und Methoden machen. Wie alt bist du?

28.

Du bist im Moment der einzige Senior Entwickler bei Justix. Was bedeutet Senior für dich?

Ein Senior-Entwickler sollte ein sehr guter Programmierer sein. Aber meiner Meinung nach gehört ein erweitertes Verständnis von Ops und Business zu dieser Rolle. Du magst in der Lage sein, ein Raumschiff zu bauen. Aber wenn das Geschäft ein Fahrrad braucht, dann musst du ein Fahrrad bauen. Dazu gehört, das auch kommunizieren zu können. In die Rolle wächst man rein. Am Anfang ist die Softwareentwicklung kompliziert genug

Wie bist du Entwickler geworden?

Gute Frage. Mich hat das schon immer irgendwie fasziniert. Mit 13 wollte ich wissen, wie das eigentlich funktioniert. Man hat halt damit gespielt. Mein erster Computer war ein 386er, dann ein AMD XP 2500+. Der konnte schon ein bisschen was. Das erste Größere, mit dem ich gelernt habe, war ein Tutorial von QuakeNet. Das war ein Crashkurs in PHP. Dann habe ich eine Modding-Seite für ein bestehendes CMS gebaut, die später zur offiziellen Seite wurde. Mit Ende 15 habe ich eine Ausbildung zum Fachinformatiker für Anwendungsentwicklung gemacht. Damals war das mit den Ausbildungen noch nicht so einfach. Und so musste ich von Köln immer nach Mettmann fahren.

Danach bin ich zu einer Kölner Agentur gegangen, wo ich das Glück hatte, alles Mögliche ausprobieren zu können. Da war ich später dann auch Hauptentwickler. Mein nächster Job war bei Convidera. Das war mein nächster Schritt in Bezug auf Mitarbeiterführung. Da haben wir die komplette IT-Abteilung aufgezogen. Nach zwei Jahren bin ich dann zu Justix.

Was sind für dich wichtige Themen und Trends in der Webentwicklung?

Ich denke, Blockchain wird ein richtig großes Thema werden, wenn es um Offenheit und Transparenz geht. Da geht es aber auch um die Entkoppelung der ganzen Wertschöpfungskette.

Für die Webentwicklung selber wird es noch mehr in Richtung Mobile gehen. Da spielen dann sicher Progressive Web Apps eine große Rolle. Da geht es dann weniger um eine klassische Web-Schnittstelle, sondern eher in Richtung GraphQL, wo man gezielt abfragen kann, was man wirklich haben will.

Woher kommt deine tägliche Portion Information?

Die bekomme ich querbeet. Ich lese viel auf Medium, wo ich entsprechende Topics abonniert habe. Da kommt jeden Tag viel Interessantes rein. Über Hacker News kommt relativ viel rein und im Trending-Bereich von GitHub stößt man öfter mal auf Sachen, die nicht so die Aufmerksamkeit bekommen, aber die man gut gebrauchen kann.

Was war das letzte Buch, das du gelesen hast?

Von Ray Kurzweil. Es ging um künstliche Intelligenz. Der Einstieg ist sehr philosophisch. Automatisierte Statistik klingt jetzt ja nicht so prickelnd. Aber wenn man sich in aller Tiefe damit auseinandersetzt, bevor man es einzusetzen versucht, dann macht das schon Sinn.

Lieber André, vielen Dank für das Interview!

Dieses Interview entstand am 23. Oktober 2017 in Zusammenarbeit mit der Justix GmbH im Kölner Mediapark 5.

Webseite: Justix GmbH