Neuschreiben
nicht empfohlen
Dirk Haun
www.geeklog.net
Neuschreiben von
Applikationen
Vita
• GeldKarten-Terminal
• PDAs & Smartphones
• Service-Level-
Management
• Dokumenten-
Konvertierung
• Open Source CMS
Agenda
• Motivation
• Don't do it!
• Abhilfen
• Vermeidung
Warum will man
Neuschreiben?
• Rational:
Probleme mit der Architektur
• Irrational:
Programmer's Ego
Motivation: Architektur
• ursprünglich:
"sauberer" Entwurf
• nach Veröffentlichung
viele neue Feature-
Wünsche
➡Klarheit l...
Motivation: Architektur
• "bessere" Architektur
• leichter wartbar
• aus Fehlern gelernt
Motivation: Ego
• alter Code ist nicht
"sexy"
• Unwille, Code anderer
Leute zu pflegen
• persönliche Vorlieben
vs. existier...
Agenda
• Motivation
• Don't do it!
• Abhilfen
• Vermeidung
Neuschreiben
braucht (mehr) Zeit
• Was liefert man in der
Zwischenzeit aus?
• Verlust von Kunden,
Bedeutung, Geld
Stillstand vermeiden?
• Zwei Teams?
‣ Woher kommen all
die Leute?
‣ Moving Target
• "Maintenance Mode"
für die alte Versio...
Verlust von Details
• alte Funktionalität
wieder herstellen
‣ wirklich alles
dokumentiert?
• Workarounds für
Real-World-Pr...
No software is an island
• Software existiert
nicht im Vakuum
• Kompatibilität mit
3rd-Party-
Applikationen
• Gesamtfunkti...
Kann es wirklich nur
besser werden?
• manchmal keine
"bessere" Lösung
• alte Fehler
‣ Umfeld, Zeitdruck
• neue Fehler
‣ Le...
Ausnahmen?
• Wechsel der
Technologie
• In-House-Tools
• Neufokussierung
Agenda
• Motivation
• Don't do it!
• Abhilfen
• Vermeidung
Personally I believe that some
systems just require some love,
and radical refactoring, to
breathe new life into them.
-- ...
Refactoring
• Module identifizieren
• problematische
Stellen identifizieren
‣ Flaschenhälse
‣ unübersichtlicher
Code
Refactoring: Tests
• Unit-/Component-
Tests!
‣ für jeden Bug
➡lohnt sich auch schon
für die laufende
Entwicklung
• Module ...
Positive Nebeneffekte
• besseres Verständnis
des Systems
• bessere Aufwands-
Abschätzungen
Agenda
• Motivation
• Don't do it!
• Abhilfen
• Vermeidung
Spezifikationen?
• bessere Specs?
‣ schön wär's ...
• flexibel sein
‣ TDD, Agile
• kein Verzicht, aber
weg von starren
Spezi...
Planning is an important
learning exercise, (...)
Plans, on the other hand, are
overrated.
-- Mary Poppendieck
Rotting Code
• Wie ist das passiert?
‣ Druck,
Zeitmangel?
‣ Inkompetenz?
• Ursachenforschung
‣ Was kann man
dagegen tun?
Mehr Kommunikation!
• Projekt-intern
• mit Kunden/Usern
• Entwicklung
Marketing Kunden
• Vorteil(?) für
OpenSource-Projekte
Zusammenfassung
• Verlust von ...
‣ Marktanteil / Bedeutung
‣ Funktionalität
‣ 3rd-Party-Applikationen
• alte Fehler wiederholen
• neue Ar...
Abhilfen
• Refactoring statt Neuschreiben
• Test Driven Development, Agile
• Ursachenforschung:
‣ Was ging beim letzten Ma...
Ressourcen
• Joel on Software
(Buch und Website)
• Agile Software
Development
• Lean Software
Development
P.S. Die Stichwo...
Credits
• Photos via flickr.com,
thanks to: Hopkinsii,
striatic, paul goyette, Kazze,
adrenalin, ikelee, Auntie P.,
frozenc...
Neuschreiben nicht empfohlen
Nächste SlideShare
Wird geladen in …5
×

Neuschreiben nicht empfohlen

492 Aufrufe

Veröffentlicht am

Why you shouldn't rewrite an existing application from the ground up (German version).

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

  • Gehören Sie zu den Ersten, denen das gefällt!

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

Keine Notizen für die Folie

Neuschreiben nicht empfohlen

  1. 1. Neuschreiben nicht empfohlen Dirk Haun www.geeklog.net
  2. 2. Neuschreiben von Applikationen
  3. 3. Vita • GeldKarten-Terminal • PDAs & Smartphones • Service-Level- Management • Dokumenten- Konvertierung • Open Source CMS
  4. 4. Agenda • Motivation • Don't do it! • Abhilfen • Vermeidung
  5. 5. Warum will man Neuschreiben? • Rational: Probleme mit der Architektur • Irrational: Programmer's Ego
  6. 6. Motivation: Architektur • ursprünglich: "sauberer" Entwurf • nach Veröffentlichung viele neue Feature- Wünsche ➡Klarheit leidet ➡Lösung(?): Neuschreiben!
  7. 7. Motivation: Architektur • "bessere" Architektur • leichter wartbar • aus Fehlern gelernt
  8. 8. Motivation: Ego • alter Code ist nicht "sexy" • Unwille, Code anderer Leute zu pflegen • persönliche Vorlieben vs. existierender Code
  9. 9. Agenda • Motivation • Don't do it! • Abhilfen • Vermeidung
  10. 10. Neuschreiben braucht (mehr) Zeit • Was liefert man in der Zwischenzeit aus? • Verlust von Kunden, Bedeutung, Geld
  11. 11. Stillstand vermeiden? • Zwei Teams? ‣ Woher kommen all die Leute? ‣ Moving Target • "Maintenance Mode" für die alte Version? ‣ Was ist ein Bug?
  12. 12. Verlust von Details • alte Funktionalität wieder herstellen ‣ wirklich alles dokumentiert? • Workarounds für Real-World-Probleme
  13. 13. No software is an island • Software existiert nicht im Vakuum • Kompatibilität mit 3rd-Party- Applikationen • Gesamtfunktionalität
  14. 14. Kann es wirklich nur besser werden? • manchmal keine "bessere" Lösung • alte Fehler ‣ Umfeld, Zeitdruck • neue Fehler ‣ Lernprozess
  15. 15. Ausnahmen? • Wechsel der Technologie • In-House-Tools • Neufokussierung
  16. 16. Agenda • Motivation • Don't do it! • Abhilfen • Vermeidung
  17. 17. Personally I believe that some systems just require some love, and radical refactoring, to breathe new life into them. -- Tim Penhey
  18. 18. Refactoring • Module identifizieren • problematische Stellen identifizieren ‣ Flaschenhälse ‣ unübersichtlicher Code
  19. 19. Refactoring: Tests • Unit-/Component- Tests! ‣ für jeden Bug ➡lohnt sich auch schon für die laufende Entwicklung • Module schrittweise um-/neuschreiben
  20. 20. Positive Nebeneffekte • besseres Verständnis des Systems • bessere Aufwands- Abschätzungen
  21. 21. Agenda • Motivation • Don't do it! • Abhilfen • Vermeidung
  22. 22. Spezifikationen? • bessere Specs? ‣ schön wär's ... • flexibel sein ‣ TDD, Agile • kein Verzicht, aber weg von starren Spezifikationen
  23. 23. Planning is an important learning exercise, (...) Plans, on the other hand, are overrated. -- Mary Poppendieck
  24. 24. Rotting Code • Wie ist das passiert? ‣ Druck, Zeitmangel? ‣ Inkompetenz? • Ursachenforschung ‣ Was kann man dagegen tun?
  25. 25. Mehr Kommunikation! • Projekt-intern • mit Kunden/Usern • Entwicklung Marketing Kunden • Vorteil(?) für OpenSource-Projekte
  26. 26. Zusammenfassung
  27. 27. • Verlust von ... ‣ Marktanteil / Bedeutung ‣ Funktionalität ‣ 3rd-Party-Applikationen • alte Fehler wiederholen • neue Architektur, neue Fehler Gefahren
  28. 28. Abhilfen • Refactoring statt Neuschreiben • Test Driven Development, Agile • Ursachenforschung: ‣ Was ging beim letzten Mal schief? • Kommunikation verbessern
  29. 29. Ressourcen • Joel on Software (Buch und Website) • Agile Software Development • Lean Software Development P.S. Die Stichworte sind verlinkt.
  30. 30. Credits • Photos via flickr.com, thanks to: Hopkinsii, striatic, paul goyette, Kazze, adrenalin, ikelee, Auntie P., frozenchipmunk, Kevin Labianco, fallsroad, photo.bugz, tim_d, lagiuspo, Nathan James, ladyphoenixx_1999, Grim Reaper With A Lawnmower, re-Verse, amuk2006, Pathfinder Linden, Gigglejuice, manuki Bilder und Flickr-Usernamen sind verlinkt.

×