Interview mit Simon Maple

Java-Performance: „Die schwarze Kunst der Softwareentwicklung“

Natali Vlatko

© Shutterstock.com/Oleg Mikhaylov

Der von ZeroTurnaround gesponserte und von RebelLabs herausgegebene Developer Productivity Report konzentrierte sich in diesem Jahr ganz auf Fragen der Java-Performance. JAXenter hatte die Gelegenheit, mit Simon Maple, Softwareentwickler und technischer Evangelist bei ZeroTurnaround, über die Ergebnisse der Umfrage zu sprechen.

JAXenter: Der diesjährige Java Productivity Report konzentriert sich ganz auf die Java-Performance – von dir als „die schwarze Kunst der Softwareentwicklung bezeichnet“. Was war die Motivation für diesen Fokus?

Simon Maple: In unserem Report wechseln wir jährlich zwischen einem breit angelegten Überblick über die technische Landschaft, in der Entwickler arbeiten, und einer spezifischen Erhebung über eine bestimmte Disziplin oder einen bestimmten Bereich der Softwareentwicklung. Mit XRebel ist Zero Turnaround vor kurzem selbst in den Performance-Markt eingestiegen, weshalb unser Interesse an diesem Themenbereich in den letzten Jahren merklich gestiegen ist. Wie wir feststellen konnten, handelt es sich um einen Abschnitt des Anwendungslebenszyklus, der vernachlässigt und manchmal sogar komplett ignoriert wird. Deshalb wollten wir etwas tiefer schürfen und herausfinden, wie der Blick der Entwickler und Teams auf Perfomance-Tests aussieht und wie sie diese angehen.

JAXenter: Wie der Report zeigt, ist zu 94 % das Entwicklungsteam für die Beseitigung von Performance-Problemen verantwortlich. Du sagst, es macht Sinn, dass man den Code während der Entwicklung Performance-Tests unterzieht. Weist der hohe Prozentsatz darauf hin, dass dies nicht geschieht?

Simon Maple: 94 % der Teilnehmer gaben an, dass die Entwickler für die Beseitigung auftauchender Performance-Probleme verantwortlich sind. Das bedeutet jedoch nicht, dass diese von den Entwicklern gefunden werden, geschweige denn während der Entwicklung. Das führt uns zum nächsten Punkt: Wenn irgendwo im Zyklus Performance-Probleme gefunden werden, wenden sich QA-, Operations- oder Performance-Teams offenbar meistens an das Entwicklungsteam, um eine Lösung für sie zu bekommen. Das kann auch Tage, Wochen oder sogar Monate nach Entwicklung des Features der Fall sein.

Tatsächlich könnte es beispielsweise sogar sein, dass die Entwickler den Code bereits wiederverwendet haben Umstände wie dieser machen einen potentiellen Fix kostspieliger.

JAXenter: Haben dich die Antworten im Hinblick auf die verwendeten Profiling-Tools überrascht? Was hältst du von XRebels Ergebnis von 3,3 % Verbreitung?

Simon Maple: Wir hatten vermutet, dass JProfiler an der Spitze stehen würde. Ich persönlich hätte erwartet, dass Java Mission Control einen höheren Prozentsatz erreicht, nicht nur weil es ein großartiges Tool ist, sondern auch weil es für die Entwicklung und für Tests frei zu verwenden und in Oracles Java 7u40 enthalten ist. XRebels Ergebnis von 3,3 % ist für ein Tool, das nur etwas länger als ein Jahr auf dem Markt ist, sehr hoch.

Auch wenn ich mir natürlich wünschen würde, dass die Zahl korrekt ist, so wohnt Umfragen doch immer ein gewisser Bias inne, und ich glaube dieser Umstand spielte hierbei eine Rolle. Wir wollten die Umfrage so weit wie möglich verbreiten und sind dazu sogar an Influencer in der Industrie herangetreten. Unsere Reichweite in den sozialen Medien schließt viele unserer JRebel- und XRebel-Kunden ein, was bei der Betrachtung der Ergebnisse berücksichtigt werden muss.

JAXenter: Im Hinblick auf die Angaben der Umfrageteilnehmer zu den am häufigsten auftretenden Perfomance-Problemen sagtest du: „wir als Industrie schaffen es nicht, richtig zu testen“. Was wäre deiner Ansicht nach die richtige Herangehensweise an Tests?

Simon Maple: Obwohl ich mit diesem Statement in erster Linie auf Performance-Tests abzielte, gilt es tatsächlich – größtenteils – für alle Arten von Tests. Es gibt zwar Leute, die großartige Unit-Tests schreiben und sie regelmäßig in einer CI-Umgebung laufen lassen, aber viele tun dies noch immer nicht. Speziell auf Performance-Tests bezogen müssen wir unsere Denkweise ändern – genau so, wie wir das vor einiger Zeit im Hinblick auf Unit-Tests und funktionale Tests getan haben.

Diese neue Denkweise muss Performance-Tests einen hohen Stellenwert einräumen, sie als etwas betrachten, dass sowohl früh als auch regelmäßig durchgeführt wird. Häufig werden Tests nur halbherzig durchgeführt oder gar ganz weggelassen, was zu einer schlechten User Experience beim Kunden führt. Entwickler konzentrieren sich häufig eher auf den Code statt auf die Qualität – was nicht immer ihre Schuld ist. Straffe Zeitpläne und der Druck aus Richtung Projektmanagement sind eine gute Ausrede dafür, dass Code ausgeliefert wird, ohne gründliche funktionale und Performace-Tests durchlaufen zu haben. Code und Anwendungen können nur so gut wie ihre Tests, was Unit-Tests, funktionale Tests und Performance-Test einschließt, sein. Alle drei müssen so früh wie möglich Teil des Prozesses sein und nach Möglichkeit während der Codeentwicklung durchgeführt werden.

JAXenter: Du hast die Frage in den Raum gestellt, ob dedizierte Performance-Teams besser sind. Die Ergebnisse weisen darauf hin, dass sie beim Auffinden von Bugs und Problemen tatsächlich überlegen sind. Gibt es noch eine andere Variable, die du in diesem Zusammenhang berücksichtigen würdest? Wie sieht es z. B. mit Fachwissen im Performance-Bereich aus?

Simon Maple: Das ist eine sehr schwierige Frage, da jedes Team anders ist und Individuen mit unterschiedlichem Wissensniveau große Auswirkungen haben. Was wir außerdem nicht näher untersucht haben sind die Arten von Bugs, die gefunden wurden. Ich spekuliere jetzt, aber dedizierte Performance-Teams dürften komplexere Testszenarien als Entwickler entwerfen als Entwickler. Nicht weil sie mehr Zeit haben, sondern weil es ihre dedizierte Aufgabe ist, vermute ich, dass sie über eine größere Expertise und deutlich mehr Fachwissen im Performance-Bereich verfügen.

Die Bugs, die von Performance-Teams gefunden werden, sind wahrscheinlich nicht nur schwieriger zu entdecken, sondern auch schwieriger zu fixen, was den sehr viel höheren Zeitaufwand, der für ihre Beseitigung nötig war, erklären würde. Obschon sowohl Erfahrung als auch Wissen Schlüsselaspekte für das Verständnis von der Arbeit dieser Teams sind, stellen sie sehr objektive und nur sehr schwer genau zu bemessende Maßzahlen dar.

Simon Maple is the Developer Advocate for ZeroTurnaround, as well as a Java Champion, JavaOne Rockstar and the founder of virtualJUG, the world’s first online-only Java User Group. Prior to joining ZeroTurnaround, Simon was a technical evangelist for IBM on the WebSphere Application Server for 12 years.

Aufmacherbild: Young Boy Dressed as Clown Performing on Stage von Shutterstock.com / Urheberrecht: Oleg Mikhaylov

Geschrieben von
Natali Vlatko
Natali Vlatko
An Australian who now calls Berlin home, via a two year love affair with Singapore. Natali was an Editorial Assistant for JAXenter.com (S&S Media Group).
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: