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

536 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
536
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

×