Embed Size (px)
Citation preview
Fifty Shades of Red
Mirko Seifert, DevBoost GmbH
JUG Saxony Day | 02.10.2015 | Dresden
Oder wie man es schafft, dass Entwickler (endlich) unter Ihrer eigenen
(schlechten) Software leiden müssen
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
Fifty Shades of Red
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
Fifty Shades of Red
Fifty Shades of Red
Fifty Shades of Red
Fifty Shades of Red
Fifty Shades of Red
Ursachen
Fehlendes Feedback an den Entwickler:
• von Benutzern
• von Produktivsystemen
• von Testsystemen
• von CI-Systemen
• von lokalen Tests
Fifty Shades of Red
Was tun?
EntwicklerLokaler
TestCI System
Test System
Staging System
Production System
Benutzer
Fifty Shades of Red
Feedback
Storage
Aber wie genau?
• Feedbackinhalt– Möglichst generisch
– Mit Code verbunden (Klasse, Methode, Zeile)
– Zeitpunkt
• Übertragung– HTTP/REST
• Anzeige für Entwickler– In der IDE, direkt am Code
– Filterbar
Fifty Shades of Red
EntwicklerLokaler
TestCI System
Test System
Staging System
Production System
Benutzer
Feedback
Storage
Tomcat Webserver
“Architektur”
Fifty Shades of Red
Client
(z.B. Code auf
Produktivsystem)
Confessional
REST API
Confessional
Database
IDE Client
(z.B. Eclipse
Plugin)
DEMO
Logger / Exception Feedback
Fifty Shades of Red
Schlechten Code erkennenprivate 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;
}
Fifty Shades of Red
DEMO
Database Performance Feedback
Fifty Shades of Red
DEMO
ThisShouldNeverHappenDemo
Fifty Shades of Red
Assertions
• Wer nutzt Assertions und wie?
• Wenn nur im Test, dann kein Unterschied zu JUnitAssertions
• Aber eigentlich ein schönes Konzept…
Fifty Shades of Red
DEMO
Assertion Feedback
Fifty Shades of Red
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)
Fifty Shades of Red
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
Fifty Shades of Red
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, …)
Fifty Shades of Red
Credits
https://www.destroyallsoftware.com/talks/a-whole-new-world
Fifty Shades of Red
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
Fifty Shades of Red
