Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
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

612 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

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

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.

×