Fifty Shades of Red

Fifty Shades of Red
Oder wie man es schafft, dass Entwickler (endlich) unter Ihrer eigenen
(schlechten) Software leiden müssen
Mirko Seifert, DevBoost GmbH
JUG Saxony Day | 02.10.2015 | Dresden
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?
Entwickler
Lokaler
Test
CI System
Test
System
Feedback
Storage
Fifty Shades of Red
Staging
System
Production
System
Benutzer
Aber wie genau?
• Feedbackinhalt
– Möglichst generisch
– Mit Code verbunden (Klasse, Methode, Zeile)
– Zeitpunkt
Entwickler
• Übertragung
Lokaler
Test
CI System
Test
System
Staging
System
Feedback
Storage
– HTTP/REST
• Anzeige für Entwickler
– In der IDE, direkt am Code
– Filterbar
Fifty Shades of Red
Productio
n System
Benutzer
“Architektur”
Client
(z.B. Code auf
Produktivsystem)
Confessional
REST API
Tomcat Webserver
Confessional
Database
Fifty Shades of Red
IDE Client
(z.B. Eclipse
Plugin)
DEMO
Logger / Exception Feedback
Fifty Shades of Red
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;
}
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 JUnit
Assertions
• 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
Danke!
Fragen?
[email protected]
Fifty Shades of Red