Herzlich Willkommen!

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

Auf dem Weg zu Unwartbarkeit
Die besten Strategien für den sicheren Erfolg!
Benjamin Schmid
Software Architect

Olive...
Das große Stück
Anteil Wartungskosten in Softwareprojekten
~67% bis >90% der Gesamtkosten
W art ung & Verbesserung
Ent w i...
Die Spielregeln für Projekte
1.
2.
3.
4.

Das Spiel kann anhand der Prozess-Anleitung nicht
gewonnen werden – Improvisatio...
Strategie #1:

Visionen einbringen
Analyse- und Entscheidung
Analyse: Fundament der Wartbarkeit

Gute Spezifikationen
Die Herausforderung:
• vollständig und präzise
• sind nicht einfa...
Graphische Spezfikationen
Graphische Spezifizikationen mal klar & eindeutig
…und viel muß es sein
Strategie #2:
Die Wahl der richtigen Waffen
Technologien und Frameworks
Tech.Lösungen für nicht-technische Probleme

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

Ungünstige Wahl:
• Einschränkungen
• Komplexität
• TechnikSelbstzweck

Gute Wahl:
• effizie...
Strategie #3:
Die Rekrutierung
Team und Zusammenarbeit
Gegeneinander

WOMM Certification
…in 4 easy steps

1. Compile
(CVS/SVN update purely optional!)

2. Launch!
3. Test you c...
Strategie #4:
Die hohe Kunst der Verschleierung
Namen und Code-Formatierung
Marry‘s Metamorphose
Falsche Fährten legen
Nun aber zur Preisfrage

Wenn a und b false sind, dann ist x:

a) 42!
b) z

c) y
d) x
d) x
Name your babies
Compiler übersetzen – Entwickler lesen!
• Lesbare Methoden, Klassen und
Attributnamen
– die tun was sie s...
Marry‘s Metamorphose
Strategie #5:
The swiss-army knife of Java: Vererbung
OO-Konzepte
Professionelle Polymorphie in Java

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

Extensive Nutzung von extends bewirkt
– Hohe Komplexität durch verteilte Logik
innerhalb der Hierarchie
...
Niemals Verantwortung abgeben
Verändern bzw. Hinzufügen von Verhalten in der OO
Vererbung:

Delegation bzw. Event/Listener...
Strategie #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 syste...
Der Weg aus der Abhängigkeit
Wegweiser für gute
Modul-Einteilungen / Dekomposition
• Fachliche Ordnung
(„Fax-Service“, „Ko...
Strategie #6½:
Gordische Seilkünste II – Das Schwert
Schnittstellen
Nach AOP: VOP
Trennungsschmerzen
Schnittstellen sind Rollen mit austauschbarer Besetzung!
Schnittstellen einfach halten!
• Komplexität g...
Strategie #7:
Mute the fire-alarm
Fehlerbehandlung
Nur nicht aufgeben
Nicht-deterministischer Rechenapparat

Lautlose Fehlerkorrektur
Error-Handling: War was?

•
•

Fehler immer individuell, vollständig und
korrekt behandeln oder …
… einpacken und weiterge...
Forensische Medizin
Diagnostikmöglichkeiten einbauen
• Logs sind der Schlüssel zur Laufzeitdynamik
• Nicht nur Details - a...
Strategie #8:
Originell programmieren
Java Basics
Bloat your code
Indirektion: Schlüssel zur OO

Masse gewinnen
…und sei kreativ
Initialisierung mal anders

„richtig“ Null
Instanzen zählen…
I‘m a 3l33t h@x0r

static Variablen/Mutables
– Pitfall!
public static HashSet aktuelleZahlen =
Session.getSprache().berech...
Strategie #9:
Qualität ‚fühlen‘ lernen – Testen vermeiden
Testen und Messen
Testen? Wir sind WOMM-zertifiziert!

“I don't need to test my programs.
I use error-correcting RAM (ECC)”
Entwickler und Tests

Gute Tests zu schreiben ist anspruchsvoll
•
•
•
•

Nicht nur Pfade ablaufen, Ergebnisse prüfen
Neben...
Strategie #10:
Die richtige 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!
… Zertifizierung bei uns am Stand!

http://www.exxcellent.de

Quel...
Nächste SlideShare
Wird geladen in …5
×

Auf dem Weg zu Unwartbarkeit - Die besten Strategien für den sicheren Erfolg!

330 Aufrufe

Veröffentlicht am

Auf dem Weg zu Unwartbarkeit - Die besten Strategien für den sicheren Erfolg!

Eine süffisante, praxisnahe Reise durch die Fallstricke der Softwareentwicklung

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

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

Keine Notizen für die Folie

Auf dem Weg zu Unwartbarkeit - Die besten Strategien für den sicheren Erfolg!

  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 Auf dem Weg zu Unwartbarkeit Die besten Strategien für den sicheren Erfolg! 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. Die Spielregeln für Projekte 1. 2. 3. 4. Das Spiel kann anhand der Prozess-Anleitung nicht gewonnen werden – Improvisation erforderlich Die fixen Termine und Budgets sind zu Beginn der Spielanleitung zu entnehmen Nicht die Fachlichkeit, sondern der Spielleiter entscheidet Wenn‘s kein Spass macht, machs‘d was falsch!
  5. 5. Strategie #1: Visionen einbringen Analyse- und Entscheidung
  6. 6. Analyse: Fundament der Wartbarkeit Gute Spezifikationen Die Herausforderung: • vollständig und präzise • sind nicht einfach (auch graphisch) Die Probleme: • Kommunikation – Kunde, Analyst, Entwickler haben eigene Vorstellungen • Konkretisierungen nötig Analyseergebnis ist die Basis von Allem Klarheit & Eindeutigkeit reduzieren die Risiken
  7. 7. Graphische Spezfikationen Graphische Spezifizikationen mal klar & eindeutig
  8. 8. …und viel muß es sein
  9. 9. Strategie #2: Die Wahl der richtigen Waffen Technologien und Frameworks
  10. 10. Tech.Lösungen für nicht-technische Probleme Einbinden von Hoffnungen SOA „Wieder verwendbarer Baustein“ JUnit „Applikation ist getestet“ Groovy „Wir sind agil & flexibel“ MochiKit „Es ist Web 2.0 und komfortabel“ CompanyFramework.jar „Manfestierter Unternehmensstyle & -qualität“
  11. 11. XML ready!
  12. 12. Frameworks: Den Rahmen finden Ungünstige Wahl: • Einschränkungen • Komplexität • TechnikSelbstzweck Gute Wahl: • effizienter • fehlerfreier • wartbarer Agilitäts-Verlust > Effizienz-Gewinn ? Strategien für den steinigen Weg – Wahllos Hinzu – Blind „den Standard“ – StringUtils neu erfinden
  13. 13. Strategie #3: Die Rekrutierung Team und Zusammenarbeit
  14. 14. Gegeneinander WOMM Certification …in 4 easy steps 1. Compile (CVS/SVN 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! Welcome as WOMM solutionist!
  15. 15. Strategie #4: Die hohe Kunst der Verschleierung Namen und Code-Formatierung
  16. 16. Marry‘s Metamorphose
  17. 17. Falsche Fährten legen
  18. 18. Nun aber zur Preisfrage Wenn a und b false sind, dann ist x: a) 42! b) z c) y d) x d) x
  19. 19. Name your babies Compiler übersetzen – Entwickler lesen! • 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 • Java Coding Conventions
  20. 20. Marry‘s Metamorphose
  21. 21. Strategie #5: The swiss-army knife of Java: Vererbung OO-Konzepte
  22. 22. Professionelle Polymorphie in Java Was bewirkt setVisible() eigentlich?
  23. 23. Kräftig umrühren Extensive Nutzung von extends bewirkt – Hohe Komplexität durch verteilte Logik innerhalb der Hierarchie – Starke, nicht-lösbare Abhängigkeiten – Vermischung von Zuständigkeiten – Versteckte Verhaltens- & Semantikänderungen
  24. 24. Niemals Verantwortung abgeben Verändern bzw. Hinzufügen von Verhalten in der OO Vererbung: Delegation bzw. Event/Listener: A ist ein spezielles B A hat/nutzt/verwendet B Enge, integrative Bindung Entkoppelt, einzeln wieder verwendbar
  25. 25. Strategie #6: Gordische Seilkünste Module und Komponenten
  26. 26. Intelligent Design… Rolle Administrator Rolle Benutzer
  27. 27. Intelligent Design… Manager Textfield Rolle Administrator Rolle Benutzer Session
  28. 28. …und Grenzen anerkennen Modul Manager Textfield Rolle Administrator Rolle Modul Modul Benutzer Session Modul Modul
  29. 29. 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 Was ist eine gute Komponentaufteilung? Wie sehen passenden Schnittstellen aus?
  30. 30. Der Weg aus der Abhängigkeit Wegweiser für gute Modul-Einteilungen / Dekomposition • Fachliche Ordnung („Fax-Service“, „Kontoverwaltung“) • Technische Schichten (GUI-, Business-Layer) • Wenige, unidirektionale Abhängigkeiten • Klares Gedankenmodell bzgl. Frage: Was gehört rein, was nicht? • Erfahrung
  31. 31. Strategie #6½: Gordische Seilkünste II – Das Schwert Schnittstellen
  32. 32. Nach AOP: VOP
  33. 33. 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. 34. Strategie #7: Mute the fire-alarm Fehlerbehandlung
  35. 35. Nur nicht aufgeben Nicht-deterministischer Rechenapparat Lautlose Fehlerkorrektur
  36. 36. Error-Handling: War was? • • Fehler immer individuell, vollständig und korrekt behandeln oder … … einpacken und weitergeben – – In geeignete, deklarierte Exceptions oder komfortable RuntimeException Dass bedeutet – Keine Details/Fehler verschlucken – auch wenn throws nervt (lieber: RuntimeException) – Fehlerhandling Alternativen, z.B. try {…} finally {…}
  37. 37. 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; Log-Levels/Kategorien
  38. 38. Strategie #8: Originell programmieren Java Basics
  39. 39. Bloat your code Indirektion: Schlüssel zur OO Masse gewinnen
  40. 40. …und sei kreativ Initialisierung mal anders „richtig“ Null
  41. 41. Instanzen zählen…
  42. 42. I‘m a 3l33t h@x0r static Variablen/Mutables – Pitfall! public static HashSet aktuelleZahlen = Session.getSprache().berechne(); – Good style: private final static String FOO = „buh“; (Immutable und Konstante) synchronized – In der der Regel: Vermeiden! Besser: java.util.concurrent verwenden – Wenn doch, erst mal Gegenprobe: volatile bekannt?
  43. 43. Strategie #9: Qualität ‚fühlen‘ lernen – Testen vermeiden Testen und Messen
  44. 44. Testen? Wir sind WOMM-zertifiziert! “I don't need to test my programs. I use error-correcting RAM (ECC)”
  45. 45. Entwickler und Tests Gute Tests zu schreiben ist anspruchsvoll • • • • Nicht nur Pfade ablaufen, Ergebnisse prüfen 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‘)
  46. 46. Strategie #10: Die richtige Autobiographie Dokumentation
  47. 47. …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. 48. Oliver Pehnke Software Engineer … eine Frage hätte ich da aber jetzt noch … Benjamin Schmid Software Architect
  49. 49. Vielen Dank für Ihre Aufmerksamkeit! Besuchen Sie uns! … Zertifizierung bei uns am Stand! http://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

×