Herzlich Willkommen!

…flipping default template layout
Spannend, listener connection …
Waiting geht‘s losstill ramping up...
und

Der 10-Punkte Plan
für den sicheren Weg zum
nicht-wartbaren Code
Benjamin Schmid
Software Architect

Oliver Pehnke
So...
Das große Stück

Anteil Wartungskosten in Softwareprojekten
~67% bis >90% der Gesamtkosten
W art ung & Verbesserung
Ent w ...
Punkt 1:

Die VerKlärungsphase

Analyse- und Entscheidung
Die Spielregeln für Projekte

1. Das Spiel kann anhand der Prozess-Anleitung nicht
gewonnen werden – Improvisation erforde...
Analyse: Fundament der Wartbarkeit

Die Herausforderung:
Gute Spezifikationen
• vollständig und präzise
• sind nicht einfa...
Punkt 2:
Die Wahl der richtigen Waffen

Technologien und Frameworks
Technische Lösungen für
nicht-technische Probleme

Einbinden von Hoffnungen
SOA
„Wieder verwendbarer Baustein“
JUnit.jar
„...
XML ready!
Frameworks: Den Rahmen finden

Richtig gewählt bedeutet
• effizienter
• fehlerfreier
• wartbarer

Falsch gewählt bedeutet
...
Punkt 3:
Die Rekrutierung

Team und Zusammenarbeit
Gegeneinander

WOMM Certification
…in 4 easy steps

1. Compile
(CVS update purely optional!)

2. Launch!
3. Test you code ...
Punkt 4:
Die hohe Kunst der Verschleierung

Namen und Code-Formatierung
Marry‘s Metamorphose
Name your babies

Compiler übersetzen – nicht Entwickler!
• Lesbare Methoden, Klassen und
Attributnamen
– die tun was sie ...
Marry‘s Metamorphose
Falsche Fährten legen

• Java Coding Conventions einhalten
• Keine Optimierungen auf Kosten der Lesbarkeit
• Lesbarkeit ho...
Punkt 5:
The swiss-army knife of Java: Vererbung

OO-Konzepte
Professionelle Polymorphie in Java

Was macht setVisible() nun eigentlich?
Kräftig umrühren

Exzessive Nutzung von extends führt zu
– Hohe Komplexität durch tiefe Hierarchieverteilung
– Starken Abh...
Niemals Verantwortung abgeben
Verändern von Verhalten
Vererbung:

Delegation:

A ist ein spezielles B
„Geklebt“

A hat/nut...
…oder gar auf andere hören!
Hinzufügen von Verhalten
Vererbung:

Event/Listener:

Hinzufügen durch Überladen
„Geklebt“

An...
Punkt 6:
Gordische Seilkünste

Module und Komponenten
Intelligent Design…

Rolle

Administrator
Rolle

Benutzer
Intelligent Design…

Manager

Textfield

Rolle

Administrator
Rolle

Benutzer

Session
…und Grenzen anerkennen

Modul

Manager

Textfield

Rolle

Administrator
Rolle

Modul

Modul

Benutzer

Session

Modul

Mo...
Unberührte Natur

“A good modular, componentized design means
minimizing the knowledge and dependency one
part of the syst...
Der Weg aus der Abhängigkeit

Wegweiser für eine
gute Modul-Einteilung
• Fachliche Ordnung
(„Fax-Service“, „Kontoverwaltun...
Punkt 6½:
Gordische Seilkünste II – Das Schwert

Schnittstellen
Nach AOP: VOP
Trennungsschmerzen
Schnittstellen sind Rollen mit austauschbarer Besetzung!
Schnittstellen einfach halten!
• Komplexität g...
Punkt 7:
Mute the fire-alarm

Fehlerbehandlung
Nur nicht aufgeben
Nicht-deterministischer Rechenapparat

Lautlose Fehlerkorrektur
Error-Handling: War was?

•
•

Fehler immer individuell und
vollständig behandeln oder …
… einpacken und weitergeben
– In ...
Forensische Medizin

Diagnostikmöglichkeiten einbauen
• Logs sind der Schlüssel zur Laufzeitdynamik
– Nicht nur Details - ...
Punkt 8:
Qualität ‚fühlen‘ lernen – Testen vermeiden

Testen und Messen
Warum die Chefs Tests wollen
Mythen zum Thema Testen
• „… hebt die Qualität“
• „… muss nur die QA“
• „… ist stupide und ei...
Entwickler und Tests

Gute Tests zu schreiben ist anspruchsvoll
• Nicht nur Pfade ablaufen, Ergebnisse auch prüfen
• Auch ...
Punkt 9:
Originell programmieren

Java Basics
Bloat your code
Tief schachteln

Masse gewinnen
Konstruktor vs. Bean
„Fette Konstruktoren“
… wachsen schnell durch Convenience-Parameter und
tiefe Hierarchiestufen
Klasse...
…und sei kreativ
Initialisierung mal anders

„richtig“ Null
Instanzen zählen…
I‘m a 3l33t h@x0r
static
– static Variablen:
• So nicht: public static HashSet aktuelleZahlen =
Session.getSprache().berec...
Punkt 10:
Die Autobiographie

Dokumentation
…ist selbsterklärend – denk ich
Was dokumentieren
• Code
(API zu 100%)
• Design
(nach Entwurf)
• Commits (Nachvollziehbark...
Oliver Pehnke
Software Engineer

… eine Frage hätte ich da
aber jetzt noch …
Benjamin Schmid
Software Architect
Vielen Dank für Ihre Aufmerksamkeit!

Besuchen Sie uns!

Foyer, Eingang Ballsaal
www.exxcellent.de

Quellen und Links zum ...
Nächste SlideShare
Wird geladen in …5
×

Der 10-Punkte Plan für den sicheren Weg zum nicht-wartbaren Code

490 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie
0 Kommentare
2 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
490
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
1
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
2
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Der 10-Punkte Plan für den sicheren Weg zum nicht-wartbaren Code

  1. 1. Herzlich Willkommen! …flipping default template layout Spannend, listener connection … Waiting geht‘s losstill ramping up… …speaker‘snich‘ ?! ….. Gleich for ego
  2. 2. und Der 10-Punkte Plan für den sicheren Weg zum nicht-wartbaren Code Benjamin Schmid Software Architect Oliver Pehnke Software Engineer
  3. 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. 4. Punkt 1: Die VerKlärungsphase Analyse- und Entscheidung
  5. 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. 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. 7. Punkt 2: Die Wahl der richtigen Waffen Technologien und Frameworks
  8. 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. 9. XML ready!
  10. 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. 11. Punkt 3: Die Rekrutierung Team und Zusammenarbeit
  12. 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. 13. Punkt 4: Die hohe Kunst der Verschleierung Namen und Code-Formatierung
  14. 14. Marry‘s Metamorphose
  15. 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. 16. Marry‘s Metamorphose
  17. 17. Falsche Fährten legen • Java Coding Conventions einhalten • Keine Optimierungen auf Kosten der Lesbarkeit • Lesbarkeit hoch bewerten
  18. 18. Punkt 5: The swiss-army knife of Java: Vererbung OO-Konzepte
  19. 19. Professionelle Polymorphie in Java Was macht setVisible() nun eigentlich?
  20. 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. 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. 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. 23. Punkt 6: Gordische Seilkünste Module und Komponenten
  24. 24. Intelligent Design… Rolle Administrator Rolle Benutzer
  25. 25. Intelligent Design… Manager Textfield Rolle Administrator Rolle Benutzer Session
  26. 26. …und Grenzen anerkennen Modul Manager Textfield Rolle Administrator Rolle Modul Modul Benutzer Session Modul Modul
  27. 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. 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. 29. Punkt 6½: Gordische Seilkünste II – Das Schwert Schnittstellen
  30. 30. Nach AOP: VOP
  31. 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. 32. Punkt 7: Mute the fire-alarm Fehlerbehandlung
  33. 33. Nur nicht aufgeben Nicht-deterministischer Rechenapparat Lautlose Fehlerkorrektur
  34. 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. 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. 36. Punkt 8: Qualität ‚fühlen‘ lernen – Testen vermeiden Testen und Messen
  37. 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. 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. 39. Punkt 9: Originell programmieren Java Basics
  40. 40. Bloat your code Tief schachteln Masse gewinnen
  41. 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. 42. …und sei kreativ Initialisierung mal anders „richtig“ Null
  43. 43. Instanzen zählen…
  44. 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. 45. Punkt 10: Die Autobiographie Dokumentation
  46. 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. 47. Oliver Pehnke Software Engineer … eine Frage hätte ich da aber jetzt noch … Benjamin Schmid Software Architect
  48. 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

×