SlideShare ist ein Scribd-Unternehmen logo
1 von 91
Downloaden Sie, um offline zu lesen
!
Erfolgreiche
Rewrites
Hallo, guten morgen Nürnberg! Ich bin Johann, und nicht ganz echter CTO.
Erst einmal herzlichen Glückwunsch an allen anwesenden Weltmeister. Wer hat das Spiel geguckt? Wer hat mehr als 6 Stunden Schlaf bekommen? Wer hat
weniger als 6 Stunden Schlaf bekommen? Wer hat weniger als 4 Stunden Schlaf bekommen? Wer hat weniger als 2 Stunden Schlaf bekommen? Respekt.
Fußball für Developer
Team oder Rockstar?
Fußball ist eigentlich für uns auch interessant. Ähnlich wie Softwareerstellung ist es ein komplexes adaptives System, und deshalb gelten einige Regeln von
dort auch für uns. Gucken wir doch mal - erste Frage: Team oder Rockstar, wer gewinnt am Ende?
Fußball für Developer
Kann ein Junior das
Projekt rocken?
Und überhaupt, wenn schon nicht die Rockstars zählen - kann ein Junior derjenige sein, der das Projekt am Ende zum Goal bringt?
Fußball für Developer
Pairing rocks!
Faktisch war es nicht ein Junior, sondern zwei. Von der verdammten Bank.
Wer von Euch macht gerade einen 

Rewrite?
!
Es gibt ja einen Grund, warum ihr hier seid. Also mal direkt gefragt - wer von Euch macht gerade einen Rewrite?
Wer von Euch plant gerade einen 

Rewrite?
!
Wer plant einen in Zukunft? 
Genau die Leute möchte ich in meinem Vortrag sehen.
Wer von Euch würde gerne einen 

Rewrite machen?
!
Und nicht zuletzt: Wer von Euch würde gerne einen Rewrite machen? Jemand mit einer Legacy-Applikation da, der keinen Rewrite möchte?
Ich bin hier um Euch das
auszureden.
!
Ich bin heute hier um Euch das auszureden.
Wir haben das schon 

ziemlich gut falsch gemacht.
!
Es ist also nicht erforderlich,
dass Ihr das auch macht.
!
Wir haben die Fehler alle schon gemacht. Ihr braucht jetzt nicht auch noch.
Ein Bild von damals, als man noch nicht so viele Pixel hatte.. Kennt das noch jemand von Euch? Ok, doch ein paar alte Leute hier. Welcher Jahrgang?
http://home.mcom.com/people/jwz/
Es gab mal eine Zeit, da hat sich das Icon des Browser beim Ansurfen der URL unten auf den drehenden Kompass geändert. Das wurde von einer Person
extra eingebaut, damit seine Homepages etwas besonderes hatte.
Das ist sein Cubicle zu der Zeit gewesen. Konkret handelt es sich um Jamie Zawinski, der damals bei Netscape Communications arbeitete. Von ihm
kommen weiterhin so Tools wie XEmacs - noch Emacs-Nutzer anwesend? XScreensaver, die DaliClock und ähnliches. Er kennt sich also mit Software aus.
CADT
Aber zurück zum Thema. Und er hat folgendes Entwicklungsmodell gefunden. CADT. Kann sich jemand vorstellen, was das heisst?
Cascade of Attention-
Deficit Teenagers
„Poah, die Software ist
so eine Grütze, da mache
ich lieber einen Rewrite.“
Und auf den Rewriteversuch
folgt der Rewriteversuch.
Das ist die Kaskade von Aufmerksamkeits-Defizit-Syndrom-Teenagern. 
!
Cascade of Attention-
Deficit Teenagers
„That's what happens when there is no incentive
for people to do the parts of programming that
aren't fun. Fixing bugs isn't fun; going through the
bug list isn't fun; but rewriting everything from
scratch is fun ...“
Jamie Zawinski
Er nennt das so: 
Das ist das was passiert wenn es keinen Incentive gibt die Teile vom Programmieren zu machen die nicht Spass machen. Bugfixes machen keinen Spass,
die Bugliste durchzugehen macht keinen Spass, aber alles noch einmal neu Programmieren: das macht Spass.
Cascade of Attention-
Deficit Teenagers
?„That's what happens when there is no incentive
for people to do the parts of programming that
aren't fun. Fixing bugs isn't fun; going through the
bug list isn't fun; but rewriting everything from
scratch is fun ...“
Wer von Euch ist der Meinung dass das stimmt mit dem Spaß? 
Genau, ich auch.
Das ist er, der Netscape Browser, an dem Jamie Zawinski mitgearbeitet hat. Die richtig alten Leute hier, also wie ich, haben den noch benutzt. Und warum
haben wir ihn benutzt?
1995
80% Market Share
Jeder hat den mal benutzt.- 1995 hatten sie einen Markanteil von 80%. In diesem Jahr kam auch die erste Version vom Internet Explorer von Microsoft
heraus. Microsoft hatte die Rechte am Mosaic-Browser gekauft und ihn schlicht für Windows kompiliert. Veröffentlich wurde er mit Microsoft Plus für
Windows 95.
1998
52% Market Share
Während der erste Browser von Microsoft noch nichts taugte, wurden die folgende besser. Schliesslich wurde er mit dem Betriebssystem gebundelt, so dass
der Markanteil stiegt. Nichtsdestotrotz hatte Netscape immer noch einen Markanteil von 52%.
1998
Let‘s rewrite the
Browser from Scratch.
Im gleichen Jahr entschloss sich Netscape, den Browser komplett neu zu schreiben. Der aktuelle Browser, Netscape 4, wurde eingefroren.
2001
10% Market Share
Aber der Code
ist jetzt super!
2001, drei Jahre später, waren sie endlich fertig. Mit sehr viel Verspätung. Der Marktanteil lag bei nur noch 10%.
1998 war der Netscape Navigator 4 noch der Standard. Dann ging es in den Rewrite, und es ga lange Zeit keine neuen Features. Auf der Netscape-Seite.
Microsoft wiederum konnte mit den Upgrades bishin zum IE6 auf die Code-Basis vom Mosaic zugreifen und kontinuierlich neue Features liefern.
Microsoft: Check
Klarer Sieg für Microsoft - die haben keinen Rewrite gemacht, sondern einfach auf der Codebase vom ersten Browser überhaupt - dem NCSA Mosaic -
weitergearbeitet.
Noch ein Microsoft-Konkurrent. Borland war mal der Standard bei Entwicklungstools für die Microsoft-Plattformen DOS und Windows ...
Borland hatte zu Dos-Zeiten ein absolut massgebliches Produkt für Datenbanken. 
Aber dann kam Windows, und sie wollte ein neues Produkt haben - und haben tatsächlich ein neues Produkt gemacht, mit Hilfe eines Firmenzukaufs von
Arago. 
Die neue Version war aber nicht kompatibel zur alten - und Microsoft übernahm mit Access den Markt. Weil wenn ich eh migrieren muss, dann kann ich es
auch zu einer anderen Lösung.
Microsoft: Check
Klarer Sieg für Microsoft - die haben keinen Rewrite gemacht,
Noch ein Produkt von den Herren. Auch bei Quattro pro wurde die Software komplett neu geschrieben. Hier war man zwar weitgehend kompatibel, hatte
aber viele Features nicht mehr. Seitdem nutzen wir alle Excel.
Microsoft: Check
Klarer Sieg für Microsoft - die haben keinen Rewrite gemacht,
Microsoft selbst wiederum entschloss sich 1991 zu einem kompletten Rewrite von Word for Windows, mit dem internen Namen „Pyramid“.
?Hat jemand eine Idee, warum Word trotzdem noch Marktführer ist? 
Was haben die gemacht, um den Rewrite zu überleben? 
Genau, weil sie das Projekt nach einer Weile gestoppt haben. Und lieber auf dem bestehenden Code weiterentwickelten.
Microsoft: Check
Klarer Sieg für Microsoft - die haben keinen Rewrite gemacht,
Standish Group:
!
nur 41%der agilen
Projekte sind in
Time & Budget
Jetzt kann man natürlich sagen, das ist anecdotal Evidence, und Borland ist nicht umsonst nicht mehr da, und Microsoft ... ja, halt Microsoft. 
Die Standish Group kennt sich neben QSM mit sowas immer am besten aus. Und sie weiss: nur 41% aller agilen Projekte sind in Time & Budget. Das klingt
zwar fies, aber ist ok.
Standish Group:
!
nur 14%aller
konventionellen
Projekte sind in
Time & Budget
Immerhin, bei konventioneller, also wasserfalliger oder Rational-Unified-Process oder ähnlicher Entwicklung sieht es noch schlechter aus.
Standish Group:
!
nur 4%aller Rewrites
sind in
Time & Budget
Und kommen wir zu den Rewrites. Nur 4% aller Rewrites sind in Time & Budget. Und nach Hofstadters Law gilt: auch wenn ich das berücksichtige und mehr
Buffer einbaue. Und fast die Hälfte aller Rewrites schlägt komplett fehl und wird eingestellt.
WTF?
Gerade da, wo wir die
Software schon kennen,
scheitern wir?
Das ist schon beeindruckend - genau da, wo wir die Software eigentlich schon haben und sie schon live ist scheitern wir am häufigsten?
"Legacy code" often
differs from its suggested
alternative by actually
working and scaling.
Bjarne Stroustrup
Bjarne Stroustrup, der Erfinder von C++, hat das schön formuliert: 
Legacy Code unterscheidet sich von der empfohlenen Alternative dadurch, dass er wirklich funktioniert und skaliert.
Also doch lieber kein




Rewrite?Hmm, wenn man sich die ganzen Zahlen ansieht - also lieber doch kein Rewrite?
Hmm, warum wollten wir noch mal einen
Rewrite?
Aber zurück zu uns - warum wollen wir noch mal einen Rewrite machen? Von denen, die sich vorhin gemeldet haben - was ist der Grund? Weil sich jemand
aus dem Business beschwert, im Regelfall. Oder aus dem Development.
•neue Features dauern zu lange
•es gibt viele Bugs
•die Software wird nicht stabil
•die Architektur skaliert nicht (Cloud)
•Einarbeitung dauert zu lange
•Rahmenbedingungen haben sich geändert
Darum wollten wir noch mal einen
Rewrite.
Der Haupttreiber ist meistens die Verlangsamung der Entwicklung und die fehlende Verlässlichkeit. Es dauert zu lange bis Features kommen, und da Team
wird durch Bugfixes blockiert.
Was macht der Code da?
Und in Wahrheit haben wir Developer einfach keinen Bock mehr. Und würden jede Begründung dafür nehmen, Hauptsache, wir müssen nicht weiter mit
dem Code arbeiten. Was macht der Code da überhaupt?
Code is easier to write than to read.
Und das gemeine dabei ist: Code ist ohnehin schneller zu schreiben als zu lesen. Und gerade alter Code ist schlecht zu lesen, sprich: da braucht es schnell
deutlich länger, den Code zu lesen als neu zu schreiben.
Änderung nötig Bekannt Prüfung erforderlich
Warum gefällt uns eine neue Software besser, die wir selbst geschrieben haben? Weil wir die Teile schon kennen. Wenn ich zB Komponente 3 ändern will,
weiss ich schon, dass ich Komponente 1, 5 und 4 aufrufen muss und Komponente 2 unabhängig ist. Mein Aufwand ist also auf drei Aufrufe limitiert, und
die Prüfungen wie und wo das geschieht sind schnell, weil ich die Komponenten schon kenne.
Änderung nötig Bekannt Prüfung erforderlich
Bei einer Legacy Software sieht das deutlich unangenehmer aus - ich kenne bislang nur Komponente 4, und ich weiss nicht, wo sich Änderungen von
Komponente 3 sonst noch auswirken können. Entweder ich arbeite jetzt im Blindflug - und probiere es einfach aus - oder ich prüfe wirklich alle möglichen
vernetzten Komponenten. Der Aufwand hier ist deutlich höher, denn jetzt muss ich mich mit allen Komponenten bekannt machen.
Unser Gehirn will auch mitspielen:
Illusory Superiority
Planning Fallacy
Optimism Bias
Unser Gehirn spielt auch mit: 80% der Leute glauben, dass sie über dem Durchschnitt liegen. Es will mir also weissmachen, ich wäre etwas fähiger als der
ursprüngliche Autor.
Daneben gibt es die Planning Fallacy - ich glaube, dass ich deutlich schneller bin als meine Erfahrung es eigentlich zulassen würde. Und den Optimism
Bias, ich glaube, Risiken und Probleme werden mich eher nicht treffen als andere.
<?php!
...!
auth_check();!
error_log(“ich bin hier“);!
...!
return $user_data;!
...!
auskommentiert
Aber wie sieht das konkret aus? Bei einer unserer Legacy-Lösungen, konkret PHProjekt, hatten wir zum Beispiel in der SOAP-API diesen Code. Ein Kollege
sollte da einen Bug fixen, und irgendwie kam er nie in die error_log-Zeile, dabei sollten doch die Termine des Nutzers zurückgegeben werden. Also hat er
die Zeile schlicht auskommentiert. 
Und ab diesem Moment konnte man über SOAP alle Daten von allen Nutzern ohne jeglichen Authentifizierung abfragen. Und wieder ging eine Security-
Issue über die Ticker.
First Order Ignorance:
!
Ich weiß, dass ich etwas nicht weiß.
Technisch ist das First Order Ignorance. Ich weiss, dass es das gibt, ich weiss bloss nicht, was es macht. Mein Kollege hätte einfach in den Code
reinschauen müssen, und schon hätte er gewusst, was dort passiert. Denn diese Stelle war ihm bekannt.
johann$ find . -name "*.php" -exec cat {} ; |wc -l
49129
E_COGNITIVE_LOAD
PHProjekt 4 ist eine echt kleine Software. Weniger als 50.000 Zeilen Code in der gesamten Lösung. Trotzdem ist das echt viel zu lesen. Und deshalb lese
ich das nicht. Und mache auch kein dickes UML mit dem ich die Wände plakatiere.
Second Order Ignorance:
!
Ich weiß nicht, was ich nicht weiß.
Aber ich weiß wie ich es herausfinde.
Das ist Second Order Ignorance, die unknown Unknowns. Ich weiss gar nicht, welche Dinge ich alles nicht weiss in der Software. Da steckt so viel Kram
drin, den ich nicht kenne, und wo ich auch keine Ahnung habe, wofür er gebraucht wird. Ich wüsste zwar, wie ich das herausfinde, aber ich investiere die
Zeit nicht sondern fange lieber gleich an, mit was auch immer.
<?php!
...!
// important Bugfix, jph 2.5.2004!
...!
// on customer request, 5.5.2005 !
...!
Und es gibt noch die Klasse von Verhalten, bei dem wir nicht wissen, was wir nicht wissen, aber auch keine Idee haben, wie wir das herausfinden. Der
Bugfix von vor 7 Jahren?! Warum gab es den, wer wollte das?
Third Order Ignorance:
!
Ich weiß nicht, was ich nicht weiß,
und ich weiß auch nicht
wie ich es herausfinde.
Das ist Third Order Ignorance. Ich weiss nicht, was ich nicht weiss, und ich habe auch keinen Weg auf dem ich das erfahre.
Jede Änderung im alten Legacy-Code

brauchte 2 mal Zeit:
!
1. um herauszufinden, dass es geändert
werden muss
!
2. um herauszufinden, wie es geändert
werden muss
!
!
Und ich soll das jetzt spontan verstehen?
Und das gemeine ist: bei allen diesen Unklarheiten muss ich bedenken, dass sie schon zwei mal Zeit zum Verstehen gebraucht haben. Und jemand darüber
nachgedacht hat. Und jetzt soll ich das, ohne den damaligen Kontext, spontan verstehen?
Regardless of what we discover, we
understand and truly believe that everyone
did the best job they could, given what they
knew at the time, their skills and abilities,
the resources available, and the situation at
hand.
Kennt jemand diese Formulierung? Das ist die Prime Directive der Scrum-Retrospektiven. Und die gilt natürlich auch für alte Software. Jetzt kann man
sagen: Ja, die hatten halt nicht die Zeit, die wir jetzt haben. Aber auch sie dachten damals, dass sie die Zeit haben würden, wie wir heute.
Schlechten Code wegwerfen und 

neu anfangen, diesmal sauber!
Uh, das ist aber viel Arbeit.
Poah, das werden wir nicht schaffen.
Lieber auf Funktionalität fokussieren.
Hmpf, Deadline schon wieder verpasst,
jetzt sind Überstunden angesagt.
Ok, Qualität ist fies, aber immerhin sind
wir endlich released. Wenn auch mit
echt schlechtem Code.
Am Ende hat man dann den Rewrite Cycle of Death ... :-) - mit wieder schlechtem Code.
Während des Rewrites
wenig bis keine neuen Features.
!
!
Der Rewrite dauert deutlich länger.
!
!
Die Konkurrenz überholt.
Und nicht nur das passiert. Weil ich im Rewrite bin, sind die Leute, die sich mit der Software auskennen, für die neue Software gebunden, und in der
bestehenden Applikation bewegt sich nur wenig. Zeitgleich dauert der Rewrite deutlich länger als erwartet. In Folge: die Konkurrenz überholt.
!
Die neuen Kollegen ohne Knowhow:
!
Wartung der Live-Applikation
oder lieber in den strategisch
wichtigen Rewrite?
!
Doppelte Kosten pro Feature
Lösung: 2 Teams?
Die naheliegenste Lösung ist das doppelte Team. Das hat aber auch seine Probleme - denn ich brauche für die Weiterentwicklung das Knowhow der
bestehenden Software - denn es ist komplex und tief - auf der anderen Seite will ich aber für die neue Software auch das Domainwissen aus der alten
nutzen... eigentlich brauche ich doppelt so viele alte Leute. 

Und für die Rewrite-Phase selbst habe ich das Problem der doppelten Kosten - denn jedes neue Feature muss in der alten Software wie auch in der neuen
bereitstehen.
! ?Die Frage ist also: wie komme ich aus der Nummer raus? Wie kann ich die Software so neu machen, dass ich das überlebe?
•Das Wissen in der Software 

zu eigenem Wissen machen
•kontinuierlicher Feature-Flow
•wenig doppelte Entwicklung
•am Ende eine wartbare Codebase
•in Zukunft preiswerte, schnelle Features
Aufgabenstellung
Das ist meine Aufgabenstellung:
Kontinuierliche
Modernisierung 

in 7 Schritten
•alles ist immer produktiv
•kleine Inkremente
•kontinuierlicher Featurestream
Und so komme ich dahin - indem ich kontinuierlich modernisiere, rewrite oder refaktoriere.
1.
Absichern der Applikation
CI Infrastruktur einführen
!
CD Infrastruktur einführen
!
Eine CI-Infrastruktur hat heute praktisch jeder, aber nicht jeder für die alten Projekte.
Etablieren einer CI- und CD-Infrastruktur Warum mache ich das? Weil ich kontinuierlich stabil bleiben will. Wer hat bereits eine CI-Infrastruktur?
Wer hat bereits eine CD-Infrastruktur?
CD ist notwendig für kleine Inkremente. Wenn ich 2 Wochen zwischen den Releases habe können zu viele Dinge zerbrechlich werden.
!
1.
Absichern der Applikation
Core-Workflows über
Akzeptanztests sichern
!
Viele sagen an dieser Stelle, gerade bei Legacy-Software: Hej, ich brauche schon 2 Wochen für die Testphase, um überhaupt sicher zu sein, dass meine Applikation releasefähig ist. Normalerweise würde man dann sagen, dass eine Applikation von beiden Seiten -
sprich über Unit-Tests in der Applikation und Acceptance / Funktions/ Integrationstests von aussen abgesichert sein sollte. Im Fall von Altapplikationen ist das meist aber nicht möglich. Also sichere ich alle Kernprozesse mit Akzeptanztests ab - zum Beispiel über BDD-
Tests, gerne auch JavaScript-getrieben über Jasmine, JSpec oder CucumberJS.
!
1.
Absichern der Applikation
!
Monitoring
!
Selenium-Cloud-Testing
!
Trick 17:

Produktionsnahe Entwicklung
Wenn ich Glück habe kann ich die Akzeptanztests auch als Roboter für den Tests des Produktionsenvironments nutzen. Sonst kann ich selbst, mit einem der vielen Online-Dienste wie Pingdom oder einer der vielen Selenium-Cloud-Dienste die Applikation absichern.
Wenn ich einen Rollout habe, der meine Applikation instabil zurücklässt weiss ich sofort Bescheid und kann ihn zurückrollen.
Es gibt noch einen weiteren Trick, mit dem man die Produktion stabil bekommt - man benutzt schlicht ein möglichst ähnliches Environment in Development oder, wenn es dort nicht möglich ist, in Integration oder Testing. Um so früher ich die Fehler entdecke um so
weniger schaffen es in Produktion.
2.
Größter gemeinsamer Nenner
Ist ein gemeinsame Codebasis möglich?
!
•bei Bedarf Alt-Applikation anheben
Kann man die Applikation auf eine gemeinsame Codebasis heben? Wenn ja, Glück gehabt. Wenn nein …
2.
Proxy-Lösung
Die neue Applikation ist ein Proxy vor der
alten.
!
Nach und nach werden Teile aus dem
Proxy in die neue Applikation gezogen
Wenn es nicht möglich ist, muss ich andere Wege gehen - und zum Beispiel die neue Applikation als Proxy zur alten Applikation betreiben. Oft muss ich
mit regulären Ausdrücken Teile der Seite herausholen.
3.
Gemeinsames Frontend
Fallthrough-Routing:
!
Alles, was die neue Applikation noch nicht
selbst macht fällt zur alten Applikation
durch.
Egal, ob ich die Applikationen direkt integrieren kann oder einen Proxy implementiere - ich habe in der neuen Applikation einen Falltrough-Router, der alle
Themen, die die neue Applikation noch nicht selbst behandeln kann, einfach zur alten Applikation durchfallen lässt.
4.
Gemeinsame Infrastruktur:
Sessions
Session-Bagging/Container:
!
Die neue Sessions finden in einem
Namespace innerhalb der alten statt
!
Damit ich den Zustand der Applikation - wie zum Beispiel die Authentifizierung - gemeinsame verwalten kann, brauche ich auch einen gemeinsamen
Zustand. Bei Symfony2 kann man das mit den Session-Bags lösen, bei Zend Framework mit den Session Containern. Beim Proxy braucht man ein Interface,
das diese Daten über eine Schnittstelle steuern kann. Laravel bietet keine Namespaced Sessions, hier muss man selbst über eine Session-Facade und einen
Hashkey Hand anlegen.
4.
Gemeinsame Infrastruktur:
Datenzugriff
Gemeinsame Datenbank wenn möglich
!
Alternative: Migration mit
Synchronisation für die Übergangszeit
!
Wenn möglich greife ich gemeinsam auf die gleiche Datenbasis zurück. Ich war bei ein paar grossen Modernisierungsprojekten mit dabei, bei denen die
Datenbasis komplett erhalten blieb - schon weil die Datenmenge so gross war, dass eine Verdopplung der Daten zu teuer gewesen wäre.
5.
Featureflags
Features können per Flag aktiviert/
deaktiviert werden
!
Switch zwischen alter/neuer Variante
Um die Lösung tatsächlich immer und für alle Stabil zu halten migriere ich hinter Featureflags. Sprich: es ist immer möglich, wahlweise den alten oder den
neuen Code zu nutzen.
6.
Workflow
Test
Abstraction
Featureflag
Reengineering
Produktion
Aufräumen
pro Feature
Wenn ich die Infrastruktur soweit fertig habe, kann ich in die konkrete Entwicklung gehen. Ich beginne jeweils mit einer Testabsicherung des zu
migrierenden Features. Sobald die Da ist, abstrahiere ich das Feature so, dass es für die alte und die neue Variante genutzt werden kann. Dann führe ich
einen Umschalter ein, der wahlweise den alten oder den neuen Code nutzt, so dass die Kollegen immer Zugriff auf eine stabile Variante haben. Danach
reengineere ich den Code und stelle ihn in Produktion, sobald er fertig ist. Wenn die neue Variante damit funktioniert lösche ich den alten Zweig aus den
Featureflags. Was steht konkret hinter den Schritten?
6.1
Test
Ich etabliere Akzeptanz-Tests (zB
Jasmine, Selenium, Behat) für das zu
migrierende Feature
Akzeptanz-Tests, Service oder Unit-Test, je nach Möglichkeit
Strategie: Branch by Abstraction
6.2Wenn ich beide Applikationen gemeinsam verwenden kann, bietet sich Martin Fowlers Branch by Abstraction als Strategie an. Ich führe eine Abstraktion ein
- zB eine Fassade - die ich über die alte Logik stülpe. Wenn ich hier stabil bin entwickle ich die neue Logik, die die gleiche Fassade bietet.
Strategie: Add Layer
6.3
Ich führe einen Soap/REST-Layer ein.
!
Beide Seiten nutzen das Soap/REST-Layer
für den Zugriff auf die Funktionalität.
Das ist eine der am weitesten verbreiteten Modernisierungs-Strategien - Add Layer — die Modernisierung zugunsten von Services. Bei uns ist das schon
lange nicht mehr Soap, sondern im Regelfall REST. In diesem Fall führe ich einen REST-Layer ein.
Strategie: Dependecy Injection & Container
6.4
Ich führe eine DI-basierte Struktur ein
!
Beide Seiten nutzen den DI-Container für
den Zugriff auf die Funktionalität.
Der Service muss auch nicht per se nach draussen zeigen - er kann auch von innen zugänglich gemacht werden. Wenn meine Modernisierung in Richtung
DI-Framework geht, dann kann ich genau an der Schnittstelle Locator/Container auch modernisieren.
Reengineering
6.5
Ich schreibe die neue Version
hinter der Abstraction und
hinter dem Featureflag. 

Alt und neu existieren parallel.
Produktion
6.6
Das neue Feature geht live und wird per
Featureflag auch in der Produktion
aktiviert.
Branch By Abstraction oder Rest-Service
Aufräumen
6.7
Wenn nach hinreichender Zeit keine
Probleme (mehr) auftreten,
wird sowohl der alte Code als auch das
Featureflag entfernt.
Alte Routen löschen, ebenso die kompletten Schalter hinter den Feature Flags.
7.
Bei Bedarf: Datenmigration
Wenn sich Schema oder
Datenbanksystem ändern:
!
Synchronisierung für die
Migrationsphase
!
Double Write
Single Read
Manche Modernisierungen lassen sich ohne Änderung der Daten durchführen - viele aber nicht. In diesem Fall braucht man einen Plan. Handelt es sich um
die gleiche Datenbank, kann man mit Triggern arbeiten um die Daten synchron zu halten. Handelt es sich um eine andere Datenbank wird es schwieriger.
Wenn ich zum Beispiel nach MongoDB migriere kann ich nicht jede Tabelle einzeln umziehen. Dieses Problem löst man mit einem Double Write und einem
Single Read - es wird also zwei mal geschrieben - in die neue Datenbank wie in die alte - aber nur einmal gelesen, in den neuen Teilen aus der neuen
Datenbank und in den alten Teilen aus der alten Datenbank.
8.
Organisation
Modernization Map (Klassen)
!
Modernization Burn-Down
Ich kenne einige Applikationen mit mehrfach abgebrochenen Modernisierungsversuchen. Das beste was ich bislang gesehen habe war eine
Ursprungssoftware mit 6 unterschiedlichen Modernisierungsversuchen, die alle nebeneinander existierten - inklusive redundanter Funktionalität, die je
nach Aufrufpfad zum Teil noch mehrfach in Produktion war.
Unsere Wins & Fails
PHProjekt: OpenSource-Groupware

!
ca 150.000 Zeilen Code
!
Rewrite von Big Ball of Mud 

nach Zend Framework & Qualität
!
Nach 4 Jahren: guter Code, 

weniger Features, keine Nutzer
Unsere Erfahrungen. Wir haben eine alte, bekannte OpenSource-Software in der Firma, die mal eine der am weitesten verbreiteten Groupware-Lösungen
war. Bis wir sie rewriten wollten.
MediaCloud

!
ca 600.000 Zeilen Code
!
Rewrite nach SOA, sehr nah am Original
!
Time & Budget nicht gehalten
!
Problematische One-Time-Datenmigration
Unsere Wins & Fails
Daneben haben wir eine eher grosse Media-Cloud-Lösung gebaut, die aus mehr oder weniger politischen Gründen modernisiert werden musste. Dort
wurde ein Rewrite in Richtung SOA- Geschmacksrichtung REST - und NoSQL gemacht.
Grosses Dokumentationsystem
!
ca 1.000.000 Zeilen Legacy-Code in einem
proprietären Framework
!
2012 nach DI-Framework modernisiert
mittels Proxy-Variante
!
kontinuierliche Datenmigration
Unsere Wins & Fails
Nächstes Fallbeispiel, eine grosse Dokumentenlösung, mit der spezialisierte, internationalisierte Wartungsmaterialien erstellt und gepflegt werden.
Infrastruktur kostet 

weniger Zeit als erwartet
Learnings
Wenn man eine langsame Modernisierung macht: die Infrastruktur kostet nicht so viel Zeit - und es macht sogar Spass. 
Und ein guter Nebeneffekt: die Einführung von Tests verzinst sich schnell, es wird frühzeitig spürbar, dass weniger Bugs auftreten.
Raus aus der
Black Box!
Learnings
Erste und wichtigste Lehre: Raus aus der Black Box. Immer möglichst viel echte Nutzer kontinuierlich auf der Software.
Learnings
Die ersten Features kosten
deutlich mehr Zeit als erwartet
Am Anfang dauert es sehr lange, weil jedes Feature seine Grundlagen mitzieht. Hier passieren grössere Reengineerings, die in Abhängigkeit voneinander
stattfinden.
Man wird mit der Zeit
deutlich schneller
Learnings
Am Anfang migriert man mit jedem Feature einen grossen Teil der Infrastruktur, und diese Phase ist wirklich zäh. Aber zum Ende hin, wenn viele
abhängige Komponenten häufig schon migriert sind, beschleunigt sich die Migration sehr.
Never
do a Rewrite!
Ok,
almost never.
Wann mache ich trotzdem einen Rewrite?
Die Software wird in Wahrheit 

gar nicht genutzt
!
Es wird nur ein kleiner Teil 

der Software genutzt
!
Die Software ist klein.
!
Es ist gar kein Rewrite.
Modernisierung FTW!
Kontinuierlich, immer in Produktion
!
Es geht auch mit inkompatiblen Stacks
!
Programmieren um wegzuwerfen spart
Zeit und Geld.
Qualität ist die
Übereinstimmung von
Produktleistung und
Kundenwunsch.
(Nicht Developervorstellung)
Reminder
Lüönd, 2004 - Das ist das, was bei einem Rewrite am Ende herauskommen sollte. Qualität ist
nicht wenn Developer glücklich sind.
!
Danke!
Präsentation/Volltext: http://slideshare.net/johannhartmann

Weitere ähnliche Inhalte

Was ist angesagt?

Software-Entwicklung Im Team
Software-Entwicklung Im TeamSoftware-Entwicklung Im Team
Software-Entwicklung Im TeamStephan Schmidt
 
GPM Vortrag: Modernes Management von Softwareprojekten
GPM Vortrag: Modernes Management von SoftwareprojektenGPM Vortrag: Modernes Management von Softwareprojekten
GPM Vortrag: Modernes Management von SoftwareprojektenFrank Düsterbeck
 
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012Martin Seibert
 
WJAX 2014: Na klar muss alles "gestern" fertig sein
WJAX 2014: Na klar muss alles "gestern" fertig seinWJAX 2014: Na klar muss alles "gestern" fertig sein
WJAX 2014: Na klar muss alles "gestern" fertig seinMatthias Bohlen
 
Java script security for java developers
Java script security for java developersJava script security for java developers
Java script security for java developersJohann-Peter Hartmann
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererTobias Schlüter
 
About Dogs and Cats - über DevOps in großen Konzernen
About Dogs and Cats - über DevOps in großen KonzernenAbout Dogs and Cats - über DevOps in großen Konzernen
About Dogs and Cats - über DevOps in großen KonzernenStefan Bauer
 
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software-Entwicklung in Teams wissen solltenStephan Schmidt
 
23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software Entwicklung in Teams wissen solltenStephan Schmidt
 

Was ist angesagt? (9)

Software-Entwicklung Im Team
Software-Entwicklung Im TeamSoftware-Entwicklung Im Team
Software-Entwicklung Im Team
 
GPM Vortrag: Modernes Management von Softwareprojekten
GPM Vortrag: Modernes Management von SoftwareprojektenGPM Vortrag: Modernes Management von Softwareprojekten
GPM Vortrag: Modernes Management von Softwareprojekten
 
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012
 
WJAX 2014: Na klar muss alles "gestern" fertig sein
WJAX 2014: Na klar muss alles "gestern" fertig seinWJAX 2014: Na klar muss alles "gestern" fertig sein
WJAX 2014: Na klar muss alles "gestern" fertig sein
 
Java script security for java developers
Java script security for java developersJava script security for java developers
Java script security for java developers
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für Programmierer
 
About Dogs and Cats - über DevOps in großen Konzernen
About Dogs and Cats - über DevOps in großen KonzernenAbout Dogs and Cats - über DevOps in großen Konzernen
About Dogs and Cats - über DevOps in großen Konzernen
 
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten
 
23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
 

Andere mochten auch

Einfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesEinfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesJohann-Peter Hartmann
 
Lügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-VerträgeLügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-VerträgeJohann-Peter Hartmann
 
Von Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und SystemadministratorenVon Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und SystemadministratorenJohann-Peter Hartmann
 
Usability intern oder extern testen (WUD 2010)
Usability intern oder extern testen (WUD 2010)Usability intern oder extern testen (WUD 2010)
Usability intern oder extern testen (WUD 2010)Sandra Griffel
 
Atletismo divertido
Atletismo divertidoAtletismo divertido
Atletismo divertidoljpe
 
Das Netzwerk der Seltenen Erden am Beispiel Neodym
Das Netzwerk der Seltenen Erden am Beispiel NeodymDas Netzwerk der Seltenen Erden am Beispiel Neodym
Das Netzwerk der Seltenen Erden am Beispiel NeodymStefan Kasberger
 

Andere mochten auch (17)

Web 2.0 revisited
Web 2.0 revisitedWeb 2.0 revisited
Web 2.0 revisited
 
Leadership in der IT
Leadership in der ITLeadership in der IT
Leadership in der IT
 
Einfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesEinfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektes
 
Agile versus Management WJAX 2014
Agile versus Management WJAX 2014Agile versus Management WJAX 2014
Agile versus Management WJAX 2014
 
Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!
 
Lügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-VerträgeLügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-Verträge
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
 
Presentation zen mayflower
Presentation zen mayflowerPresentation zen mayflower
Presentation zen mayflower
 
Von Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und SystemadministratorenVon Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und Systemadministratoren
 
Management brainfucks
Management brainfucksManagement brainfucks
Management brainfucks
 
pi920.pdf
pi920.pdfpi920.pdf
pi920.pdf
 
Usability intern oder extern testen (WUD 2010)
Usability intern oder extern testen (WUD 2010)Usability intern oder extern testen (WUD 2010)
Usability intern oder extern testen (WUD 2010)
 
Exponatebeschreibung Sonderausstellung.pdf
Exponatebeschreibung Sonderausstellung.pdfExponatebeschreibung Sonderausstellung.pdf
Exponatebeschreibung Sonderausstellung.pdf
 
Atletismo divertido
Atletismo divertidoAtletismo divertido
Atletismo divertido
 
Pressemeldung Marketing-Seminar.pdf
Pressemeldung Marketing-Seminar.pdfPressemeldung Marketing-Seminar.pdf
Pressemeldung Marketing-Seminar.pdf
 
Das Netzwerk der Seltenen Erden am Beispiel Neodym
Das Netzwerk der Seltenen Erden am Beispiel NeodymDas Netzwerk der Seltenen Erden am Beispiel Neodym
Das Netzwerk der Seltenen Erden am Beispiel Neodym
 
Pressemeldung_Generator Hostels.pdf
Pressemeldung_Generator Hostels.pdfPressemeldung_Generator Hostels.pdf
Pressemeldung_Generator Hostels.pdf
 

Ähnlich wie Erfolgreiche rewrites

JavaScript Days 2015: Security
JavaScript Days 2015: SecurityJavaScript Days 2015: Security
JavaScript Days 2015: SecurityMayflower GmbH
 
Microsoft und die Open Source Community - Leaving the death star behind
Microsoft und die Open Source Community - Leaving the death star behindMicrosoft und die Open Source Community - Leaving the death star behind
Microsoft und die Open Source Community - Leaving the death star behindChristian Heilmann
 
JavaScript und Security - JavaScript Days 2013 Berlin
JavaScript und Security - JavaScript Days 2013 BerlinJavaScript und Security - JavaScript Days 2013 Berlin
JavaScript und Security - JavaScript Days 2013 BerlinJohann-Peter Hartmann
 
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten.
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten.23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten.
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten.Stephan Schmidt
 
DNUG ak-anwendungsentwicklung.18042011
DNUG ak-anwendungsentwicklung.18042011DNUG ak-anwendungsentwicklung.18042011
DNUG ak-anwendungsentwicklung.18042011Ulrich Krause
 
SEODAY2016 - 10 SEO Coder Hooks
SEODAY2016 - 10 SEO Coder HooksSEODAY2016 - 10 SEO Coder Hooks
SEODAY2016 - 10 SEO Coder HooksConstantin
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018Johann-Peter Hartmann
 
Browserstrategien und Progressive Enhancement
Browserstrategien und Progressive EnhancementBrowserstrategien und Progressive Enhancement
Browserstrategien und Progressive EnhancementAperto Nachname
 
Mojo, Twitter und Konsorten
Mojo, Twitter und KonsortenMojo, Twitter und Konsorten
Mojo, Twitter und KonsortenPhilipp Naderer
 
How to become a better software engineer by doing nothing
How to become a better software engineer by doing nothingHow to become a better software engineer by doing nothing
How to become a better software engineer by doing nothingPeter Mösenthin
 
C/ C++ for Notes & Domino Developers
C/ C++ for Notes & Domino DevelopersC/ C++ for Notes & Domino Developers
C/ C++ for Notes & Domino DevelopersUlrich Krause
 
Agiles Lernen und Software Entwicklung das OSGi Code Camp 2010
Agiles Lernen und Software Entwicklung das OSGi Code Camp 2010Agiles Lernen und Software Entwicklung das OSGi Code Camp 2010
Agiles Lernen und Software Entwicklung das OSGi Code Camp 2010Christian Baranowski
 
JFS 2011 - Top 10 der Tools & Methoden - Baumgartner, Oehmichen
JFS 2011 - Top 10 der Tools & Methoden - Baumgartner, OehmichenJFS 2011 - Top 10 der Tools & Methoden - Baumgartner, Oehmichen
JFS 2011 - Top 10 der Tools & Methoden - Baumgartner, OehmichenOdilo Oehmichen
 
JFS 2011 - Top 10 Tools & Methoden - Baumgartner, Oehmichen
JFS 2011 - Top 10 Tools & Methoden - Baumgartner, OehmichenJFS 2011 - Top 10 Tools & Methoden - Baumgartner, Oehmichen
JFS 2011 - Top 10 Tools & Methoden - Baumgartner, OehmichenPatrick Baumgartner
 

Ähnlich wie Erfolgreiche rewrites (20)

Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
 
JavaScript Days 2015: Security
JavaScript Days 2015: SecurityJavaScript Days 2015: Security
JavaScript Days 2015: Security
 
Microsoft und die Open Source Community - Leaving the death star behind
Microsoft und die Open Source Community - Leaving the death star behindMicrosoft und die Open Source Community - Leaving the death star behind
Microsoft und die Open Source Community - Leaving the death star behind
 
JavaScript und Security - JavaScript Days 2013 Berlin
JavaScript und Security - JavaScript Days 2013 BerlinJavaScript und Security - JavaScript Days 2013 Berlin
JavaScript und Security - JavaScript Days 2013 Berlin
 
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten.
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten.23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten.
23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten.
 
WWruhr2018
WWruhr2018WWruhr2018
WWruhr2018
 
DNUG ak-anwendungsentwicklung.18042011
DNUG ak-anwendungsentwicklung.18042011DNUG ak-anwendungsentwicklung.18042011
DNUG ak-anwendungsentwicklung.18042011
 
objectiF extrem
objectiF extremobjectiF extrem
objectiF extrem
 
SEODAY2016 - 10 SEO Coder Hooks
SEODAY2016 - 10 SEO Coder HooksSEODAY2016 - 10 SEO Coder Hooks
SEODAY2016 - 10 SEO Coder Hooks
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018
 
Browserstrategien und Progressive Enhancement
Browserstrategien und Progressive EnhancementBrowserstrategien und Progressive Enhancement
Browserstrategien und Progressive Enhancement
 
Mojo, Twitter und Konsorten
Mojo, Twitter und KonsortenMojo, Twitter und Konsorten
Mojo, Twitter und Konsorten
 
Advanced Continuous Integration
Advanced Continuous IntegrationAdvanced Continuous Integration
Advanced Continuous Integration
 
How to become a better software engineer by doing nothing
How to become a better software engineer by doing nothingHow to become a better software engineer by doing nothing
How to become a better software engineer by doing nothing
 
C/ C++ for Notes & Domino Developers
C/ C++ for Notes & Domino DevelopersC/ C++ for Notes & Domino Developers
C/ C++ for Notes & Domino Developers
 
Codeception VisualCeption
Codeception VisualCeptionCodeception VisualCeption
Codeception VisualCeption
 
Agiles Lernen und Software Entwicklung das OSGi Code Camp 2010
Agiles Lernen und Software Entwicklung das OSGi Code Camp 2010Agiles Lernen und Software Entwicklung das OSGi Code Camp 2010
Agiles Lernen und Software Entwicklung das OSGi Code Camp 2010
 
JFS 2011 - Top 10 der Tools & Methoden - Baumgartner, Oehmichen
JFS 2011 - Top 10 der Tools & Methoden - Baumgartner, OehmichenJFS 2011 - Top 10 der Tools & Methoden - Baumgartner, Oehmichen
JFS 2011 - Top 10 der Tools & Methoden - Baumgartner, Oehmichen
 
JFS 2011 - Top 10 Tools & Methoden - Baumgartner, Oehmichen
JFS 2011 - Top 10 Tools & Methoden - Baumgartner, OehmichenJFS 2011 - Top 10 Tools & Methoden - Baumgartner, Oehmichen
JFS 2011 - Top 10 Tools & Methoden - Baumgartner, Oehmichen
 
Development in der Cloud-Ära
Development in der Cloud-ÄraDevelopment in der Cloud-Ära
Development in der Cloud-Ära
 

Mehr von Johann-Peter Hartmann

Mehr von Johann-Peter Hartmann (12)

The End of my Career
The End of my CareerThe End of my Career
The End of my Career
 
DevOps beyond the Tools
DevOps beyond the ToolsDevOps beyond the Tools
DevOps beyond the Tools
 
Warum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommtWarum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommt
 
NewWork in der Praxis
NewWork in der PraxisNewWork in der Praxis
NewWork in der Praxis
 
How not to screw the operating system of your startup
How not to screw the operating system of your startupHow not to screw the operating system of your startup
How not to screw the operating system of your startup
 
Surviving Complexity
Surviving ComplexitySurviving Complexity
Surviving Complexity
 
JavaScript Security
JavaScript SecurityJavaScript Security
JavaScript Security
 
Serverside Cryptoparty
Serverside CryptopartyServerside Cryptoparty
Serverside Cryptoparty
 
Wetware Bugs and Refactoring
Wetware Bugs and RefactoringWetware Bugs and Refactoring
Wetware Bugs and Refactoring
 
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
 
Profiling for Grown-Ups
Profiling for Grown-UpsProfiling for Grown-Ups
Profiling for Grown-Ups
 
Paradigmenwechsel bei webapplikationen
Paradigmenwechsel bei webapplikationenParadigmenwechsel bei webapplikationen
Paradigmenwechsel bei webapplikationen
 

Erfolgreiche rewrites

  • 1. ! Erfolgreiche Rewrites Hallo, guten morgen Nürnberg! Ich bin Johann, und nicht ganz echter CTO.
  • 2. Erst einmal herzlichen Glückwunsch an allen anwesenden Weltmeister. Wer hat das Spiel geguckt? Wer hat mehr als 6 Stunden Schlaf bekommen? Wer hat weniger als 6 Stunden Schlaf bekommen? Wer hat weniger als 4 Stunden Schlaf bekommen? Wer hat weniger als 2 Stunden Schlaf bekommen? Respekt.
  • 3. Fußball für Developer Team oder Rockstar? Fußball ist eigentlich für uns auch interessant. Ähnlich wie Softwareerstellung ist es ein komplexes adaptives System, und deshalb gelten einige Regeln von dort auch für uns. Gucken wir doch mal - erste Frage: Team oder Rockstar, wer gewinnt am Ende?
  • 4. Fußball für Developer Kann ein Junior das Projekt rocken? Und überhaupt, wenn schon nicht die Rockstars zählen - kann ein Junior derjenige sein, der das Projekt am Ende zum Goal bringt?
  • 5. Fußball für Developer Pairing rocks! Faktisch war es nicht ein Junior, sondern zwei. Von der verdammten Bank.
  • 6. Wer von Euch macht gerade einen 
 Rewrite? ! Es gibt ja einen Grund, warum ihr hier seid. Also mal direkt gefragt - wer von Euch macht gerade einen Rewrite?
  • 7. Wer von Euch plant gerade einen 
 Rewrite? ! Wer plant einen in Zukunft? Genau die Leute möchte ich in meinem Vortrag sehen.
  • 8. Wer von Euch würde gerne einen 
 Rewrite machen? ! Und nicht zuletzt: Wer von Euch würde gerne einen Rewrite machen? Jemand mit einer Legacy-Applikation da, der keinen Rewrite möchte?
  • 9. Ich bin hier um Euch das auszureden. ! Ich bin heute hier um Euch das auszureden.
  • 10. Wir haben das schon 
 ziemlich gut falsch gemacht. ! Es ist also nicht erforderlich, dass Ihr das auch macht. ! Wir haben die Fehler alle schon gemacht. Ihr braucht jetzt nicht auch noch.
  • 11. Ein Bild von damals, als man noch nicht so viele Pixel hatte.. Kennt das noch jemand von Euch? Ok, doch ein paar alte Leute hier. Welcher Jahrgang?
  • 12. http://home.mcom.com/people/jwz/ Es gab mal eine Zeit, da hat sich das Icon des Browser beim Ansurfen der URL unten auf den drehenden Kompass geändert. Das wurde von einer Person extra eingebaut, damit seine Homepages etwas besonderes hatte.
  • 13. Das ist sein Cubicle zu der Zeit gewesen. Konkret handelt es sich um Jamie Zawinski, der damals bei Netscape Communications arbeitete. Von ihm kommen weiterhin so Tools wie XEmacs - noch Emacs-Nutzer anwesend? XScreensaver, die DaliClock und ähnliches. Er kennt sich also mit Software aus.
  • 14. CADT Aber zurück zum Thema. Und er hat folgendes Entwicklungsmodell gefunden. CADT. Kann sich jemand vorstellen, was das heisst?
  • 15. Cascade of Attention- Deficit Teenagers „Poah, die Software ist so eine Grütze, da mache ich lieber einen Rewrite.“ Und auf den Rewriteversuch folgt der Rewriteversuch. Das ist die Kaskade von Aufmerksamkeits-Defizit-Syndrom-Teenagern. !
  • 16. Cascade of Attention- Deficit Teenagers „That's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun ...“ Jamie Zawinski Er nennt das so: Das ist das was passiert wenn es keinen Incentive gibt die Teile vom Programmieren zu machen die nicht Spass machen. Bugfixes machen keinen Spass, die Bugliste durchzugehen macht keinen Spass, aber alles noch einmal neu Programmieren: das macht Spass.
  • 17. Cascade of Attention- Deficit Teenagers ?„That's what happens when there is no incentive for people to do the parts of programming that aren't fun. Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun ...“ Wer von Euch ist der Meinung dass das stimmt mit dem Spaß? Genau, ich auch.
  • 18. Das ist er, der Netscape Browser, an dem Jamie Zawinski mitgearbeitet hat. Die richtig alten Leute hier, also wie ich, haben den noch benutzt. Und warum haben wir ihn benutzt?
  • 19. 1995 80% Market Share Jeder hat den mal benutzt.- 1995 hatten sie einen Markanteil von 80%. In diesem Jahr kam auch die erste Version vom Internet Explorer von Microsoft heraus. Microsoft hatte die Rechte am Mosaic-Browser gekauft und ihn schlicht für Windows kompiliert. Veröffentlich wurde er mit Microsoft Plus für Windows 95.
  • 20. 1998 52% Market Share Während der erste Browser von Microsoft noch nichts taugte, wurden die folgende besser. Schliesslich wurde er mit dem Betriebssystem gebundelt, so dass der Markanteil stiegt. Nichtsdestotrotz hatte Netscape immer noch einen Markanteil von 52%.
  • 21. 1998 Let‘s rewrite the Browser from Scratch. Im gleichen Jahr entschloss sich Netscape, den Browser komplett neu zu schreiben. Der aktuelle Browser, Netscape 4, wurde eingefroren.
  • 22. 2001 10% Market Share Aber der Code ist jetzt super! 2001, drei Jahre später, waren sie endlich fertig. Mit sehr viel Verspätung. Der Marktanteil lag bei nur noch 10%.
  • 23. 1998 war der Netscape Navigator 4 noch der Standard. Dann ging es in den Rewrite, und es ga lange Zeit keine neuen Features. Auf der Netscape-Seite. Microsoft wiederum konnte mit den Upgrades bishin zum IE6 auf die Code-Basis vom Mosaic zugreifen und kontinuierlich neue Features liefern.
  • 24. Microsoft: Check Klarer Sieg für Microsoft - die haben keinen Rewrite gemacht, sondern einfach auf der Codebase vom ersten Browser überhaupt - dem NCSA Mosaic - weitergearbeitet.
  • 25. Noch ein Microsoft-Konkurrent. Borland war mal der Standard bei Entwicklungstools für die Microsoft-Plattformen DOS und Windows ...
  • 26. Borland hatte zu Dos-Zeiten ein absolut massgebliches Produkt für Datenbanken. Aber dann kam Windows, und sie wollte ein neues Produkt haben - und haben tatsächlich ein neues Produkt gemacht, mit Hilfe eines Firmenzukaufs von Arago. Die neue Version war aber nicht kompatibel zur alten - und Microsoft übernahm mit Access den Markt. Weil wenn ich eh migrieren muss, dann kann ich es auch zu einer anderen Lösung.
  • 27. Microsoft: Check Klarer Sieg für Microsoft - die haben keinen Rewrite gemacht,
  • 28. Noch ein Produkt von den Herren. Auch bei Quattro pro wurde die Software komplett neu geschrieben. Hier war man zwar weitgehend kompatibel, hatte aber viele Features nicht mehr. Seitdem nutzen wir alle Excel.
  • 29. Microsoft: Check Klarer Sieg für Microsoft - die haben keinen Rewrite gemacht,
  • 30. Microsoft selbst wiederum entschloss sich 1991 zu einem kompletten Rewrite von Word for Windows, mit dem internen Namen „Pyramid“.
  • 31. ?Hat jemand eine Idee, warum Word trotzdem noch Marktführer ist? Was haben die gemacht, um den Rewrite zu überleben? Genau, weil sie das Projekt nach einer Weile gestoppt haben. Und lieber auf dem bestehenden Code weiterentwickelten.
  • 32. Microsoft: Check Klarer Sieg für Microsoft - die haben keinen Rewrite gemacht,
  • 33. Standish Group: ! nur 41%der agilen Projekte sind in Time & Budget Jetzt kann man natürlich sagen, das ist anecdotal Evidence, und Borland ist nicht umsonst nicht mehr da, und Microsoft ... ja, halt Microsoft. Die Standish Group kennt sich neben QSM mit sowas immer am besten aus. Und sie weiss: nur 41% aller agilen Projekte sind in Time & Budget. Das klingt zwar fies, aber ist ok.
  • 34. Standish Group: ! nur 14%aller konventionellen Projekte sind in Time & Budget Immerhin, bei konventioneller, also wasserfalliger oder Rational-Unified-Process oder ähnlicher Entwicklung sieht es noch schlechter aus.
  • 35. Standish Group: ! nur 4%aller Rewrites sind in Time & Budget Und kommen wir zu den Rewrites. Nur 4% aller Rewrites sind in Time & Budget. Und nach Hofstadters Law gilt: auch wenn ich das berücksichtige und mehr Buffer einbaue. Und fast die Hälfte aller Rewrites schlägt komplett fehl und wird eingestellt.
  • 36. WTF? Gerade da, wo wir die Software schon kennen, scheitern wir? Das ist schon beeindruckend - genau da, wo wir die Software eigentlich schon haben und sie schon live ist scheitern wir am häufigsten?
  • 37. "Legacy code" often differs from its suggested alternative by actually working and scaling. Bjarne Stroustrup Bjarne Stroustrup, der Erfinder von C++, hat das schön formuliert: Legacy Code unterscheidet sich von der empfohlenen Alternative dadurch, dass er wirklich funktioniert und skaliert.
  • 38. Also doch lieber kein 
 
 Rewrite?Hmm, wenn man sich die ganzen Zahlen ansieht - also lieber doch kein Rewrite?
  • 39. Hmm, warum wollten wir noch mal einen Rewrite? Aber zurück zu uns - warum wollen wir noch mal einen Rewrite machen? Von denen, die sich vorhin gemeldet haben - was ist der Grund? Weil sich jemand aus dem Business beschwert, im Regelfall. Oder aus dem Development.
  • 40. •neue Features dauern zu lange •es gibt viele Bugs •die Software wird nicht stabil •die Architektur skaliert nicht (Cloud) •Einarbeitung dauert zu lange •Rahmenbedingungen haben sich geändert Darum wollten wir noch mal einen Rewrite. Der Haupttreiber ist meistens die Verlangsamung der Entwicklung und die fehlende Verlässlichkeit. Es dauert zu lange bis Features kommen, und da Team wird durch Bugfixes blockiert.
  • 41. Was macht der Code da? Und in Wahrheit haben wir Developer einfach keinen Bock mehr. Und würden jede Begründung dafür nehmen, Hauptsache, wir müssen nicht weiter mit dem Code arbeiten. Was macht der Code da überhaupt?
  • 42. Code is easier to write than to read. Und das gemeine dabei ist: Code ist ohnehin schneller zu schreiben als zu lesen. Und gerade alter Code ist schlecht zu lesen, sprich: da braucht es schnell deutlich länger, den Code zu lesen als neu zu schreiben.
  • 43. Änderung nötig Bekannt Prüfung erforderlich Warum gefällt uns eine neue Software besser, die wir selbst geschrieben haben? Weil wir die Teile schon kennen. Wenn ich zB Komponente 3 ändern will, weiss ich schon, dass ich Komponente 1, 5 und 4 aufrufen muss und Komponente 2 unabhängig ist. Mein Aufwand ist also auf drei Aufrufe limitiert, und die Prüfungen wie und wo das geschieht sind schnell, weil ich die Komponenten schon kenne.
  • 44. Änderung nötig Bekannt Prüfung erforderlich Bei einer Legacy Software sieht das deutlich unangenehmer aus - ich kenne bislang nur Komponente 4, und ich weiss nicht, wo sich Änderungen von Komponente 3 sonst noch auswirken können. Entweder ich arbeite jetzt im Blindflug - und probiere es einfach aus - oder ich prüfe wirklich alle möglichen vernetzten Komponenten. Der Aufwand hier ist deutlich höher, denn jetzt muss ich mich mit allen Komponenten bekannt machen.
  • 45. Unser Gehirn will auch mitspielen: Illusory Superiority Planning Fallacy Optimism Bias Unser Gehirn spielt auch mit: 80% der Leute glauben, dass sie über dem Durchschnitt liegen. Es will mir also weissmachen, ich wäre etwas fähiger als der ursprüngliche Autor. Daneben gibt es die Planning Fallacy - ich glaube, dass ich deutlich schneller bin als meine Erfahrung es eigentlich zulassen würde. Und den Optimism Bias, ich glaube, Risiken und Probleme werden mich eher nicht treffen als andere.
  • 46. <?php! ...! auth_check();! error_log(“ich bin hier“);! ...! return $user_data;! ...! auskommentiert Aber wie sieht das konkret aus? Bei einer unserer Legacy-Lösungen, konkret PHProjekt, hatten wir zum Beispiel in der SOAP-API diesen Code. Ein Kollege sollte da einen Bug fixen, und irgendwie kam er nie in die error_log-Zeile, dabei sollten doch die Termine des Nutzers zurückgegeben werden. Also hat er die Zeile schlicht auskommentiert. Und ab diesem Moment konnte man über SOAP alle Daten von allen Nutzern ohne jeglichen Authentifizierung abfragen. Und wieder ging eine Security- Issue über die Ticker.
  • 47. First Order Ignorance: ! Ich weiß, dass ich etwas nicht weiß. Technisch ist das First Order Ignorance. Ich weiss, dass es das gibt, ich weiss bloss nicht, was es macht. Mein Kollege hätte einfach in den Code reinschauen müssen, und schon hätte er gewusst, was dort passiert. Denn diese Stelle war ihm bekannt.
  • 48. johann$ find . -name "*.php" -exec cat {} ; |wc -l 49129 E_COGNITIVE_LOAD PHProjekt 4 ist eine echt kleine Software. Weniger als 50.000 Zeilen Code in der gesamten Lösung. Trotzdem ist das echt viel zu lesen. Und deshalb lese ich das nicht. Und mache auch kein dickes UML mit dem ich die Wände plakatiere.
  • 49. Second Order Ignorance: ! Ich weiß nicht, was ich nicht weiß. Aber ich weiß wie ich es herausfinde. Das ist Second Order Ignorance, die unknown Unknowns. Ich weiss gar nicht, welche Dinge ich alles nicht weiss in der Software. Da steckt so viel Kram drin, den ich nicht kenne, und wo ich auch keine Ahnung habe, wofür er gebraucht wird. Ich wüsste zwar, wie ich das herausfinde, aber ich investiere die Zeit nicht sondern fange lieber gleich an, mit was auch immer.
  • 50. <?php! ...! // important Bugfix, jph 2.5.2004! ...! // on customer request, 5.5.2005 ! ...! Und es gibt noch die Klasse von Verhalten, bei dem wir nicht wissen, was wir nicht wissen, aber auch keine Idee haben, wie wir das herausfinden. Der Bugfix von vor 7 Jahren?! Warum gab es den, wer wollte das?
  • 51. Third Order Ignorance: ! Ich weiß nicht, was ich nicht weiß, und ich weiß auch nicht wie ich es herausfinde. Das ist Third Order Ignorance. Ich weiss nicht, was ich nicht weiss, und ich habe auch keinen Weg auf dem ich das erfahre.
  • 52. Jede Änderung im alten Legacy-Code
 brauchte 2 mal Zeit: ! 1. um herauszufinden, dass es geändert werden muss ! 2. um herauszufinden, wie es geändert werden muss ! ! Und ich soll das jetzt spontan verstehen? Und das gemeine ist: bei allen diesen Unklarheiten muss ich bedenken, dass sie schon zwei mal Zeit zum Verstehen gebraucht haben. Und jemand darüber nachgedacht hat. Und jetzt soll ich das, ohne den damaligen Kontext, spontan verstehen?
  • 53. Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. Kennt jemand diese Formulierung? Das ist die Prime Directive der Scrum-Retrospektiven. Und die gilt natürlich auch für alte Software. Jetzt kann man sagen: Ja, die hatten halt nicht die Zeit, die wir jetzt haben. Aber auch sie dachten damals, dass sie die Zeit haben würden, wie wir heute.
  • 54. Schlechten Code wegwerfen und 
 neu anfangen, diesmal sauber! Uh, das ist aber viel Arbeit. Poah, das werden wir nicht schaffen. Lieber auf Funktionalität fokussieren. Hmpf, Deadline schon wieder verpasst, jetzt sind Überstunden angesagt. Ok, Qualität ist fies, aber immerhin sind wir endlich released. Wenn auch mit echt schlechtem Code. Am Ende hat man dann den Rewrite Cycle of Death ... :-) - mit wieder schlechtem Code.
  • 55. Während des Rewrites wenig bis keine neuen Features. ! ! Der Rewrite dauert deutlich länger. ! ! Die Konkurrenz überholt. Und nicht nur das passiert. Weil ich im Rewrite bin, sind die Leute, die sich mit der Software auskennen, für die neue Software gebunden, und in der bestehenden Applikation bewegt sich nur wenig. Zeitgleich dauert der Rewrite deutlich länger als erwartet. In Folge: die Konkurrenz überholt.
  • 56. ! Die neuen Kollegen ohne Knowhow: ! Wartung der Live-Applikation oder lieber in den strategisch wichtigen Rewrite? ! Doppelte Kosten pro Feature Lösung: 2 Teams? Die naheliegenste Lösung ist das doppelte Team. Das hat aber auch seine Probleme - denn ich brauche für die Weiterentwicklung das Knowhow der bestehenden Software - denn es ist komplex und tief - auf der anderen Seite will ich aber für die neue Software auch das Domainwissen aus der alten nutzen... eigentlich brauche ich doppelt so viele alte Leute. 
 Und für die Rewrite-Phase selbst habe ich das Problem der doppelten Kosten - denn jedes neue Feature muss in der alten Software wie auch in der neuen bereitstehen.
  • 57. ! ?Die Frage ist also: wie komme ich aus der Nummer raus? Wie kann ich die Software so neu machen, dass ich das überlebe?
  • 58. •Das Wissen in der Software 
 zu eigenem Wissen machen •kontinuierlicher Feature-Flow •wenig doppelte Entwicklung •am Ende eine wartbare Codebase •in Zukunft preiswerte, schnelle Features Aufgabenstellung Das ist meine Aufgabenstellung:
  • 59. Kontinuierliche Modernisierung 
 in 7 Schritten •alles ist immer produktiv •kleine Inkremente •kontinuierlicher Featurestream Und so komme ich dahin - indem ich kontinuierlich modernisiere, rewrite oder refaktoriere.
  • 60. 1. Absichern der Applikation CI Infrastruktur einführen ! CD Infrastruktur einführen ! Eine CI-Infrastruktur hat heute praktisch jeder, aber nicht jeder für die alten Projekte. Etablieren einer CI- und CD-Infrastruktur Warum mache ich das? Weil ich kontinuierlich stabil bleiben will. Wer hat bereits eine CI-Infrastruktur? Wer hat bereits eine CD-Infrastruktur? CD ist notwendig für kleine Inkremente. Wenn ich 2 Wochen zwischen den Releases habe können zu viele Dinge zerbrechlich werden. !
  • 61. 1. Absichern der Applikation Core-Workflows über Akzeptanztests sichern ! Viele sagen an dieser Stelle, gerade bei Legacy-Software: Hej, ich brauche schon 2 Wochen für die Testphase, um überhaupt sicher zu sein, dass meine Applikation releasefähig ist. Normalerweise würde man dann sagen, dass eine Applikation von beiden Seiten - sprich über Unit-Tests in der Applikation und Acceptance / Funktions/ Integrationstests von aussen abgesichert sein sollte. Im Fall von Altapplikationen ist das meist aber nicht möglich. Also sichere ich alle Kernprozesse mit Akzeptanztests ab - zum Beispiel über BDD- Tests, gerne auch JavaScript-getrieben über Jasmine, JSpec oder CucumberJS. !
  • 62. 1. Absichern der Applikation ! Monitoring ! Selenium-Cloud-Testing ! Trick 17:
 Produktionsnahe Entwicklung Wenn ich Glück habe kann ich die Akzeptanztests auch als Roboter für den Tests des Produktionsenvironments nutzen. Sonst kann ich selbst, mit einem der vielen Online-Dienste wie Pingdom oder einer der vielen Selenium-Cloud-Dienste die Applikation absichern. Wenn ich einen Rollout habe, der meine Applikation instabil zurücklässt weiss ich sofort Bescheid und kann ihn zurückrollen. Es gibt noch einen weiteren Trick, mit dem man die Produktion stabil bekommt - man benutzt schlicht ein möglichst ähnliches Environment in Development oder, wenn es dort nicht möglich ist, in Integration oder Testing. Um so früher ich die Fehler entdecke um so weniger schaffen es in Produktion.
  • 63. 2. Größter gemeinsamer Nenner Ist ein gemeinsame Codebasis möglich? ! •bei Bedarf Alt-Applikation anheben Kann man die Applikation auf eine gemeinsame Codebasis heben? Wenn ja, Glück gehabt. Wenn nein …
  • 64. 2. Proxy-Lösung Die neue Applikation ist ein Proxy vor der alten. ! Nach und nach werden Teile aus dem Proxy in die neue Applikation gezogen Wenn es nicht möglich ist, muss ich andere Wege gehen - und zum Beispiel die neue Applikation als Proxy zur alten Applikation betreiben. Oft muss ich mit regulären Ausdrücken Teile der Seite herausholen.
  • 65. 3. Gemeinsames Frontend Fallthrough-Routing: ! Alles, was die neue Applikation noch nicht selbst macht fällt zur alten Applikation durch. Egal, ob ich die Applikationen direkt integrieren kann oder einen Proxy implementiere - ich habe in der neuen Applikation einen Falltrough-Router, der alle Themen, die die neue Applikation noch nicht selbst behandeln kann, einfach zur alten Applikation durchfallen lässt.
  • 66. 4. Gemeinsame Infrastruktur: Sessions Session-Bagging/Container: ! Die neue Sessions finden in einem Namespace innerhalb der alten statt ! Damit ich den Zustand der Applikation - wie zum Beispiel die Authentifizierung - gemeinsame verwalten kann, brauche ich auch einen gemeinsamen Zustand. Bei Symfony2 kann man das mit den Session-Bags lösen, bei Zend Framework mit den Session Containern. Beim Proxy braucht man ein Interface, das diese Daten über eine Schnittstelle steuern kann. Laravel bietet keine Namespaced Sessions, hier muss man selbst über eine Session-Facade und einen Hashkey Hand anlegen.
  • 67. 4. Gemeinsame Infrastruktur: Datenzugriff Gemeinsame Datenbank wenn möglich ! Alternative: Migration mit Synchronisation für die Übergangszeit ! Wenn möglich greife ich gemeinsam auf die gleiche Datenbasis zurück. Ich war bei ein paar grossen Modernisierungsprojekten mit dabei, bei denen die Datenbasis komplett erhalten blieb - schon weil die Datenmenge so gross war, dass eine Verdopplung der Daten zu teuer gewesen wäre.
  • 68. 5. Featureflags Features können per Flag aktiviert/ deaktiviert werden ! Switch zwischen alter/neuer Variante Um die Lösung tatsächlich immer und für alle Stabil zu halten migriere ich hinter Featureflags. Sprich: es ist immer möglich, wahlweise den alten oder den neuen Code zu nutzen.
  • 69. 6. Workflow Test Abstraction Featureflag Reengineering Produktion Aufräumen pro Feature Wenn ich die Infrastruktur soweit fertig habe, kann ich in die konkrete Entwicklung gehen. Ich beginne jeweils mit einer Testabsicherung des zu migrierenden Features. Sobald die Da ist, abstrahiere ich das Feature so, dass es für die alte und die neue Variante genutzt werden kann. Dann führe ich einen Umschalter ein, der wahlweise den alten oder den neuen Code nutzt, so dass die Kollegen immer Zugriff auf eine stabile Variante haben. Danach reengineere ich den Code und stelle ihn in Produktion, sobald er fertig ist. Wenn die neue Variante damit funktioniert lösche ich den alten Zweig aus den Featureflags. Was steht konkret hinter den Schritten?
  • 70. 6.1 Test Ich etabliere Akzeptanz-Tests (zB Jasmine, Selenium, Behat) für das zu migrierende Feature Akzeptanz-Tests, Service oder Unit-Test, je nach Möglichkeit
  • 71. Strategie: Branch by Abstraction 6.2Wenn ich beide Applikationen gemeinsam verwenden kann, bietet sich Martin Fowlers Branch by Abstraction als Strategie an. Ich führe eine Abstraktion ein - zB eine Fassade - die ich über die alte Logik stülpe. Wenn ich hier stabil bin entwickle ich die neue Logik, die die gleiche Fassade bietet.
  • 72. Strategie: Add Layer 6.3 Ich führe einen Soap/REST-Layer ein. ! Beide Seiten nutzen das Soap/REST-Layer für den Zugriff auf die Funktionalität. Das ist eine der am weitesten verbreiteten Modernisierungs-Strategien - Add Layer — die Modernisierung zugunsten von Services. Bei uns ist das schon lange nicht mehr Soap, sondern im Regelfall REST. In diesem Fall führe ich einen REST-Layer ein.
  • 73. Strategie: Dependecy Injection & Container 6.4 Ich führe eine DI-basierte Struktur ein ! Beide Seiten nutzen den DI-Container für den Zugriff auf die Funktionalität. Der Service muss auch nicht per se nach draussen zeigen - er kann auch von innen zugänglich gemacht werden. Wenn meine Modernisierung in Richtung DI-Framework geht, dann kann ich genau an der Schnittstelle Locator/Container auch modernisieren.
  • 74. Reengineering 6.5 Ich schreibe die neue Version hinter der Abstraction und hinter dem Featureflag. 
 Alt und neu existieren parallel.
  • 75. Produktion 6.6 Das neue Feature geht live und wird per Featureflag auch in der Produktion aktiviert. Branch By Abstraction oder Rest-Service
  • 76. Aufräumen 6.7 Wenn nach hinreichender Zeit keine Probleme (mehr) auftreten, wird sowohl der alte Code als auch das Featureflag entfernt. Alte Routen löschen, ebenso die kompletten Schalter hinter den Feature Flags.
  • 77. 7. Bei Bedarf: Datenmigration Wenn sich Schema oder Datenbanksystem ändern: ! Synchronisierung für die Migrationsphase ! Double Write Single Read Manche Modernisierungen lassen sich ohne Änderung der Daten durchführen - viele aber nicht. In diesem Fall braucht man einen Plan. Handelt es sich um die gleiche Datenbank, kann man mit Triggern arbeiten um die Daten synchron zu halten. Handelt es sich um eine andere Datenbank wird es schwieriger. Wenn ich zum Beispiel nach MongoDB migriere kann ich nicht jede Tabelle einzeln umziehen. Dieses Problem löst man mit einem Double Write und einem Single Read - es wird also zwei mal geschrieben - in die neue Datenbank wie in die alte - aber nur einmal gelesen, in den neuen Teilen aus der neuen Datenbank und in den alten Teilen aus der alten Datenbank.
  • 78. 8. Organisation Modernization Map (Klassen) ! Modernization Burn-Down Ich kenne einige Applikationen mit mehrfach abgebrochenen Modernisierungsversuchen. Das beste was ich bislang gesehen habe war eine Ursprungssoftware mit 6 unterschiedlichen Modernisierungsversuchen, die alle nebeneinander existierten - inklusive redundanter Funktionalität, die je nach Aufrufpfad zum Teil noch mehrfach in Produktion war.
  • 79. Unsere Wins & Fails PHProjekt: OpenSource-Groupware
 ! ca 150.000 Zeilen Code ! Rewrite von Big Ball of Mud 
 nach Zend Framework & Qualität ! Nach 4 Jahren: guter Code, 
 weniger Features, keine Nutzer Unsere Erfahrungen. Wir haben eine alte, bekannte OpenSource-Software in der Firma, die mal eine der am weitesten verbreiteten Groupware-Lösungen war. Bis wir sie rewriten wollten.
  • 80. MediaCloud
 ! ca 600.000 Zeilen Code ! Rewrite nach SOA, sehr nah am Original ! Time & Budget nicht gehalten ! Problematische One-Time-Datenmigration Unsere Wins & Fails Daneben haben wir eine eher grosse Media-Cloud-Lösung gebaut, die aus mehr oder weniger politischen Gründen modernisiert werden musste. Dort wurde ein Rewrite in Richtung SOA- Geschmacksrichtung REST - und NoSQL gemacht.
  • 81. Grosses Dokumentationsystem ! ca 1.000.000 Zeilen Legacy-Code in einem proprietären Framework ! 2012 nach DI-Framework modernisiert mittels Proxy-Variante ! kontinuierliche Datenmigration Unsere Wins & Fails Nächstes Fallbeispiel, eine grosse Dokumentenlösung, mit der spezialisierte, internationalisierte Wartungsmaterialien erstellt und gepflegt werden.
  • 82. Infrastruktur kostet 
 weniger Zeit als erwartet Learnings Wenn man eine langsame Modernisierung macht: die Infrastruktur kostet nicht so viel Zeit - und es macht sogar Spass. Und ein guter Nebeneffekt: die Einführung von Tests verzinst sich schnell, es wird frühzeitig spürbar, dass weniger Bugs auftreten.
  • 83. Raus aus der Black Box! Learnings Erste und wichtigste Lehre: Raus aus der Black Box. Immer möglichst viel echte Nutzer kontinuierlich auf der Software.
  • 84. Learnings Die ersten Features kosten deutlich mehr Zeit als erwartet Am Anfang dauert es sehr lange, weil jedes Feature seine Grundlagen mitzieht. Hier passieren grössere Reengineerings, die in Abhängigkeit voneinander stattfinden.
  • 85. Man wird mit der Zeit deutlich schneller Learnings Am Anfang migriert man mit jedem Feature einen grossen Teil der Infrastruktur, und diese Phase ist wirklich zäh. Aber zum Ende hin, wenn viele abhängige Komponenten häufig schon migriert sind, beschleunigt sich die Migration sehr.
  • 88. Wann mache ich trotzdem einen Rewrite? Die Software wird in Wahrheit 
 gar nicht genutzt ! Es wird nur ein kleiner Teil 
 der Software genutzt ! Die Software ist klein. ! Es ist gar kein Rewrite.
  • 89. Modernisierung FTW! Kontinuierlich, immer in Produktion ! Es geht auch mit inkompatiblen Stacks ! Programmieren um wegzuwerfen spart Zeit und Geld.
  • 90. Qualität ist die Übereinstimmung von Produktleistung und Kundenwunsch. (Nicht Developervorstellung) Reminder Lüönd, 2004 - Das ist das, was bei einem Rewrite am Ende herauskommen sollte. Qualität ist nicht wenn Developer glücklich sind. !