- Tests dürfen nie zum Selbstzweck existieren - "weil man das so macht"
- Abdeckung ist vollkommen egal
- Nur wichtiger Code muss getestet sein
- Nur wichtiger Code muss getestet sein
- Wann ist ein Test wichtig? Wenn er Klärung bringt
- Bringt diese Zeile Code mir etwas?
- Befriedigt sie nur irgendwelche Frameworks oder Patterns?
- Wozu braucht man während eines Rennens eine Klimaanlage oder elektrische Fensterheber?
2. Alles hat seine Kosten
- Meistens kostet es dich Komplexität
- Und damit den Verstand
- Vergleichbar mit Werbung und Aufmerksamkeit
- Cyclomatic Complexity / Cognitive Complexity
- Physik: überschüssige Energie wird Wärme; Code: überschüssiger Code wird Komplexität
- Quattro-Autos waren schwerer als die Konkurrenz, brauchten mehr Leistung, die Fahrer mussten lernen, mit den Wagen zu fahren
3. Verbaue dir nicht deine Möglichkeiten
- Änderungen werden kommen (Kunde)
- Änderungen werden nötig sein (Architektur)
- Du wirst Änderungen vornehmen wollen (Aufräumen)
- Es wird inkompatible Änderungen geben (DB)
- Keine Annahmen treffen, explizit sein
- Nicht zuviel in einer Aufrufhierarchie machen
- Das Differential muss auf der Rennstrecke tauschbar sein
## Zusammenfassung
Rallye-Meisterschaften stellen die Fahrzeuge, ihre Fahrer und die Konstrukteure vor ganz besondere Herausforderungen. Im Gegensatz zu Rundrennen wird hier nicht auf speziell konstruierten Strecken, sondern auf abgesperrten Straßen- und Schotterabschnitten bei Wind und Wetter gegen die Uhr gefahren. Dabei reicht die Variation von waldigen Strecken in Finnland bis zum afrikanischen Kontinent. Um diesen stark unterschiedlichen Ansprüchen zu genügen und die Fahrzeuge derartig anpassbar zu gestalten, muss vor allem eins gegeben sein: Simplizität.
Ich möchte bei meinem Vortrag Parallelen zwischen der Softwareentwicklung und dem Rallyefahren herausarbeiten und versuchen, Prinzipien aus dem Sport auf unsere Tätigkeit als Entwickler anzuwenden.
Wie schafft man es beispielsweise seine Software so zu konstruieren, dass man am Straßenrand das Differential auswechseln kann? Wieviel Schrauben muss man am Kotflügel lösen, um mitten im Sprint eine größere Anpassung an der Architektur vorzunehmen?
Dabei soll auch nicht davor zurückgeschreckt werden, mit alteingesessenen Mustern und Grundsätzen zu brechen, um herauszufinden, ob sie wirklich so universell sind, wie es viele glauben. Denn: ohne radikal zu denken, schafft man es nicht, von 0 auf 100 in unter 2,6 Sekunden auf Schotter zu beschleunigen.
## Dramatis persona
Aus Goslar stammend und mit Braunschweig als Wahlheimat arbeite ich seit mehr als 10 Jahren als Javaentwickler in allen Bereichen, die Software zu bieten hat. Dabei interessiert mich am Meisten die Meta-Seite der Entwicklung: wie baut man Code, der noch in der fernen Zukunft flexibel und wartbar ist? Wie kann man zusammen an Software arbeiten, ohne sich gegenseitig auf die Füße zu treten? Dabei beschäftige ich mich nicht nur mit Java allein, sondern habe im Bereich Cluster-Computing Kotlin zu schätzen gelernt und beim privaten Programmieren Clojure entdeckt und mich dabei Hals über Kopf darin verliebt.
Josha von Gizycki
5 years ago