SlideShare uma empresa Scribd logo
1 de 92
Baixar para ler offline
Hallo zusammen!

Hallo, guten morgen Hamburg! Ich bin Johann, und nicht ganz echter CTO.
Ein Vortrag _ohne_
Microsoft-Bashing

Neu!

Willkommen zu einer Premiere - ich habe mal einen Vortrag ohne Microsoft-Bashing.

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 ganz
schlimm falsch gemacht.

Ihr müsst das also
nicht mehr falsch zu machen.
Wir haben die Fehler alle schon gemacht. Ihr braucht jetzt nicht auch noch.

Wer von Euch macht gerade eine

Modernisierung?
Und wer macht gerade eine Modernisierung? :-)
Ein Bild von damals, als die Pixel noch nen halben Meter gross waren. 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.
Das ist sein Nightclub, die DNA Lounge, den er sich vom Netscape-Geld gekauft hat.
CADT
Aber zurück zum Thema. Und er hat folgendes Entwicklungsmodell gefunden. CADT. Kann
sich jemand vorstellen, was das heisst?
Cascade of AttentionDeficit Teenagers
„Poah, die Software ist
so eine Grütze, da mache
ich lieber einen Rewrite.“

Auf den Rewriteversuch
folgt der Rewriteversuch.
Das ist die Kaskade von Aufmerksamkeits-Defizit-Syndrom-Teenagern.
Cascade of AttentionDeficit 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 AttentionDeficit 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 Spass?
Genau, ich auch.
Ich bleibe noch in einem kurzen Opa-erzählt-vom-Krieg-Modus.
Das hier ist der erste Browser, geschrieben vom Team von Marc Andreessen.
Marc Andreessen machte sich dann mit etwas Venture-Capital selbstständig und gründete
Netscape Communications, und macht den Browser zu einem richtigen Produkt. Dieses war
der - richtig - Netscape Navigator. Und genau an dem hatte Jamie Zawinski mitgewirkt.
1995
80%

Market Share

Und tatsächlich ging das Geschäft auf - 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
Aber der Code
ist jetzt super!

10%

Market Share

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% aller 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?
Also lieber
doch 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.
So, warum wollten wir noch mal einen

Rewrite?

•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
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. 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.
1999-2005
„Gewachsene Codebase“

Und warum ist das so? Weil wir damals Software anders geschrieben haben.Gerne spricht man
da über Software aus der Pre-Framework-Ära. Gerne mit PHPLib, Pear, Smarty und _vielen_
eigenen Libraries realisiert.
1999-2005
Objektorientiert zum Teil
Design Patterns fast nicht vorhanden
SOLID Wer ist „SOLID?“

Wenn man Glück hat, ist der Code wenigstens zum Teil Objektorientiert. Design Patterns
spielen eine kleine Rolle. Saubere Objektorientierung, sei es SOLID oder GRASP, findet noch
nicht statt. Bei wem ist das so?
Big Ball
of Mud

http://www.flickr.com/photos/theclyde

„Ein Big Ball of Mud ist ein planlos strukturierter, weitläufiger, schlampiger, mit
Klebeband fixierter und Ballenpressdraht zusammengeschnürter Spaghetti-CodeDschungel. Derartige Systeme tendieren zu ungehemmtem Wachstum und benötigen
laufende Betreuung. Die in diesen Systemen enthaltenen Informationen sind wahllos über
die entferntesten Elemente verteilt, oft bis zu dem Punkt, wo fast alle wichtigen
Informationen global oder dupliziert sind. Die Architektur derartiger Systeme wurde
vielleicht nie richtig definiert, und wenn doch ist sie bis zur Unkenntlichkeit erodiert.
Programmierer mit einem Fetzen architektonischer Sensibilität meiden derartige Sümpfe.
Nur diejenigen, die sich nicht um Architektur scheren und vielleicht sogar gerne Tag für Tag
mühsam Löcher in undichten Deichen stopfen, arbeiten gerne mit solchen Systemen.“ Wer
kennt solche Systeme? Wer hat schon selbst welche gebaut?
Schlechte Code-Qualität:

• lange Funktionen/Methoden
• grosse, allmächtige Klassen
• Komplexität jenseits von Gut und Böse
• Low Cohesion
• Strong Coupling
•„Spaghetti SQL in Spaghetti PHP in
Spaghetti HTML“

Da findet man vor allem die klassischen Dinge, die einem heute auch die CI anmahnen würde
- schlechter Coding Style, schwer zu lesender Code, schwer zu lesende Methoden und
schlechte, unvorhersehbare Struktur.
Aus dieser Zeit stammt auch noch unser fantastischer Ruf. Sind hier im Raum Ruby- oder
Java-Entwickler? Ihr wisst, was ich meine.
2005-2011
„Framework-Ära“

Die nächste Zeit der PHP-Entwicklung war etwas besser. Da haben wir mit dem ZendFramework, mit Symfony, mit Cake-PHP, Code-Igniter und vielen anderen sowohl brauchbare
OO als auch Design Patterns bekommen. Also kein Big Ball of Mud, trotzdem macht sie
Probleme.
2005-2011
„Framework-Ära“

• Framework ist nicht mehr zeitgemäß
• Migration ist sehr aufwändig
Aber auch bei den Frameworks gibt es Probleme - denn auch diese Frameworks sind nicht
mehr zeitgemäß, und man möchte eigentlich nicht mehr mit ihnen Entwicklen. Die Migration
ist aber sehr mühsam, weil sich nicht nur bei den PHP-Versionen, sondern vor allem auch bei
der Art zu Arbeiten viel geändert hat - Dependency Injection war zum Beispiel noch kein so
grosses Thema wie heute.
Was macht der Code da?

Viel spannender sind aber meist die Fragen: Was macht der Code da? Warum gibt es das
ü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.
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 unterschätze Aufgaben, die ich selbst erledigt, und
der Optimism Bias, der mir erzählen will, wieviel besser die Welt wird, wenn erst einmal meine
Lösung online ist.
<?php
auskommentiert
...
auth_check();
error_log(“ich bin hier“);
...
return $user_dates;
...
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

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.
Lösung: 2 Teams?
Die neuen Kollegen ohne Knowhow:



Wartung der Live-Applikation
oder lieber in den strategisch
wichtigen Rewrite?
Doppelte Kosten pro Feature

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
•keine doppelte Entwicklung
•am Ende eine wartbare Codebase
•in Zukunft preiswerte, schnelle Features

Aufgabenstellung
Das ist meine Aufgabenstellung:
Kontinuierliche
Modernisierung/
Rewrite
•alles ist immer produktiv
•kleine Inkremente
•kontinuierlicher Featurestream
Und so komme ich dahin - indem ich kontinuierlich modernisiere, rewrite oder refaktoriere.
Absichern der Applikation
CI Infrastruktur einführen
CD Infrastruktur einführen
Core-Workflows über Akzeptanztests
sichern
Monitoring
Produktionsnahe Entwicklung
Etablieren einer CI- und CD-Infrastruktur
Wenn der alte Code testbar ist:
Absicherung der Basisfeatures durch Akzeptanztests
Monitoring etablieren (Responsivität, Logfiles, etc)
Produktionsnahe Entwicklung über Vagrant etc - das gilt natürlich auch für Test.

1.
Größter gemeinsamer Nenner
Ist ein gemeinsames PHP möglich?

•bei Bedarf Alt-Applikation anheben
Symfony
Zend Framework
Laravel 4

5.3.3
5.3.3
5.3.7

2.

Kann man ein gemeinsames PHP betreiben?
Es gibt für den PHP CodeSniffer Checks, wo die alte Applikation den neuen PHP-Versionen
widerspricht.
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

2.

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.
Gemeinsames Frontend
Fallthrough-Router:
Alles, was die neue Applikation noch nicht
selbst macht fällt zur alten Applikation
durch.

3.

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.
Gemeinsame Infrastruktur:
Sessions
Session-Bagging/Container:
Die neue Sessions finden in einem
Namespace innerhalb der alten statt

4.

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.
Gemeinsame Infrastruktur:
Datenzugriff
Gemeinsame Datenbank wenn möglich
Alternative: Migration mit
Synchronisation für die Übergangszeit

4.
Featureflags

Features können per Flag aktiviert/
deaktiviert werden
Switch zwischen alter/neuer Variante

5.

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.
Workflow
Test
Aufräumen

Abstraction
pro Feature

Produktion

6.

Featureflag

Reengineering

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?
Test
Ich etabliere Akzeptanz-Tests (zB
Jasmine, Selenium, Behat) für das zu
migrierende Feature

6.1

Akzeptanz-Tests, Service oder Unit-Test, je nach Möglichkeit
Branch by Abstraction

6.2

Wenn ich beide Applikationen gemeinsam verwenden kann, nutze ich Branch by Abstraction.
Ich führe eine Facade in der Mitte ein, greife auf Sie zu. Bei Symfony2 und Zend Framework
bieten Services als Sammlung dieser Fassaden. Damit lässt sich die Serviceinfrastruktur der
Applikation gut migrieren.
Abstraction: SOA
Ich führe einen REST-Layer ein.
Beide Seiten nutzen das REST-Layer für
den Zugriff auf die Funktionalität.

6.3

Das ist eine der am weitesten verbreiteten Modernisierungs-Strategien - 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.
Reengineering
Ich schreibe die neue Version
hinter der Abstraction und
hinter dem Featureflag.
Alt und neu existieren parallel.

Branch By Abstraction oder Rest-Service

6.4
Produktion

Das neue Feature geht live und wird per
Featureflag auch in der Produktion
aktiviert.

Branch By Abstraction oder Rest-Service

6.5
Aufräumen

Wenn nach hinreichender Zeit keine
Probleme (mehr) auftreten,
wird sowohl der alte Code als auch das
Featureflag entfernt.

Alte Routen löschen

6.6
Bei Bedarf: Datenmigration
Wenn sich Schema oder
Datenbanksystem ändern:
Synchronisierung für die
Migrationsphase

Alte Routen löschen

7.
Organisation

Modernization Burn-Down

Modernization-BurnDown

8.
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
Medialösung
Unsere Wins & Fails
MediaCloud
ca 600.000 Zeilen Code
Rewrite nach SOA, sehr nah am Original
Time & Budget nicht gehalten
Problematische One-Time-Datenmigration
Medialösung
Unsere Wins & Fails
Grosses Dokumentationsystem
ca 1.000.000 Zeilen Legacy-Code in einem
proprietären Framework
2012 nach Symfony 2 modernisiert
in der Proxy-Variante
kontinuierliche Datenmigration
Dokumentenlösung
Learnings
Infrastruktur kostet
weniger Zeit als erwartet
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.
Learnings
Raus aus der

Black Box!
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.
Learnings

Man wird mit der Zeit
deutlich schneller
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.
Ich gehöre zu den 4%. It‘s magic!
Modernisierung FTW!
Kontinuierlich, immer in Produktion
Es geht auch mit inkompatiblen PHPVersionen
Programmieren um wegzuwerfen spart
Zeit und Geld.
Reminder
Qualität ist die
Übereinstimmung von
Produktleistung und
Kundenwunsch.
Lüönd, 2004 - Qualität ist nicht der SourceCode.
Danke!

Mais conteúdo relacionado

Destaque (16)

Management brainfucks
Management brainfucksManagement brainfucks
Management brainfucks
 
Von Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und SystemadministratorenVon Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und Systemadministratoren
 
DevOps jenseits der Tools
DevOps jenseits der ToolsDevOps jenseits der Tools
DevOps jenseits der Tools
 
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
 
DevOps beyond the Tools
DevOps beyond the ToolsDevOps beyond the Tools
DevOps beyond the Tools
 
Einfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesEinfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektes
 
Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!
 
JavaScript Security
JavaScript SecurityJavaScript Security
JavaScript Security
 
Die Architektur, die man kann
Die Architektur, die man kannDie Architektur, die man kann
Die Architektur, die man kann
 
Javascript Security
Javascript SecurityJavascript Security
Javascript Security
 
Agile versus Management WJAX 2014
Agile versus Management WJAX 2014Agile versus Management WJAX 2014
Agile versus Management WJAX 2014
 
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?
 
Leadership in der IT
Leadership in der ITLeadership in der IT
Leadership in der IT
 
NewWork in der Praxis
NewWork in der PraxisNewWork in der Praxis
NewWork in der Praxis
 
Wetware Bugs and Refactoring
Wetware Bugs and RefactoringWetware Bugs and Refactoring
Wetware Bugs and Refactoring
 
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
 

Semelhante a Rewrites überleben

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 Days 2015: Security
JavaScript Days 2015: SecurityJavaScript Days 2015: Security
JavaScript Days 2015: SecurityMayflower GmbH
 
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
 
SEODAY2016 - 10 SEO Coder Hooks
SEODAY2016 - 10 SEO Coder HooksSEODAY2016 - 10 SEO Coder Hooks
SEODAY2016 - 10 SEO Coder HooksConstantin
 
E-Commerce Organisationsstrukturen
E-Commerce OrganisationsstrukturenE-Commerce Organisationsstrukturen
E-Commerce OrganisationsstrukturenBjörn Schotte
 
Digital Publishing Übersicht & Strategie
Digital Publishing Übersicht & StrategieDigital Publishing Übersicht & Strategie
Digital Publishing Übersicht & StrategieHaeme Ulrich
 
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
 
Befreite Barrierefreiheit - A-Tag Wien 2008
Befreite Barrierefreiheit - A-Tag Wien 2008Befreite Barrierefreiheit - A-Tag Wien 2008
Befreite Barrierefreiheit - A-Tag Wien 2008Christian Heilmann
 
Datenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software AnalyticsDatenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software AnalyticsMarkus Harrer
 
Browserstrategien und Progressive Enhancement
Browserstrategien und Progressive EnhancementBrowserstrategien und Progressive Enhancement
Browserstrategien und Progressive EnhancementAperto Nachname
 
Desktop Publishing war 1985. Jetzt geht mehr!
Desktop Publishing war 1985. Jetzt geht mehr!Desktop Publishing war 1985. Jetzt geht mehr!
Desktop Publishing war 1985. Jetzt geht mehr!Haeme Ulrich
 
Eine Stunde was mit Api First!
Eine Stunde was mit Api First!Eine Stunde was mit Api First!
Eine Stunde was mit Api First!JanWeinschenker
 
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
 
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
 
Development in der Cloud-Ära
Development in der Cloud-ÄraDevelopment in der Cloud-Ära
Development in der Cloud-ÄraAndreas Koop
 
Arbeitswelt2020PechaKucha
Arbeitswelt2020PechaKuchaArbeitswelt2020PechaKucha
Arbeitswelt2020PechaKuchaElsy Zollikofer
 

Semelhante a Rewrites überleben (20)

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 Days 2015: Security
JavaScript Days 2015: SecurityJavaScript Days 2015: Security
JavaScript Days 2015: Security
 
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
 
SEODAY2016 - 10 SEO Coder Hooks
SEODAY2016 - 10 SEO Coder HooksSEODAY2016 - 10 SEO Coder Hooks
SEODAY2016 - 10 SEO Coder Hooks
 
E-Commerce Organisationsstrukturen
E-Commerce OrganisationsstrukturenE-Commerce Organisationsstrukturen
E-Commerce Organisationsstrukturen
 
WWruhr2018
WWruhr2018WWruhr2018
WWruhr2018
 
Digital Publishing Übersicht & Strategie
Digital Publishing Übersicht & StrategieDigital Publishing Übersicht & Strategie
Digital Publishing Übersicht & Strategie
 
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.
 
Befreite Barrierefreiheit - A-Tag Wien 2008
Befreite Barrierefreiheit - A-Tag Wien 2008Befreite Barrierefreiheit - A-Tag Wien 2008
Befreite Barrierefreiheit - A-Tag Wien 2008
 
Datenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software AnalyticsDatenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software Analytics
 
Advanced Continuous Integration
Advanced Continuous IntegrationAdvanced Continuous Integration
Advanced Continuous Integration
 
Browserstrategien und Progressive Enhancement
Browserstrategien und Progressive EnhancementBrowserstrategien und Progressive Enhancement
Browserstrategien und Progressive Enhancement
 
Desktop Publishing war 1985. Jetzt geht mehr!
Desktop Publishing war 1985. Jetzt geht mehr!Desktop Publishing war 1985. Jetzt geht mehr!
Desktop Publishing war 1985. Jetzt geht mehr!
 
Eine Stunde was mit Api First!
Eine Stunde was mit Api First!Eine Stunde was mit Api First!
Eine Stunde was mit Api First!
 
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
 
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
 
Arbeitswelt2020 pecha kucha
Arbeitswelt2020 pecha kuchaArbeitswelt2020 pecha kucha
Arbeitswelt2020 pecha kucha
 
Development in der Cloud-Ära
Development in der Cloud-ÄraDevelopment in der Cloud-Ära
Development in der Cloud-Ära
 
Development in der Cloud-Ära
Development in der Cloud-ÄraDevelopment in der Cloud-Ära
Development in der Cloud-Ära
 
Arbeitswelt2020PechaKucha
Arbeitswelt2020PechaKuchaArbeitswelt2020PechaKucha
Arbeitswelt2020PechaKucha
 

Mais de Johann-Peter Hartmann

Mais de Johann-Peter Hartmann (7)

The End of my Career
The End of my CareerThe End of my Career
The End of my Career
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
 
Surviving Complexity
Surviving ComplexitySurviving Complexity
Surviving Complexity
 
Serverside Cryptoparty
Serverside CryptopartyServerside Cryptoparty
Serverside Cryptoparty
 
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
 
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
 

Rewrites überleben

  • 1. Hallo zusammen! Hallo, guten morgen Hamburg! Ich bin Johann, und nicht ganz echter CTO.
  • 2. Ein Vortrag _ohne_ Microsoft-Bashing Neu! Willkommen zu einer Premiere - ich habe mal einen Vortrag ohne Microsoft-Bashing.
  • 3.  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?
  • 4.  Wer von Euch plant gerade einen Rewrite? Wer plant einen in Zukunft? Genau die Leute möchte ich in meinem Vortrag sehen.
  • 5.  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?
  • 6.  Ich bin hier um Euch das auszureden. Ich bin heute hier um Euch das auszureden.
  • 7.  Wir haben das schon ganz schlimm falsch gemacht. Ihr müsst das also nicht mehr falsch zu machen. Wir haben die Fehler alle schon gemacht. Ihr braucht jetzt nicht auch noch.
  • 8.  Wer von Euch macht gerade eine Modernisierung? Und wer macht gerade eine Modernisierung? :-)
  • 9. Ein Bild von damals, als die Pixel noch nen halben Meter gross waren. Kennt das noch jemand von Euch? Ok, doch ein paar alte Leute hier. Welcher Jahrgang?
  • 10. 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.
  • 11. 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.
  • 12. Das ist sein Nightclub, die DNA Lounge, den er sich vom Netscape-Geld gekauft hat.
  • 13. CADT Aber zurück zum Thema. Und er hat folgendes Entwicklungsmodell gefunden. CADT. Kann sich jemand vorstellen, was das heisst?
  • 14. Cascade of AttentionDeficit Teenagers „Poah, die Software ist so eine Grütze, da mache ich lieber einen Rewrite.“ Auf den Rewriteversuch folgt der Rewriteversuch. Das ist die Kaskade von Aufmerksamkeits-Defizit-Syndrom-Teenagern.
  • 15. Cascade of AttentionDeficit 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.
  • 16. ? Cascade of AttentionDeficit 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 Spass? Genau, ich auch.
  • 17. Ich bleibe noch in einem kurzen Opa-erzählt-vom-Krieg-Modus. Das hier ist der erste Browser, geschrieben vom Team von Marc Andreessen.
  • 18. Marc Andreessen machte sich dann mit etwas Venture-Capital selbstständig und gründete Netscape Communications, und macht den Browser zu einem richtigen Produkt. Dieses war der - richtig - Netscape Navigator. Und genau an dem hatte Jamie Zawinski mitgewirkt.
  • 19. 1995 80% Market Share Und tatsächlich ging das Geschäft auf - 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 Aber der Code ist jetzt super! 10% Market Share 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% aller 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. Also lieber doch kein Rewrite? Hmm, wenn man sich die ganzen Zahlen ansieht - also lieber doch kein Rewrite?
  • 38. 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.
  • 39. So, warum wollten wir noch mal einen Rewrite? •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 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. 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.
  • 40. 1999-2005 „Gewachsene Codebase“ Und warum ist das so? Weil wir damals Software anders geschrieben haben.Gerne spricht man da über Software aus der Pre-Framework-Ära. Gerne mit PHPLib, Pear, Smarty und _vielen_ eigenen Libraries realisiert.
  • 41. 1999-2005 Objektorientiert zum Teil Design Patterns fast nicht vorhanden SOLID Wer ist „SOLID?“ Wenn man Glück hat, ist der Code wenigstens zum Teil Objektorientiert. Design Patterns spielen eine kleine Rolle. Saubere Objektorientierung, sei es SOLID oder GRASP, findet noch nicht statt. Bei wem ist das so?
  • 42. Big Ball of Mud http://www.flickr.com/photos/theclyde „Ein Big Ball of Mud ist ein planlos strukturierter, weitläufiger, schlampiger, mit Klebeband fixierter und Ballenpressdraht zusammengeschnürter Spaghetti-CodeDschungel. Derartige Systeme tendieren zu ungehemmtem Wachstum und benötigen laufende Betreuung. Die in diesen Systemen enthaltenen Informationen sind wahllos über die entferntesten Elemente verteilt, oft bis zu dem Punkt, wo fast alle wichtigen Informationen global oder dupliziert sind. Die Architektur derartiger Systeme wurde vielleicht nie richtig definiert, und wenn doch ist sie bis zur Unkenntlichkeit erodiert. Programmierer mit einem Fetzen architektonischer Sensibilität meiden derartige Sümpfe. Nur diejenigen, die sich nicht um Architektur scheren und vielleicht sogar gerne Tag für Tag mühsam Löcher in undichten Deichen stopfen, arbeiten gerne mit solchen Systemen.“ Wer kennt solche Systeme? Wer hat schon selbst welche gebaut?
  • 43. Schlechte Code-Qualität: • lange Funktionen/Methoden • grosse, allmächtige Klassen • Komplexität jenseits von Gut und Böse • Low Cohesion • Strong Coupling •„Spaghetti SQL in Spaghetti PHP in Spaghetti HTML“ Da findet man vor allem die klassischen Dinge, die einem heute auch die CI anmahnen würde - schlechter Coding Style, schwer zu lesender Code, schwer zu lesende Methoden und schlechte, unvorhersehbare Struktur.
  • 44. Aus dieser Zeit stammt auch noch unser fantastischer Ruf. Sind hier im Raum Ruby- oder Java-Entwickler? Ihr wisst, was ich meine.
  • 45. 2005-2011 „Framework-Ära“ Die nächste Zeit der PHP-Entwicklung war etwas besser. Da haben wir mit dem ZendFramework, mit Symfony, mit Cake-PHP, Code-Igniter und vielen anderen sowohl brauchbare OO als auch Design Patterns bekommen. Also kein Big Ball of Mud, trotzdem macht sie Probleme.
  • 46. 2005-2011 „Framework-Ära“ • Framework ist nicht mehr zeitgemäß • Migration ist sehr aufwändig Aber auch bei den Frameworks gibt es Probleme - denn auch diese Frameworks sind nicht mehr zeitgemäß, und man möchte eigentlich nicht mehr mit ihnen Entwicklen. Die Migration ist aber sehr mühsam, weil sich nicht nur bei den PHP-Versionen, sondern vor allem auch bei der Art zu Arbeiten viel geändert hat - Dependency Injection war zum Beispiel noch kein so grosses Thema wie heute.
  • 47. Was macht der Code da? Viel spannender sind aber meist die Fragen: Was macht der Code da? Warum gibt es das überhaupt?
  • 48. 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.
  • 49. 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 unterschätze Aufgaben, die ich selbst erledigt, und der Optimism Bias, der mir erzählen will, wieviel besser die Welt wird, wenn erst einmal meine Lösung online ist.
  • 50. <?php auskommentiert ... auth_check(); error_log(“ich bin hier“); ... return $user_dates; ... 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.
  • 51. 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.
  • 52. johann$ find . -name "*.php" -exec cat {} ; |wc -l 49129 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.
  • 53. 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.
  • 54. <?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?
  • 55. 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.
  • 56. 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?
  • 57. 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.
  • 58. 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.
  • 59. 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.
  • 60. Lösung: 2 Teams? Die neuen Kollegen ohne Knowhow:  Wartung der Live-Applikation oder lieber in den strategisch wichtigen Rewrite? Doppelte Kosten pro Feature 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.
  • 61.  ? Die Frage ist also: wie komme ich aus der Nummer raus? Wie kann ich die Software so neu machen, dass ich das überlebe?
  • 62. •Das Wissen in der Software zu eigenem Wissen machen •kontinuierlicher Feature-Flow •keine doppelte Entwicklung •am Ende eine wartbare Codebase •in Zukunft preiswerte, schnelle Features Aufgabenstellung Das ist meine Aufgabenstellung:
  • 63. Kontinuierliche Modernisierung/ Rewrite •alles ist immer produktiv •kleine Inkremente •kontinuierlicher Featurestream Und so komme ich dahin - indem ich kontinuierlich modernisiere, rewrite oder refaktoriere.
  • 64. Absichern der Applikation CI Infrastruktur einführen CD Infrastruktur einführen Core-Workflows über Akzeptanztests sichern Monitoring Produktionsnahe Entwicklung Etablieren einer CI- und CD-Infrastruktur Wenn der alte Code testbar ist: Absicherung der Basisfeatures durch Akzeptanztests Monitoring etablieren (Responsivität, Logfiles, etc) Produktionsnahe Entwicklung über Vagrant etc - das gilt natürlich auch für Test. 1.
  • 65. Größter gemeinsamer Nenner Ist ein gemeinsames PHP möglich? •bei Bedarf Alt-Applikation anheben Symfony Zend Framework Laravel 4 5.3.3 5.3.3 5.3.7 2. Kann man ein gemeinsames PHP betreiben? Es gibt für den PHP CodeSniffer Checks, wo die alte Applikation den neuen PHP-Versionen widerspricht.
  • 66. 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 2. 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.
  • 67. Gemeinsames Frontend Fallthrough-Router: Alles, was die neue Applikation noch nicht selbst macht fällt zur alten Applikation durch. 3. 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.
  • 68. Gemeinsame Infrastruktur: Sessions Session-Bagging/Container: Die neue Sessions finden in einem Namespace innerhalb der alten statt 4. 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.
  • 69. Gemeinsame Infrastruktur: Datenzugriff Gemeinsame Datenbank wenn möglich Alternative: Migration mit Synchronisation für die Übergangszeit 4.
  • 70. Featureflags Features können per Flag aktiviert/ deaktiviert werden Switch zwischen alter/neuer Variante 5. 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.
  • 71. Workflow Test Aufräumen Abstraction pro Feature Produktion 6. Featureflag Reengineering 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?
  • 72. Test Ich etabliere Akzeptanz-Tests (zB Jasmine, Selenium, Behat) für das zu migrierende Feature 6.1 Akzeptanz-Tests, Service oder Unit-Test, je nach Möglichkeit
  • 73. Branch by Abstraction 6.2 Wenn ich beide Applikationen gemeinsam verwenden kann, nutze ich Branch by Abstraction. Ich führe eine Facade in der Mitte ein, greife auf Sie zu. Bei Symfony2 und Zend Framework bieten Services als Sammlung dieser Fassaden. Damit lässt sich die Serviceinfrastruktur der Applikation gut migrieren.
  • 74. Abstraction: SOA Ich führe einen REST-Layer ein. Beide Seiten nutzen das REST-Layer für den Zugriff auf die Funktionalität. 6.3 Das ist eine der am weitesten verbreiteten Modernisierungs-Strategien - 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.
  • 75. Reengineering Ich schreibe die neue Version hinter der Abstraction und hinter dem Featureflag. Alt und neu existieren parallel. Branch By Abstraction oder Rest-Service 6.4
  • 76. Produktion Das neue Feature geht live und wird per Featureflag auch in der Produktion aktiviert. Branch By Abstraction oder Rest-Service 6.5
  • 77. Aufräumen Wenn nach hinreichender Zeit keine Probleme (mehr) auftreten, wird sowohl der alte Code als auch das Featureflag entfernt. Alte Routen löschen 6.6
  • 78. Bei Bedarf: Datenmigration Wenn sich Schema oder Datenbanksystem ändern: Synchronisierung für die Migrationsphase Alte Routen löschen 7.
  • 80. 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 Medialösung
  • 81. Unsere Wins & Fails MediaCloud ca 600.000 Zeilen Code Rewrite nach SOA, sehr nah am Original Time & Budget nicht gehalten Problematische One-Time-Datenmigration Medialösung
  • 82. Unsere Wins & Fails Grosses Dokumentationsystem ca 1.000.000 Zeilen Legacy-Code in einem proprietären Framework 2012 nach Symfony 2 modernisiert in der Proxy-Variante kontinuierliche Datenmigration Dokumentenlösung
  • 83. Learnings Infrastruktur kostet weniger Zeit als erwartet 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.
  • 84. Learnings Raus aus der Black Box! Erste und wichtigste Lehre: Raus aus der Black Box. Immer möglichst viel echte Nutzer kontinuierlich auf der Software.
  • 85. 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.
  • 86. Learnings Man wird mit der Zeit deutlich schneller 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.
  • 89. 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. Ich gehöre zu den 4%. It‘s magic!
  • 90. Modernisierung FTW! Kontinuierlich, immer in Produktion Es geht auch mit inkompatiblen PHPVersionen Programmieren um wegzuwerfen spart Zeit und Geld.
  • 91. Reminder Qualität ist die Übereinstimmung von Produktleistung und Kundenwunsch. Lüönd, 2004 - Qualität ist nicht der SourceCode.