Am Dienstag, den 2.2.2016, war ich wieder auf der OOP. Es gab viele interessante Vorträge, die ich hier kurz zusammenfassen möchte.
Wider die Mikroskop-Falle – Die wahren Probleme finden
Den Start am Dienstag macht Dr. Gernot Starke, der jedes Jahr auf der OOP sein „Unwesen treibt“. Andere kennen ihn ggf. von seinen Büchern, z.B. „Effektive Softwarearchitekturen“. In seinem Vortrag ging er darauf ein, dass wir manchmal im Detail an Problemen herumschrauben, die im Großen gar keine Rolle spielen. Als Bild zeigte er Karamba als super Rostentferner auf, um verrostete Schrauben zu lösen. Was natürlich nichts bringt, wenn das Auto, was an der Schraube hängt, gerade zur Schrottpresse unterwegs ist.
Seine Empfehlung war, dass man zuerst anhand eines Qualitätsbaums (nach ISO 25010) eine Breitensuche nach eventuellen Problemen durchführt. Deren Auftreten und Risiko bewertet man dann und taucht gezielter in die Problemsuche ab. Auf die Art übersieht man weniger und konzentriert sich auf die wichtigen Dinge. Zur Umsetzung wurden Stichworte wie eine Stakeholder-Map („Kenne Deine Kunden“) oder ATAM (Architecture Tradeoff Analysis Method) genannt.
Der Vortrag brachte für mich zwar nur Altbekanntes, zeigte dies aber noch einmal gut zusammenfasst auf. Und es schadet nicht, immer einmal wieder daran erinnert zu werden, einen Schritt zurückzugehen, um ein größeres Bild zu sehen.
Keynote: Testen heißt Gas geben
Dr. Frank Simon hielt die erste Keynote des Tages. Er wollte mit dem Bild des Testers aufräumen, dessen einziger Job es ist, alles kaputt zu machen. In der Tat gab es früherer Definitionen eines Testers, der genau dies tun sollte. Laut Dr. Simon hat sich dies aber geändert.
Zum Testen gehöre mehr als die Funktionalität. Auch sinnvolle Anforderungen muss ein Tester prüfen, da er sonst nicht weiß, was er für die Stakeholder testen soll. Ebenso zählt dazu auch ein Test des Prozesses, der Dokumentation, der Software und der Architektur. Es sind also zahlreiche Abläufe, in die ein Tester eingebunden werden kann und die man erst einmal nicht damit verbindet.
Mir gefiel das neue Bild des Testers. Am Tag zuvor hatte mir ein Kollege erst wieder gesagt, dass ein Tester nur dazu da ist, alles kaputt zu machen – und deswegen ein Entwickler auch kein guter Tester sei, weil er das Kaputtmachen nicht könne. Das sehe ich anders. Denn gerade mit der Definition oben können Entwickler sehr gute Tester sein.
Der restliche Teil der Keynote war eher eine Werbeveranstaltung für die ISTQB-Trainings und –Zertifizierung, sodass ich davon weniger mitgenommen habe.
Theorie leuchtet ein, Praxis ist einleuchtender
Der Untertitel von Mahbouba Gharbis Vortrag war „Architekturbewertung live und in Farbe“. Unter „live“ hatte ich mir zwar etwas anderes vorgestellt, als das Durchsprechen eines realen Anwendungsfalles und wie Gharbi dabei vorgegangen ist, dennoch stellte der Vortrag einen guten Ansatz dar, wie man Architektur bewerten kann. Extrem kurz zusammengefasst kann sagen: Es handelt sich um ATAM (Architecture Tradeoff Analysis Method).
Die Idee dahinter ist sehr einfach: Man schreibt zeilenweise alle Anforderungen auf, die man an das System bzw. die Software hat. Dabei geht man am einfachsten den Qualitätsbaum durch und erstellt zu den einzelnen nichtfunktionalen Anforderungen Szenarien, die man prüfen will (zusammen mit Sender, Nachricht, Umgebung und Reaktion). In den Spalten fasst man alle Design- oder Architekturentscheidungen zusammen, die man getroffen hat. Daraus ergibt sich eine Matrix, in die man einträgt, ob eine Entscheidung die Anforderung unterstützt, trivialerweise unterstützt, ihr widerspricht oder ob es egal ist. Nach der Eintragung liest man sowohl zeilenweise ab, ob Anforderungen mit den Entscheidungen gar nicht umgesetzt werden können oder gar vergessen wurden. Umgekehrt erkennt man, ob Entscheidungen getroffen wurden, die gar keine Anforderung adressieren oder die Umsetzung von Anforderungen verhindern.
An der Menge des Textes merkt man: Mir hat der Vortrag sehr gut gefallen und obwohl die Idee dahinter simpel ist, kannte ich sie noch nicht und hoffe, sie irgendwann einmal einsetzen zu dürfen.
Keynote: Vernetzte Software frisst die Welt
Dies war der reißerische Titel der zweiten Keynote, die Sascha Lobo gehalten hat. Einige kennen ihn ggf. von seiner Spiegel-Kolumne oder von seiner Aktivität als Blogger. Lobo bezeichnet sich selbst als reiner Anwender ohne jegliche Programmiererfahrung.
Die Essenz seines Vortrags war, dass wir als Entwickler eine ethische Aufgabe haben, wenn es um die immer breitere Vernetzung der Welt geht. In der heutigen Gesellschaft gilt: „Es gibt keine natürliche Beschränkung der Datenbegeisterung.“ Das heißt, wenn es einen Datensammel-/-auswertedienst gibt, der den Nutzern irgendein Problem löst, wird jeglicher Gedanke an Datenschutz fallen gelassen. Deswegen müssen Entwickler an mögliche Angriffszenarien denken, damit diese Daten sicher sind. Aber auch ethische Entscheidungen, wie der Abgasskandal bei VW, bei dem „irgendein“ Entwickler ja die Software geschrieben haben muss, zählen auch dazu. Lobo möchte vermeiden, dass in der Gemeinschaft ein Bild des bösen Entwicklers oder Hackers entsteht.
Der Vortrag war inhaltlich als auch von der Form sehr gut. Man merkt, dass Sascha Lobo gerne und gut redet, auch wenn der Vortrag am Anfang wie auswendig gelernt und aufgesagt wirkte. Es gab viele Pointen und nachdenkliche Anekdoten. Im Kern ging es in eine ähnliche Richtung wie Martin Fowlers „We are not code monkeys“ vor zwei Jahren auf der OOP.
Langlebige Softwarearchitekturen – Technische Schulden beherrschen und behandeln
Für den Vortrag machte Gernot Starke am Morgen bereits Werbung, wodurch es ein glücklicher Zufall war, dass ich den Vortrag im Vorfeld ebenfalls ausgewählt hatte. Dr. Carola Lilienthal definierte technische Schulden als „bewusste und unbewusste Entscheidungen, die langfristig zu Mehrkosten führen“.
Maßnahmen gegen technische Schulden sind dabei:
- regelmäßige Architekturdiskussionen
- Weiterbildung der Architekten und Entwickler
- Automatisiertes Testen und Refactoring
- regelmäßige Architekturanalyse und -Erneuerung
Sinnvoll ist der Abbau von technischen Schulden, weil damit hohe Kosten verbunden sind. So zeigte Dr. Lilienthal eine (nicht repräsentative) Messung, bei der ein Entwickler im Schnitt nur 30% der Zeit damit verbringt ein Problem zu lösen und den Code zu schreiben und die restlichen 70% mit dem Verstehen des Codes. Interessant fand ich auch die Anmerkungen, dass ein Schichtenmodell (z.B. mit UI, App und Data) nicht ausreicht, sondern dass auch die Komponenten der Software in dem Modell erkennbar sein müssen.
Am Ende des Vortrags zeigte Dr. Lilienthal noch, dass es eine Verbindung gibt zwischen kognitiver Wahrnehmung und einer einfachen und verständlichen Architektur, da sich beide auf ähnliche Strukturen und Mechanismen abstützen (z.B. Mustern, Hierarchiebildung und Modularität).
Objects in the Mirror
Kurz: Frank Buschmann und Kevlin Henney zeigten Auszüge und Zitate aus zahlreichen Büchern und Berichten seit den 1960ern, die die Entwicklung und Bewertung der Objektorientierung zeigten. Ich gebe zu, dass ich mir mehr erhofft hatte, aber das Vorlesen von Buchauszügen ist einfach nicht spannend. So war es auch nicht schlimm, dass ich 15 Minuten eher zum Zug musste.
Abschließend
Wie immer war die OOP eine Reise wert. Leider finde ich die Kosten von fast 1500 Euro für einen Tag viel zu hoch, was viele (vor allem kleinere) Firmen abschreckt, ihre Mitarbeiter dorthin zu schicken.
