Fifty Shades of Red. Oder wie man es schafft, dass Entwickler (endlich) unter Ihrer eigenen (schlechten) Software leiden müssen

Transkript

1 Oder wie man es schafft, dass Entwickler (endlich) unter Ihrer eigenen (schlechten) Software leiden müssen Mirko Seifert, DevBoost GmbH JUG Saxony Day Dresden

2 Unser Leben als Softwareentwickler Wir schreiben hervorragende Software, die Menschen glücklich macht Wir machen das Leben auf diesem Planeten durch die Nutzung von Software einfacher, schöner, angenehmer Wir bewerkstelligen alles Menschenmögliche um Fehler und Unannehmlichkeiten für die Benutzer unserer Software zu vermeiden

3 Unser Leben als Softwarenutzer Wir nutzen ausschließlich hervorragende Software, die uns glücklich macht Wir können das Leben auf diesem Planeten durch die Nutzung von Software viel mehr genießen Wir finden nur sehr, sehr selten Fehler oder Unannehmlichkeiten in der Software, die wir nutzen

4

5

6

7

8 Ursachen Fehlendes Feedback an den Entwickler: von Benutzern von Produktivsystemen von Testsystemen von CI-Systemen von lokalen Tests

9 Was tun? Entwickler Lokaler Test CI System Test System Staging System Production System Benutzer Feedback Storage

10 Feedbackinhalt Möglichst generisch Aber wie genau? Mit Code verbunden (Klasse, Methode, Zeile) Zeitpunkt Übertragung HTTP/REST Anzeige für Entwickler In der IDE, direkt am Code Filterbar Entwickler Lokaler Test CI System Test System Staging System Feedback Storage Productio n System Benutzer

11 Architektur Client (z.b. Code auf Produktivsystem) Confessional REST API IDE Client (z.b. Eclipse Plugin) Tomcat Webserver Confessional Database

12 DEMO Logger / Exception Feedback

13 Schlechten Code erkennen private boolean lookupuser(string username, String expectedhash) { boolean foundhash = false; String sql = "SELECT password FROM user WHERE username =?"; try (Connection connection = DriverManager.getConnection(getDatabaseURL(), USER, PASS); PreparedStatement preparedstatement = connection.preparestatement(sql)) { preparedstatement.setstring(1, username); ResultSet resultset = preparedstatement.executequery(); while (resultset.next()) { foundhash = expectedhash.equals(resultset.getstring("password")); break; } resultset.close(); } catch (SQLException se) { se.printstacktrace(); } return foundhash; }

14 DEMO Database Performance Feedback

15 DEMO ThisShouldNeverHappenDemo

16 Assertions Wer nutzt Assertions und wie? Wenn nur im Test, dann kein Unterschied zu JUnit Assertions Aber eigentlich ein schönes Konzept

17 DEMO Assertion Feedback

18 Schlechten Code erkennen Weitere Beispiele Anzahl Datenbankabfragen bei Nutzung von JPA Netzwerkkommunikation Request-Anzahl, Request-Dauer, Timeouts (z. B. API Aufrufe) Speichernutzung (große Objekte, benutzter HEAP, HTTP Session Size) Andere I/O Operations (z. B. Schreiben von Daten auf Platte)

19 Was es noch zu beachten gilt (1/2) Code zum Senden von Events muss: Thread-safe sein Fehlerfrei sein Asynchron laufen Tolerant bei Netzwerkausfall sein Obere Schranken für Speicher beachten

20 Was es noch zu beachten gilt (2/2) Code wird weiterentwickelt Zeilennummern verschieben sich Korrekturrechnung anhand der SCM Historie erforderlich Verwaltung von Events notwendig (wer markiert Events als behandelt, wer behandelt welches Event, )

21 Credits

22 Fazit 1. Es ist (relativ) einfach mehr Feedback über unseren Code zu bekommen 2. Es gibt viele (schlechte) Dinge, die man dem Code als Entwickler nicht (einfach) ansehen kann 3. Ohne Feedback aus Produktivumgebungen ist es schwierig fehlerarme, performante Applikationen zu entwickeln

23 Danke! Fragen?