1. Herzlich Willkommen!
…flipping default template layout
Spannend, listener connection …
Waiting geht‘s losstill ramping up…
…speaker‘snich‘ ?! …..
Gleich for ego

2. und
Der 10-Punkte Plan
für den sicheren Weg zum
nicht-wartbaren Code
Benjamin Schmid
Software Architect
Oliver Pehnke
Software Engineer

3. Das große Stück
Anteil Wartungskosten in Softwareprojekten
~67% bis >90% der Gesamtkosten
W art ung & Verbesserung
Ent w icklung
Quellen:
Zelkowitz et al. (1970)
”Principles of Software Engineering and Design”
Moad, J. (1990)
“Maintaining the competitive edge”
• Projektlaufzeit überdauert oft Projekt-Mitarbeiter
• Wartbarkeit entscheidend für langfristigen Projekterfolg

4. Punkt 1:
Die VerKlärungsphase
Analyse- und Entscheidung

5. Die Spielregeln für Projekte
1. Das Spiel kann anhand der Prozess-Anleitung nicht
gewonnen werden – Improvisation erforderlich
2. Die fixen Termine und Budgets
sind zu Beginn der Spielanleitung zu entnehmen
3. Nicht die Fachlichkeit,
sondern der Spielleiter entscheidet

6. Analyse: Fundament der Wartbarkeit
Die Herausforderung:
Gute Spezifikationen
• vollständig und präzise
• sind nicht einfach
(auch graphisch)
Die Probleme:
• Kommunikation
– Kunde, Analyst, Entwickler
haben eigene Vorstellungen
• Konkretisierungen
erforderlich
• Analyse ist die Basis
• Klar & eindeutig = reduziert Risiko

7. Punkt 2:
Die Wahl der richtigen Waffen
Technologien und Frameworks

8. Technische Lösungen für
nicht-technische Probleme
Einbinden von Hoffnungen
SOA
„Wieder verwendbarer Baustein“
JUnit.jar
„Applikation ist getestet“
Groovy.jar
„Wir sind agil & flexibel“
MochiKit.js
„Es ist Web 2.0 und komfortabel“
CompanyFramework.jar
„Code ist in Unternehmensstyle
& -qualität“

9. XML ready!

10. Frameworks: Den Rahmen finden
Richtig gewählt bedeutet
• effizienter
• fehlerfreier
• wartbarer
Falsch gewählt bedeutet
• Einschränkungen
• höhere Komplexität
• unnötige Beschäftigung
mit Technik
Falltüren bei der Auswahl von Frameworks
– Wahllos einbinden
– Blind auf „den Standard“ setzen
– Verzichten und das Rad neu erfinden
Realer Verlust >> Erträumter Gewinn

11. Punkt 3:
Die Rekrutierung
Team und Zusammenarbeit

12. Gegeneinander
WOMM Certification
…in 4 easy steps
1. Compile
(CVS update purely optional!)
2. Launch!
3. Test you code path
(Unless code change is less than 5 lines
or you are a real professional)
4. Check-in!

13. Punkt 4:
Die hohe Kunst der Verschleierung
Namen und Code-Formatierung

14. Marry‘s Metamorphose

15. Name your babies
Compiler übersetzen – nicht Entwickler!
• Lesbare Methoden, Klassen und
Attributnamen
– die tun was sie sagen
– konstante Begrifflichkeiten
– griffige Namen
• Namen und Bedeutung synchron
halten
– Namen sind Orientierung im Code
und Design

16. Marry‘s Metamorphose

17. Falsche Fährten legen
• Java Coding Conventions einhalten
• Keine Optimierungen auf Kosten der Lesbarkeit
• Lesbarkeit hoch bewerten

18. Punkt 5:
The swiss-army knife of Java: Vererbung
OO-Konzepte

19. Professionelle Polymorphie in Java
Was macht setVisible() nun eigentlich?

20. Kräftig umrühren
Exzessive Nutzung von extends führt zu
– Hohe Komplexität durch tiefe Hierarchieverteilung
– Starken Abhängigkeiten
– Vermischung von Zuständigkeiten
– Versteckten Verhaltens-/Semantikveränderungen

21. Niemals Verantwortung abgeben
Verändern von Verhalten
Vererbung:
Delegation:
A ist ein spezielles B
„Geklebt“
A hat/nutzt/verwendet B
„Gesteckt“
Enge, integrative Bindung
Entkoppelt, einzeln wieder verwendbar

22. …oder gar auf andere hören!
Hinzufügen von Verhalten
Vererbung:
Event/Listener:
Hinzufügen durch Überladen
„Geklebt“
Anfügen als Listener
„Gesteckt“
Enge, integrative Bindung
Entkoppelt, einzeln wieder verwendbar
Listener auch wieder entfernen !

23. Punkt 6:
Gordische Seilkünste
Module und Komponenten

24. Intelligent Design…
Rolle
Administrator
Rolle
Benutzer

25. Intelligent Design…
Manager
Textfield
Rolle
Administrator
Rolle
Benutzer
Session

26. …und Grenzen anerkennen
Modul
Manager
Textfield
Rolle
Administrator
Rolle
Modul
Modul
Benutzer
Session
Modul
Modul

27. Unberührte Natur
“A good modular, componentized design means
minimizing the knowledge and dependency one
part of the system has to have about another.”
Modul
Modul
Modul
Die Preisfragen sind also:
– Was ist eine gute Komponentaufteilung?
– Wie sehen passenden Schnittstellen aus?

28. Der Weg aus der Abhängigkeit
Wegweiser für eine
gute Modul-Einteilung
• Fachliche Ordnung
(„Fax-Service“, „Kontoverwaltung“)
• Technische Schichten
(GUI-, Business-Layer)
• Wenige, unidirektionale Abhängigkeiten
• Klares Gedankenmodell:
Was gehört rein, was nicht?
• Erfahrung

29. Punkt 6½:
Gordische Seilkünste II – Das Schwert
Schnittstellen

30. Nach AOP: VOP

31. Trennungsschmerzen
Schnittstellen sind Rollen mit austauschbarer Besetzung!
Schnittstellen einfach halten!
• Komplexität gehört in die
Implementierung
• “If you’re in doubt – leave it out !”
• Bei Klassen: private, etc. nutzen
• Neue Rollen erkennen und via
Refactoring frühzeitig abbilden
Veröffentliche Schnittstellen sind
Vertragsbestandteil einer Klasse und
nachträglich schwer zu ändern

32. Punkt 7:
Mute the fire-alarm
Fehlerbehandlung

33. Nur nicht aufgeben
Nicht-deterministischer Rechenapparat
Lautlose Fehlerkorrektur

34. Error-Handling: War was?
•
•
Fehler immer individuell und
vollständig behandeln oder …
… einpacken und weitergeben
– In geeignete, deklarierte Exceptions
– Sonst als RuntimeException
•
•
•
Keine Details bzw. komplette Fehler verschlucken
Keine Fehler „behandeln“ nur weil sie
per throws deklariert sind
Auch try { … } finally { … } nutzen

35. Forensische Medizin
Diagnostikmöglichkeiten einbauen
• Logs sind der Schlüssel zur Laufzeitdynamik
– Nicht nur Details - auch Eckpunkte dokumentieren
„Versuche Fax ID:4711 an Empfänger Y zu senden“
– Kein Sonderzeichen-Krieg;
Logger-Levels & -Kategorien nutzen!

36. Punkt 8:
Qualität ‚fühlen‘ lernen – Testen vermeiden
Testen und Messen

37. Warum die Chefs Tests wollen
Mythen zum Thema Testen
• „… hebt die Qualität“
• „… muss nur die QA“
• „… ist stupide und einfach“
Wartbarkeit und Tests
• Blackbox
Whitebox
• Spezifikation
Testfälle
• Wertvolles Werkzeug
in der Entwicklung (Team)
“I don't need to test my programs.
I have an error-correcting modem.”

38. Entwickler und Tests
Gute Tests zu schreiben ist anspruchsvoll
• Nicht nur Pfade ablaufen, Ergebnisse auch prüfen
• Auch die Nebenpfade und Randbereiche bedenken
• Automatisierbar und Regressionsfähig halten
• Unbedarft gegen den Vertrag der API testen
Fehlern vorbeugen
• Konstruktive Mittel
• Code Robustheit
• Diagnostik
(‚Fehler durch Design verhindern‘)
(Fail gracefully)
(‚schnelle Fehlerlokalisierung‘)

39. Punkt 9:
Originell programmieren
Java Basics

40. Bloat your code
Tief schachteln
Masse gewinnen

41. Konstruktor vs. Bean
„Fette Konstruktoren“
… wachsen schnell durch Convenience-Parameter und
tiefe Hierarchiestufen
Klassen-Attribute via
– Konstruktor signalisiert Kompositon
– Property signalisiert Konfiguration
„Immutable objects are
the "first class citizens" of
the object world“

42. …und sei kreativ
Initialisierung mal anders
„richtig“ Null

43. Instanzen zählen…

44. I‘m a 3l33t h@x0r
static
– static Variablen:
• So nicht: public static HashSet aktuelleZahlen =
Session.getSprache().berechne();
• So ja:
private final static String FOO =
„buh“;
– static Methoden: Jein
– static inner class: Ja
synchronized
– In der der Regel: Vermeiden
– Wenn doch: volatile bekannt?

45. Punkt 10:
Die Autobiographie
Dokumentation

46. …ist selbsterklärend – denk ich
Was dokumentieren
• Code
(API zu 100%)
• Design
(nach Entwurf)
• Commits (Nachvollziehbarkeit)
Wie dokumentieren
•
•
•
Nicht was, sondern die
Hintergründe (Warum, Wie)
Sagen was der Code nicht sagt
JavaDoc ausnutzen
– Zusammenhänge mit @link, @see
– Parameter (Nullable, Defaults)
und Rückgabewerte (Typ)

47. Oliver Pehnke
Software Engineer
… eine Frage hätte ich da
aber jetzt noch …
Benjamin Schmid
Software Architect

48. Vielen Dank für Ihre Aufmerksamkeit!
Besuchen Sie uns!
Foyer, Eingang Ballsaal
www.exxcellent.de
Quellen und Links zum Thema
The Daily WTF
Tips for maintainable Java code
It Works on My Machine
Unmaintainable code
http://worsethanfailure.com/
http://www.squarebox.co.uk/download/javatips.html
http://jcooney.net/archive/2007/02/01/42999.aspx
http://mindprod.com/jgloss/jgloss.html