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
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
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“
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
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
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
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 !
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
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
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!
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‘)
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“
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?
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)
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