Interview mit Mark Struberg

Angstschweiß auf der Entwicklerstirn: Codeänderungen ohne Unittests!

Mark Struberg

Wer als IT-Unternehmen heute mithalten will, muss in der Lage sein, Produkte und Updates schnell auszuliefern. In diesem Kontext wird ein kontinuierliches und möglichst automatisiertes Deployment immer wichtiger. Und so ist dem Thema „Continuous Deployment“ auf dem Java EE Summit (9. bis 11. Dezember 2013) ein ganzer Workshop gewidmet. Wir sprachen mit Workshop-Leiter Mark Struberg über die Bedeutung von Continuous Deployment und die Herausforderungen an Java Enterprise Entwickler.

JAXenter: Hallo Mark! In der heutigen IT-Welt ist ein kurzer Time-to-Market mittlerweile lebenswichtig. Du wirst auf dem Java EE Summit über Continuous Development sprechen – warum ist das heute so wichtig?

Mark Struberg: Der Term ‚Continuous Development‘ ist ja streng genommen noch gar nicht richtig definiert. Gab es das überhaupt vor Andrew‘ und Aslaks Buch schon? Auf jeden Fall treffen die Worte recht gut, was ich in meinen Projekten anwende, um Änderungswünsche in bestehenden Applikationen möglichst schnell in einer guten Qualität in Produktion zu bringen. Ähnlich wie beim CAP Theorem kann man auch bei der Softwareentwicklung nur zwei der drei folgenden Parameter gleichzeitig erreichen: Qualität, Entwicklungszeit, Kosten. Continuous Development kann uns helfen, zumindest den Parameter ‚Qualität‘ teilautomatisiert in den Griff zu bekommen.

Durch gezieltes Aufbereiten und Extrahieren von Daten aus der Produktion (auch richtig loggen will gelernt sein!) und Umsetzen der gewonnenen Informationen in (praxisrelevante!) Unit Tests kann in Verbindung mit Continuous Integration und einem guten Build viel Stabilität gewonnen werden. Und jede vermiedene Entwicklungsiteration ist pure gewonnene Zeit.

JAXenter: Java-EE-Anwendungen sind in der Regel komplex. Bietet die Java-EE-Welt die technischen Voraussetzungen, um auf den Wandel der IT zu reagieren?

Mark Struberg: Die meisten Techniken, die in großen Projekten angewendet werden, sind mehrere Jahrzehnte alt. Und selbst Techniken, die scheinbar (oder tatsächlich) neu sind, beinhalten einen großen Teil an alten und erprobten Technologien. Tatsächlich bin ich noch auf nichts gestoßen, was man mit Java EE nicht auch machen hätte können.

Meist spießt es sich nicht an den JavaEE Spezifikationen sondern an den einzelnen Server-Implementierungen. Mein Herz schmerzt immer, wenn mal wieder der nächste große Hype angerollt kommt und man damit auf einmal jedes umherliegende Problem lösen will. SOAP, anyone? Viele der neuen Technologien haben ihre Berechtigung. Aber genauso viele davon werden in der Euphorie missbräuchlich verwendet.

JAXenter: Welche Zielgruppe willst du mit deinem Workshop „With Continuous Development from Dev to Ops“ ansprechen?

Mark Struberg: Java-Anfänger werden sich vermutlich schwer tun. Aber vom Junior Developer bis zum Experten sollte für alle anderen einiges dabei sein. Ich werde recht tief in die Materie gehen. Ich bin ja bekannt dafür, mich nicht mit Werbetexten aufzuhalten, sondern per Hands-on die ‚Gemeinheiten‘ des Projektalltages aufzudecken.

Ich werde sicher auch wieder ein paar Code Drops zum ‚Abkupfern‘ zur Verfügung stellen, damit man nicht mit einem Brummkopf aus der Session raus kommt und am nächsten Tag nichts mehr nachvollziehen kann. Wie beim Testing selbst ist auch hier ‚Nachhaltigkeit‘ die Devise.

Ich werde unter anderem auf folgende Punkte im Detail eingehen:

  • Wie kann ich mein Programm gestalten, um möglichst hochwertige Informationen über auftretende Probleme aus der Produktion zu erhalten?
  • Wie kann ich selbst für EJBs und andere Java-EE-Technologien Unit Tests schreiben? Stichworte: Arquillian bzw. CdiCtrl.
  • Wie kann ich wirklich realitätsnahe Unit Tests schreiben, ohne dabei ‚die Seele aus dem Projekt zu mocken‘?
  • Wie kann ich meinen Build so gestalten, dass ich einen möglichst schnellen aber dennoch hochqualitativen Änderungszyklus erhalte?

JAXenter: Welche Rolle spielt deiner Meinung nach das Testing?

Mark Struberg: Jeder, der seriös ein großes Projekt umsetzt, MUSS eine gute Unit Test Suite haben. Punkt!

Nichts ist schlimmer als der Angstschweiß auf der Entwicklerstirn, wenn er wieder mal Sourcen ändern muss, in denen es keine Testabdeckung gibt. Dreht man in derartigen Projekten an einem kleinen Schräubchen links, fällt eventuell irgendwo auf der anderen Seite ein Rad ab. Und ohne Tests bekommt man als Entwickler rein nichts davon mit!

Umso mehr schaudert es mich, wenn ich darüber nachdenke, in wie viele große Projekte ich gerufen werde, in denen ich tatsächlich der erste bin, der Unit Tests schreibt und das ganze Environment dafür fit macht. Wobei dies gar nicht so schwer ist, wenn man einmal ein paar Kniffe kennt…

JAXenter: Vielen Dank für dieses Interview!

Mark Struberg ist Softwarearchitekt mit über zwanzig Jahren Programmiererfahrung. Er arbeitet seit 1996 mit Java und ist aktiv in Open-Source-Projekte im Bereich Java und Linux involviert. Mark ist Apache Software Foundation Member und PMC bei Apache OpenWebBeans, MyFaces, Delta-Spike und vielen anderen Apache-Projekten. Als Java Expert Group Member arbeitet er aktiv an der CDI und anderen EE-Spezifikation mit. Er arbeitet unter anderem für die Research Group for Industrial Software (INSO) der TU Wien.

Kommentare
  1. tobi2013-11-13 18:13:39

    "Jeder, der seriös ein großes Projekt umsetzt, MUSS eine gute Unit Test Suite haben. Punkt!"

    Leider ist das bei vielen Entwicklern noch nicht angekommen, zumindest in meiner Abteilung. Bei uns beispielsweise habe ich *versucht* Unittests einzuführen. Erst hat der Kollege den Test @Ignored, mittlerweile meine ich sogar er ist wegen compile errors auskommentiert.
    Auf die Frage weshalb er das tat und den Test nicht einfach wieder funktionsfähig gemacht hat antwortete er "Weil ich davon nix halt." - und die Ansicht ist in den meisten Köpfen (bei uns) leider fest verzahnt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.