Legacy php - Sanieren oder Ablösen?

1. Legacy PHP Projekte Sanieren oder ablösen? Legacy PHP Projekte - Sanieren oder ablösen? Leider wieder so viele Slides, aber wie immer alles zum nachlesen mit Fliesstext auf Slideshare. Es tut mir leid, aber da sind einfach so viele Dinge die so wichtig sind.

2. Das bin ich vor 16 Jahren auf der ersten PHP-Konferenz. Da ging es noch darum, PHP auch in Firmen einzusetzen. Und heute rede ich unter anderem darüber, wie man es wieder los wird :-) Das mit dem etablieren scheint ja geklappt zu haben :-)

3. Chief Tailwind Officer @ Mayflower Viele PHP-Lösungen   gebaut & beraten Dazu: GoLang, Scala, Java, Python, Rust, Node.JS etc Mit Björn, der auf dem Bild nicht zu sehen ist, weil er es macht, habe ich dann Mayflower gegründet - mit der Absicht, PHP mit Schulungen, Support etc für Unternehmen zugänglich zu machen. Das hat, wie man hier an der Konferenz erkennen kann, ja durchaus geklappt. Wir haben da viele grosse PHP-Lösungen mitgebaut und auch dabei beraten, aber inzwischen machen wir - wie alle anderen auch - auch viele andere Plattformen.

4. Legacy PHP Projekte Sanieren oder ablösen? Und weil wir beide Seiten gut kennen dieser Talk. Ich habe selbst keine Ambitionen, was Programmiersprachen, Plattformen etc angeht. Ich habe parallel einen Macbook, einen Windows 10 und einen Linux-Laptop, und ein iPhone und ein Android-Handy in der Tasche. Ich mag alle Plattformen. Wenn auch alles was OpenSource ist etwas lieber. Aber warum der Talk.

5. x Wenn man an der richtigen Stelle nachguckt, ist PHP immer noch Super erfolgreich. 82.2 % aller Websites werden mit PHP betrieben, sogar gestern Abend noch! Aber: wenn auf Platz 5 Cold Fusion kommt, dann stimmt daran etwas nicht.

6. x Github & StackOverflow Gucken wir doch mal andere Quellen an. Mein Lieblings-Popularitätskontest ist Redmonk, weil er nicht wie Tiobe auf dem Google Dance beruht, sondern schlicht die Anzahlen auf Stackoverﬂow und Github zählt. Und da ist PHP oben rechts zu sehen.

7. x Github & StackOverflow Faktisch beﬁndet sich PHP in der Redmond-Bewertung des vergangenen Quartals auf Platz 3. Und guck: kein Cold Fusion. Aber PHP trotzdem vorne.

8. x http://stackoverﬂow.com/research/developer-survey-2016 Most Popular Wenn man sich den Developer-Survey von Stackoverﬂow anschaut, dann sieht das etwas anders aus. Es kommt zwar wieder JavaScript als erstes, aber PHP wurde hier von SQL und C# überholt.

9. x Tiobe Index Wenn man sich den aktuellen Tiobe-Index anschaut, dann rutscht PHP noch weiter nach unten - nämlich auf Platz 7 - im letzten Jahr war es noch auf Platz 6, vor einigen Jahren lange Zeit auf Platz 3.

10. x Tiobe Index Das zeigt auch die Prozentzahl der Tiobe-Marktforschung. Von mehr als 10% des Marktes sind wir auf nunmehr etwas über 5% gerutscht. Die Ursache ist oﬀensichtlich - es gibt inzwischen viele Alternativen, 2006 sah das nicht so aus. Und nicht nur das, es gibt inzwischen ziemlich viele ziemlich gute Alternativen.

11. x http://stackoverﬂow.com/research/developer-survey-2016 Most Loved Das hat sich auch unter den Entwicklern rumgesprochen, und wenn man sich die „Most Loved“ Sprachen anschaut, dann sieht man, dass man nichts sieht - PHP beﬁndet sich nicht unter den ersten 11.

12. x https://github.com/Dobiasd/programming-language-subreddits-and-their-choice-of-words Community Bei der Begeisterungsfähigkeit liegt PHP auch eher hinten. Guckt man sich die Wortnutzung auf Reddit an, dann ist nur jedes 7 Wort ein positives - bei Clojure sind die Leute bei jedem 5ten Wort begeistert.

13. x https://github.com/Dobiasd/programming-language-subreddits-and-their-choice-of-words Community Sobald man aber auf die Schimpfworte guckt, liegen wir weit vorne. Jedes 35 Wort ist ein Crap, Fuck, Hate oder Shit.

14. Der Ø-Entwickler würde eigentlich gerne etwas anderes einsetzen. Fazit: Der Durchschnittsentwickler würde heute eigentlich gerne eine andere Programmiersprache verwenden. Aber nicht nur da gibt es Probleme.

15. https://en.wikipedia.org/wiki/Gov._Stanford Wer von Ihnen hat eine Software im Einsatz, die älter als 5 Jahre ist?

16. http://www.fotocommunity.de/fotograf/peter-raudenkolb/1039860 Und wenn Sie bei Ihnen noch in Produktion ist, wieviel wird an Ihr gearbeitet? Gibt es immer noch regelmässig Updates, Veränderungen und Zusätze? Gibt es Bugs, die korrigiert werden müssen? So schlimm wir unsere Legacy-Software ﬁnden - Legacy-Software ist immer auch erfolgreiche Software. Würde sie keiner brauchen, dann wäre sie nie zu Legacy- Software geworden.

17. http://commons.wikimedia.org/wiki/ File:Berrigan_Drummond_Street_Rail_Crossing.JPG Und da kommen wir auch schon zum Problem - unsere Welt ändert sich die ganze Zeit, und während unsere Lösung für die ursprünglichen Rahmenbedingungen noch perfekt war, sieht es heute grundlegend anders aus. Und wir passen unsere Software an, damit wir sie weiterbenutzten können.

18. https://en.wikipedia.org/wiki/Road-rail_vehicle Und am Ende haben wir ein Ergebnis, dem zwar noch die ursprüngliche Intention anzusehen ist, das aber nicht 100% wie die optimale Lösung für unser aktuelles Problem aussieht.

19. Cost / Feature Die Kosten pro Feature steigen kontinuierlich Kosten Zeit Und nicht nur das beobachtet man, man beobachtet auch, wie die Development-Performance kontinuierlich sinkt.

20. Junge Applikationen Recherche ist preiswert => Umsetzung auch Aber warum ist das der Fall? In einer jungen Applikation gibt es nur wenig Komponten, die genau das tun, was man von ihnen erwarten würde. Wenn ich eine Änderung mache - hier blau - mache ich sie einfach. Die tangierten Komponenten - rot - sind bekannt - grün - also kostet mich die Recherche wenig.

21. Alte Applikationen Recherche ist teuer => Umsetzung auch Bei alten Applikationen sieht das ganze deutlich anders aus. Hier wurde viel angepasst, und viel ursprüngliche Funktion hat sich in der zwischenzeit geändet. Deshalb weiss ich weder, auf wen sich das auswirken kann - rot - noch kenne ich die möglicherweise betroffenen Komponenten gut genug um diese Entscheidung mit wenig Aufwand treffen zu können. Im Resultat investiere ich sehr viel Zeit in Recherche, überall da wo ein möglicher Impact stattfindet - rot - aber kein Knowhow vorhanden ist - also kein grün - entsteht ein Rechercheaufwand. Und weil diese Effekte über Netzwerk wirken multiplizieren sie sich - und daraus resultieren exponentiell steigende Recherchekosten.

22. „Komponente 3 ändern“ Was muss alles angefasst werden? Die Frage nach „wie lange dauert es, Komponente 3 zu ändern“ bedeutet für sie: „Welche Komponenten sind alle betroﬀen, und wieviel Arbeit steckt dahinter“. Das kann man erst dann seriös beantworten, wenn man tatsächlich alle möglicherweise betroﬀenen Komponenten angeschaut hat. Für Vorgesetzte ist das oft unverständlich „Wie kann denn das so lange dauern, Du musst doch nur Komponente 3 ändern“ :-)

23. Accidental Complexity Weniger Programmieren aber: mehr Recherche Und es gibt nicht nur die Komplexität, die durch den Businesscase selbst eingeführt wurde. Wir ITler neigen dazu, selbst Komplexität zu erzeugen. Wir führen Generalisierungen ein, die am Ende mehr Aufwand kosten als dass sie nutzen bringen, wir schreiben Code, der zwar Schreibarbeit spart, aber Recherchenaufwand erzeugt.

24. Wissen in der Applikation Es ﬁnden sich drei Sorten Wissen in der Applikation Code Welchen Code gibt es,   wie hängt er zusammen? Features Welche Features gibt es? Motivation Warum gibt es dieses Feature/  diesen Code? Damit haben wir drei Sorten von fehlenden Knowledge in der Applikation - den Code selbst, die sich dahinter verbergenden Features, und die Motivation, warum es so ist, wie es ist. Und beim dritten Punkt handelt es sich sogar um unbekannte Unbekannte, ich weiß also dort noch nicht einmal genau, was ich alles nicht weiß. Es kann sein, dass ein Feature längst nicht mehr gebraucht wird. Es kann sein, dass eine Softwarestruktur völlig unnötig geworden ist.

25. Wer von Ihnen ist Software-Entwickler? Wer von Euch ist Software-Entwickler?

26. Zeitinvestment bei Softwareentwicklung Im Mittel über die Software Lifetime, Quelle: Microsoft Neuer Code Bestehenden Code ändern Analyse von bestehendem Code Software-Durchleser Schaut man sich die Zeitverwendung in Softwareprojekten an, dann sind wir in Wahrheit Software-Durchleser, nicht Software-Entwickler. Wir schreiben nur 2% unserer Zeit neuen Code. Die meiste Zeit - fast 80% - verbringen wir mit dem Lesen von Code. Immerhin 20% unserer Zeit verbringen wir noch mit der Modiﬁkation bestehender Software.

27. Die Wissenschaft vom Lesen von Code, den eigentlich keiner Lesen möchte. Wenn man es ebenso genau wie zynisch betrachtet verbringen wir also unsere Zeit damit, Code zu lesen, den wir eigentlich gar nicht lesen wollten. Aber ich gehöre ja auch dazu, ich hatte ja schon erwähnt, dass ich das ganz schön lange mache.

28. (In Wahrheit   debugge ich gerne :-) ) In Wahrheit gibt es aber auch Code, den ich gerne debugge, das hat dann fast etwas von Archäologie.

29. PHP Cowboy Coding Age 1995-2005 Phpnuke, Postnuke,   Drupal, Wordpress Wer kann sich noch an PHP3 erinnern? In dieser Zeit entstanden Lösungen wie PHPnuke, Postnuke, Drupal, Wordpress, osCommerce und viele andere, die bis heute laufen und das Rückenmark des Internets stellen.

30. • zum Teil objektorientiert • keine Design Patterns • Viel Not-Invented-Here • Accidental Complexity hoch • Einarbeitung zäh • schnell! • Kündigungsschutz++ Diese Lösungen waren zum Teil objektorientiert, hatten damals noch keine Design-Patterns, wenig Libraries und viel eigene Lösungen. Heute ist die Einarbeitung zäh, weil man so viele eigene Regeln befolgen muss. Aber - sie Antworten erstaunlich schnell, meist deutlich schneller als eine frische Symfony-Applikation. Und wenn man sich mal mit einer auskennt die noch gebraucht wird, dann kommt das einem Kündigungsschutz gleich.

31. PHP Cowboy Coding Age   Wer war dabei? Ich habe 1998 mit PHP 3 angefangen. Die erste Applikation, ein Katalogsystem, habe ich in 3 Tagen geschrieben. Und zwar Mit Spaghetti SQL in Spaghetti PHP in Spaghetti HTML. Aber: ein komplettes Katalogsystem mit Backend, Nutzerverwaltung und Suche, in 3 Tagen - das ist schon cool. Wer von Euch war noch dabei? Wer hat heute noch solche Applikationen im Einsatz?

32. ‚Struts/Rails’ MVC Age 2005–2011 Zend Framework,  CakePHP, Code Igniter Und damit die vernünftig Programmieren konnte, hat Zend für sie das Zend Framework gebaut, andere haben wie CakePHP Rails nachgebaut.

33. • 100% OO und Design-Pattern • Schnelle Einarbeitung • Langsamer! • Wartbarkeit ok • Accidental Complexity ok • Kündigungsschutz— Damit konnte man PHP praktisch so nutzen wie viele andere Sprachen auch, und die Vorhersehbarkeit und Nachvollziehbarkeit von Code wurde deutlich besser. Ich freue mich bis heute, wenn ich in einer technischen Bewertung Zend Framework 1-Code bekommen, weil ich einfach genau weiss, wo was wohnt. Auf einmal wurden wir aber deutlich langsamer in den Requests. Und man konnte uns kündigen, weil andere meist noch am gleichen Tag Bugs in der Software ﬁxen konnten.

34. ‚Struts/Rails’ MVC Age Wer war/ist dabei? Wer von Euch hat an so einer Software mitgearbeitet? Wer arbeitet heute noch mit so einer Software? Wer hat solche Software noch im Betrieb?

35. PHP ‚Springy’ DI Age 2011 ff Symfony 2, Zend Framework 2 Nachdem wir alle Ideen von Struts geklaut hatten, und es ganz gut funktioniert hat - warum sollte man nicht das gleiche bei Spring machen? In Folge wurde die nächste Generation Frameworks geschaﬀen, die auf DI-Konzepte aufgesetzt haben. Und während Laravel etwas von beidem ist, sind Symfony 2 und Zend Framework 2 gut in dieser Kategorie einzuordnen.

36. • OO, Design-Pattern & DI • Gute Einarbeitung • Responsivität schlechter • Wartbarkeit gut • Accidental Complexity Mittel • Kündigungsschutz- - Da war jetzt nicht nur gute Objektorientierung und Design-Pattern, es ware auch eine gute modulier Zerlegung und Testbarkeit über DI möglich. Und auf einmal konnten sich nicht nur PHP-Entwickler, sondern auch Leute mit Java-Background schnell in PHP-Plattformen zurechtﬁnden. Die Wartbarkeit war gut, die Komplexität im griﬀ, und man ist immer noch gut ersetzbar.

37. PHP ‚Springy’ DI Age Wer ist dabei? Bei uns bei Mayﬂower ist das der Gros der PHP-Welt. Wer arbeitet mit so einer Applikation?

38. PHP ‚Hybrid’ Age 2015 ff PHP +   node.js + … etc Das nächste bleibt noch abzuwarten. Bei uns ist aber zu sehen, dass der Datenbank- wie Sprachzoo deutlich grösser geworden ist, und einem leicht 5-10 Plattformen aus der Tüte fallen, wann man die Software installieren möchte.

39. Wenn ich eine Symfony2- Lösung habe, muss ich die überhaupt modernisieren? Die meisten hier im Raum werden sich jetzt vermutlich die Frage stellen: warum erwähnt der Johann um Himmels willen Symfony-DI-Lösungen? Die müssen doch auf gar keinen Fall modernisiert werden?

40. Todsicher. Kosten Zeit Max(Benefit)/Feature Ich hatte es vorhin schon mit der Accidental Complexity schon einmal auf dem Schirm - es ist keine Frage von Der Basisplattform, sondern eine von Wartbarkeit. Wenn die Wartbarkeit meiner Software abnimmt, dann gibt es immer weniger Features oder Bugfixes, die den Aufwand der Umsetzung tatsächlich lohnen - und wenn ich die Linie des maximale Wertes überschritten habe ist meine Software offiziell tot - denn es lohnt sich nicht, irgendetwas an Ihr zu ändern.

41. Kosten Zeit Max(Beneﬁt)/Feature Cowboy PHP MVC PHP DI PHP Und um so näher ich dieser Linie komme, um so wichtiger wird es für mich, die Software zu modernisieren - oder abzulösen. Und während dieser Ablösedruck bei den Cowboy-PHP-Anwendungen hoch ist, ist es bei den MVC-basierten PHP-Plattformen meist noch gut zu ertragen, und bei den DI-basierten Lösungen.

42. Weg mit der alten! Was muss ich bei der Wahl der neuen beachten? Also: weg mit der alten Lösung. Aber: was mache ich statt dessen? Welche Faktoren muss ich bei der Auswahl der neuen Software beachten? Typischerweise berücksichtig man bei der Wahl der Architektur die funktionalen und die nonfunktionalen Anforderungen von Software, wie sie zB in den Qualitätskriterien der ISO 9126 dokumentiert sind. Meiner Erfahrung nach sind das bei Modernisierungen andere, und deshalb liste ich die hier auf :-)

43. Marktfaktoren 1. aktueller Featuredruck 2. zukünftiger Featuredruck 3. erwartete Lebenszeit Backbone? Angular 1 anyone? Wie gut ist die neue Software bei der Lieferung von neuen Features, wenn ich jetzt damit beginne? Wie verhält sie sich in Zukunft dabei? Wird sie genauso wieder langsam und zäh, wie die aktuelle Lösung? Und was ist die erwartete Lebenszeit? Hat jemand hier noch Backbone im Einsatz? Angular 1? Genau, wir haben weniger Zeit, unsere Software zu verzinsen.

44. Marktfaktoren 4. Cost of Delay 5. Kostenrisiko 6. Vendor-Lock-in 7. Austauschbarkeit Oft geht man bei einem Rewrite in eine Feature-Freeze - kann ich mir das überhaupt leisten, eine weile weniger Features zu liefern? Viele Rewrites scheitern oder überziehen ihr Budget deutlich, kann ich mir das als Firma leisten? Hole ich mir einen Vendor-Lock-in ins Haus? Zb AWS, Apache Beanstalk, Lambda oder die Google Container Engine? Hat jemand von Euch parse.com eingesetzt? Was passiert, wenn der Vendor auf einmal vom Markt veschwindet?

45. Entwicklermarkt 8. Verfügbarkeit heute 9. Verfügbarkeit zukünftig 10.Kompetenzlevel 11.Attraktivität „Wer für neue Technologie kommt geht auch für neue Technologie.“ Und natürlich kennen wir alle den größten Kostenfaktor - die Entwickler. Wie viele ﬁnde ich heute für die neue Plattform? Wie sieht das in Zukunft aus? Finde ich Leute mit guter Kompetenz auf der Plattform? Wie Attraktiv ist die Plattform für Entwickler? Kommen die dann gerne zu mir? Ein Freund von mir sagt gerne: wer für die hippe Technologie kommt geht auch wegen anderer hipper Technologie.

46. Meine Software 12.Größe des Projektes 13.Komplexität 14.Domain-Wissen 15.Spezialisierung 16.Interagierende Systeme Und natürlich sollte die neue Plattform der Größe meines Projektes angemessen sein. Welche Komplexität muss ich abbilden können? Wie viel Domainwissen steckt in meiner Software (das ist in der Regel schlecht dokumentiert :-) ) ? Wieviel spezielle Algorithmen, wieviel besondere Funktionalität ist enthalten? Mit welchen Schnittstellen muss sie interagieren können? Brauchen wir Datenbankinterfaces?

47. Meine Organisation 17.Teamgrösse 18.Vorhandene Kompetenzen 19.Skill-Level 20.Fähigkeiten in Betrieb 21.Fähigkeiten in Product Management Wie gross ist mein Team? Brauche ich eine Lösung, bei der sich 6 Leute synchronisieren müssen oder 150? Welche Kompetenzen habe ich jetzt im Team? Welche Sprachen können die, sind funktionale Programmierung bekannt, besteht DevOps-Kompetenz, kennen die sich schon mit Verteilten Systemen aus? Wenn das CAP-Theorem nicht bekannt ist kann man mit Schwierigkeiten rechnen, wenn man zu MicroServices wechseln möchte :-) Wie fähig sind wir im Betrieb von Plattformen? Können wir Infrastructure as Code, können wir AWS, können wir Continuous Deployment, können wir Mesos oder Kubernetes betreiben? Wie gut läuft die Kooperation, auch in Richtung auf das Product Management? Arbeiten die im gleiche Raum zusammen oder ist das eine ganz andere Abteilung in meinem Unternehmen?

48. Technische   Anforderungen 22.Reifegrad 23.Zukunftstauglichkeit 24.Erlernbarkeit 25.Ressourcenbedarf 26.Skalierbarkeit Wie reif ist die neue Lösung? Eher Java-8-reif oder NPM-Package-JavaScript-Reif? Wird sie in 2 Jahren noch existieren, gibt es LTS-Versionen? Wie gut ist sie zu lernen, gibt es Erfahrungen, Tutorials, Trainings? Was sind Ihre Anforderungen an die Aussenwelt? Wie gut skaliert sie? Wie aufwändig ist es, sie zu skalieren?

49. Ecosystem 27.Libraries / Components 28.Tooling 29.Community 30.Integrierbarkeit Und, nicht zuletzt - wie sieht das Ecosystem aus? Gibt es Libraries / Komponenten für viele Problemstellungen? Wie gut ist der Tooling-Support? Achtung: das gilt nicht nur für die Dinge von denen ich schon weiß, dass ich sie brauche, sondern vor allem für die Dinge, von denen ich das noch nicht weiß. Wie gut ist die Community? Sind viele Probleme schon gelöst und dokumentiert? Wie oft kann ich einfach von Stack Overﬂow copypasten an stelle es selbst zu programmieren? Wie gut ist die Software integrierbar in andere Ecosysteme, die bei mir bereits laufen?

50. Alle Faktoren sind relevant. Und das gemeine daran ist, man muss tatsächlich alle diese Faktoren im Auge behalten, wenn man Architekturentscheidungen zugunsten oder gegen eine Legacy- Plattform triﬀt.

51. Marktfaktoren 1. aktueller Featuredruck 2. zukünftiger Featuredruck 3. Erwartete Lebenszeit 1. aktueller Featuredruck Die Businessseite sieht meistens nur diesen Punkt.

52. Entwicklermarkt 8. Verfügbarkeit heute 9. Verfügbarkeit zukünftig 10.Kompetenzlevel 11.Attraktivität11.Attraktivität Und wir Entwickler sehen meist nur diesen :-)

53. x http://stackoverﬂow.com/research/developer-survey-2016 Attraktivität Und das ist ein Problem. Ich nehme noch mal den Survey von vorhin, auf dem die beliebtesten Sprachen geführt wurden. Ganz oben auf der Liste stehen - und ich muss sagen, zurecht - Rust, Swift, F#, Scala und Go.

54. Sprache Entwickler Jobangebote Rust 13 1 Swift 351 46 F# 24 2 Scala 286 20 Go 40 3 Java 10000+ 1188 PHP 4031 461 JavaScript 3488 393 C#.net 1812 128 Attraktivität @ München Schaut man sich das mal konkret in XING für München an dann sieht man recht schnell, welches Problem man hätte, wenn man die Plattform einsetzt. Es gibt ganze 13 Leute, die tatsächlich Rust anbieten, und 1 Jobangebot, das auf Rust fokussiert. Swift gibt es etwas mehr, dito Scala. Aber faktisch sind wir weit weg von den Dimensionen, in denen zB Java, PHP, JavaScript oder C# zu ﬁnden ist.

55. Wenn man das als Entwickler sieht sagt man natürlich: Hey, das ist ja nur, weil das gerade erst anfängt, warte mal ab, das wird sich ziemlich schnell durchsetzen. Hey, es ist ganz vorne in der Entwicklerpopularität! Klar, dass dann auch viele Firmen aufspringen!

56. OK, aber was mache ich dann? … aber nur laaaaaangsam.  Popularität @ Redmonk So richtig schnell geht das nicht mit der Adaption. Das passiert noch nicht mal bei OpenSource- und Hobby-Projekte. Guckt man sich die Statistik bei Redmond an, dann ist der letzte relevante Wechsel seit 2014 der Austausch von Swift (grün) und ObjectiveC gewesen.

57. Ok, und was bleibt mir   da übrig? Also: so schnell geht das nicht. Wir müssen oﬀensichtlich mit den Sprachen arbeiten, für die es ein bisschen Verbreitung gibt.

58. s 1. PHP 2. JavaScript 3. Java 4. Python 5. Ruby 6. Golang 7. Scala Realistische Plattformen Wenn man die Sprachen mit Hilfe von Tiobe, Redmonk, StackOverﬂow und Xing ausdünnt, dann bleiben etwa diese 10 Sprachen übrig.

59. Hey, da fehlt Rust! Und Elixir! Und $personalToyLanguage! Und selbst wenn sich das komplette Entwicklerteam freiwillig meldet, und sagt: Wir haben beschlossen dass wir jetzt alle Rust lernen! Oder Elixir, oder ELM!

60. 0 200000 400000 600000 800000 Java PHP Rust Elixir Repositories Users EcoSystem @ github.com Dann hilft das auch noch nicht wirklich weiter, weil sich das Ecosystem ebenfalls in Abhängigkeit zur Popularität verhält. Ich habe hier mal die Zahlen von Java und PHP denen von Rust und Elixir entgegen gestellt.

61. Aber es gibt alles, was wir brauchen in der Sprache! Von Entwickler-Seite hört man dann gerne das Argument: Hey, es ist aber alles enthalten, was wir brauchen. Guck mal, das MicroService-Framework und die beiden Libraries, da ist praktisch alle unsere Anforderungen drin.

62. Aber nicht die Sachen, von denen Du noch nicht weißt, dass Du sie brauchen wirst. (Statistisch gesehen) Das gemeine ist aber: bei einem kleinen EcoSystem sind vermutlich die Dinge, von denen wir noch nicht wissen, dass wir sie brauchen werden, enthalten. Unknown Unknowns ﬁndet man nur da woe schon viel ist, wo die Wahrscheinlichkeit hoch ist, dass andere Leute nicht nur schon das Problem hatten, was wir haben werden, sondern auch gleich Ihre Lösung auf Github gestellt haben.

63. s 1. PHP 2. JavaScript 3. Java 4. Python 5. Ruby 6. Golang 7. Scala Realistische Plattformen Also bleiben wir bei dieser Auswahl, ich glaube, die gibt den Zustand Ende 2016 ganz passabel wieder.

64. Sprache Umlernen EcoSystem Entwickler Reifegrad Zukunft DevLove PHP JavaScript Java Python Ruby GoLang Scala Welche Sprache als nächstes? Wenn ich von einer PHP-Applikation komme, sind meistens zwei Sprachen sehr einfach einzusetzen: PHP und JavaScript, weil ich das ohnehin im Browser schon eingesetzt habe. Java, Python, Ruby und Golang sind unserer Erfahrung nach ziemlich schnell zu lernen, bei Scala wird es etwas langsamer, das ist unserer normalen Sprachwelt nicht nahe genug. Wenn ich wenig Zeit zum Lernen neuer Sprachen habe bin ich also gezwungen mit PHP oder JavaScript weiterzumachen.

65. Sprache Umlernen EcoSystem Entwickler Reifegrad Zukunft DevLove PHP JavaScript Java Python Ruby GoLang Scala Und das Ecosystem? Nächster Punkt ist das EcoSystem. Bei PHP, JavaScript, Java, Python und Ruby gibt es für praktisch alle Zwecke Libraries - im konkreten Fall mehr als sechsstellige Repositories - bei Golang und Scala sind wir jeweils in den 20-Tausendern unterwegs.

66. Sprache Umlernen EcoSystem Entwickler Reifegrad Zukunft DevLove PHP JavaScript Java Python Ruby GoLang Scala Gibt es Entwickler? Entwickler-Verfügbarkeit, hier am Beispiel in München - bei PHP, Javascript, Java und Python 4 stellige Entwicklerzahl, bei Ruby immerhin noch 3stellig, bei Golang und Scala nur 2stellig. Also: so richtig viel Angebot an Entwicklern ist nicht vorhanden.

67. Sprache Umlernen EcoSystem Entwickler Reifegrad Zukunft DevLove PHP JavaScript Java Python Ruby GoLang Scala Wie reif/stabil ist das? Das ist jetzt mehr daumengepeilt und aus unserer eigenen Erfahrung - aber: während man bei PHP, Java, Python und Ruby halbwegs zurecht kommt gibt es bei den APIs in der JavaScript-, in der Golang und in der Scala-Welt noch gelegentliche Probleme. Aber das ist eher Anecdotal Evidence, ich habe keinen Weg gefunden, das mit richtigen Daten zu hinterlegen. Ich würde mich über Input freuen :-)

68. Sprache Umlernen EcoSystem Entwickler Reifegrad Zukunft DevLove PHP JavaScript Java Python Ruby GoLang Scala Wie sieht die Lebenszeit aus? Die Zukunft habe ich über die Marktdurchdringung und Wachstumsraten bzw. Bedeutungsverlust bewertet. PHP hat immer noch eine gute Verbreitung, sinkt aber kontinuierlich. Javascript ist weiterhin im Aufwärtstrend. Java hat mit Java 8 den Abwärtstrend etwas gefangen. Python steigt kontinuerlich, Ruby lässt etwas nach, Golang steigt, Scala sinkt etwas

69. Sprache Umlernen EcoSystem Entwickler Reifegrad Zukunft DevLove PHP JavaScript Java Python Ruby GoLang Scala Und die Devs? Mögen die das? Und Last but noch least - Developer Support. Die Beliebgheit hatten wir schon, weder PHP, noch Java, noch Ruby ﬁnden sich da auf den Top-Plätzen

70. „Should I stay or should I go now? Should I stay or should I go now? If I go there will be trouble An’ if I stay it will be double„ Und was machen wir jetzt mit der Frage, die the Clash so schön formuliert? Should i stay or should i go? Und klar haben sie recht mit der Ansage, dass eine neue Plattform Trouble bringen wird. Und sie haben meist auch recht, dass das verbleiben bei der Legacy-Software auf jeden Fall schlimmer ist.

71. Sanieren: Captain Obvious Strategie Migration nach Symfony 2/3 Ausgangspunkt Cowboy-Style / MVC-Style PHP Hoher Technical Debt  Motivation „Moderne“ Plattform, Innovationsfähigkeit, Domain-Wissen & Kollegen halten Probleme und Risiken PHP-Lock-In, Fluktuation bei hohen Skills, Schwierige Talent Acquisition Typische Antipattern Multiple Layers of Legacy,   „Tote Modernisierungen“ Voraussetzung zum Erfolg Support & Budget von Business-Seite  Infrastruktur zum Knowhowaufbau Das ist die heute meist oﬀensichtlichste Lösung - ich migriere auf eine nicht-Legacy-PHP-Variante. Meist mache ich das, wenn ich alte Cowboy-Style oder MVC-Style- PHP-Apps habe, mit einem hohen Technical Debt.

72. 1. aktueller Featuredruck 2. zukünftiger Featuredruck 3. Erwartete Lebenszeit 1. aktueller Featuredruck Alle neuen Features & Projekte auf die neue Plattform! Multiple Layers of Legacy Der Punkt ist aber: ich bin bei dieser ﬁesen Software gelandet, weil der Featuredruck so hoch war. Und wenn ich nicht ein neues Business bekommen habe, dann ist das noch immer so. Und da kommt immer die clevere Idee: Hey, lass uns doch nur die neuen Features & Projekte mit der neuen Plattform machen! Und wir behalten die alte Plattform!

73. Ursprüngliche Features,   Architektur 1 Neue Features/  Architektur 2 Multiple Layers of Legacy Und so kommt zu der alten Architektur eine zweite, neuere und bessere. Und weil der Featuredruck so hoch ist komme ich nicht dazu, die Architektur 1 zu renovieren.

74. Ursprüngliche Features,   Architektur 1 Neue Features/  Architektur 2 Neue Features/   Architektur 3 Multiple Layers of Legacy Und nach zwei Jahren ist auch Architektur 2 nicht mehr das, was man möchte. Also fängt man bei den neuen Features mit Architektur 3 an. Und kommt irgendwie nicht dazu, Architektur 1 zu refactoren. Und Architektur 2, aber die ist ja auch noch fast neu.

75. Neue Features/  Architektur 2 Neue Features/   Architektur 3 Neue Features/   Architektur 4 Multiple Layers of Legacy Ursprüngliche Features,   Architektur 1 Und weil der Featuredruck immer noch erhalten bleibt, und wir nicht genug Manpower zum Refactoring haben, machen wir einfach beim nächsten neuen Feature wieder die Architektur, die heute angesagt ist. Und so enden wir durch kontinuierliche Innovation und Modernisierung bei einer Software, die deutlich schlechter zu warten ist als wenn wir nur bei Architektur 1 geblieben wären.

76. Domain Driven Design Strategie Migration nach Symfony 2/3+DDD Ausgangspunkt Cowboy-Style / MVC-Style PHP Hoher Technical Debt, hohe Komplexität Motivation Wartbarkeit! Saubere Architektur,   Talent Acquisition, Disziplinierung Business Probleme und Risiken Organisatorische Gründe für Technical Debt, Developer-Fähigkeiten Typische Antipattern DDD-Lite Voraussetzung zum Erfolg Support & Budget von Business-Seite  Knowhow für Business & Development Eine weitere Modernisierungsvariante ist die Modernisierung in Richtung DDD. Das ist in der PHP-Welt mit etwas Verspätung eingeschlagen, und wurde vor allem in den letzten 3-4 Jahren viel diskutiert. Meist geht das einher mit einer Modernisierung in Richtung Symfony, insbesondere dann, wenn die Komplexität der Anwendung hoch ist - oder für hoch gehalten wird.

77. Alle Tactical Patterns, Ubiquitous Language,  Bounded Contexts & Context Maps sind da. Aber nur die   Entwickler kennen sie. DDD-Lite Gerade weil das in unserer Welt meist von den Techies getrieben wird kommt es bei uns oft zu DDD-lite. Wir lieben Design Pattern, und deshalb lieben wir auch die Tactical Patterns, die Eric Evans und Co uns gegeben haben. Und wir vergessen die ganze Businessseite dabei. In Folge hat Domains, Entitäten und Value Objects, die sich ganz anders verhalten als die Realität. Mit der Folge, dass mein Domain Model hässlich wird.

78. MicroService Monokultur Strategie MicroServices mit Standard-Stack Ausgangspunkt Cowboy/  MVC/DI-Age PHP-Applikation Motivation Skalieren über Teams, bessere Wartbarkeit, Skalierbarkeit, Robustheit, Sprachwechsel Probleme und Risiken Komplexität, Cohesion Chaos, Layered Services, Missing Automation Typische Antipattern Distributed Monolith Voraussetzung zum Erfolg Automatisierung in Knowhow & Infrastruktur: Monitoring, QA, Deployment Die aktuelle Kuh im Dorf ist auch bei uns aber nicht mehr DDD, sondern wie überall MicroService. Dort sieht man zwei Strategien, und ich stelle hier mal die erste vor - die MicroService Monokultur. Auch wenn die Flexibilität über Plattformen einer der Kernvorteile von MicroServices ist passiert das in der Praxis häuﬁger als man denkt - insbesondere da, wo die Entscheidung zu MicroServices zentral getrieben wurde, zB von CTO oder Architektenrunde. Probleme sind fehlende Automatisierung, und wenn die Entwickler alle vom Monolithen kommen - das Neudesign eines Monolithens, jetzt nur mit Funktionsaufrufen über HTTP und Queues.

79. „If you can’t build a well- structured monolith, what makes you think you can build a well-structured set of microservices?“ http://www.codingthearchitecture.com/2014/07/06/ distributed_big_balls_of_mud.html Richtig populär wurde das mit seinem Monolith First Pattern durch Martin Fowler, aber aus diesem Blogartikel stammt das: Wenn man schon nicht in der Lage war einen gut strukturierten Monolithen zu machen, wie kann man dann glauben, dass es mit einer verteilten Applikation klappt?

80. MicroServices Strategie MicroServices mit freier Stack-Wahl, Container Ausgangspunkt MVC/DI-Age PHP-Applikation Motivation Skalieren über Teams, bessere Wartbarkeit, Skalierbarkeit, Robustheit, Sprachwechsel Probleme und Risiken Komplexität, Cohesion Chaos,   Missing Automation Typische Antipattern MicroService Snowﬂakes Voraussetzung zum Erfolg Automatisierung in Knowhow & Infrastruktur: Monitoring, QA, Deployment Das sieht man im Moment eher bei den ganz grossen - oder bei den ganz kleinen, startuppigen PHP-Businesses - klassische MicroServices. Meist ist die technische Strategie da nur das stellen der Plattform - und die Teams bauen selbst die Mikroservices nach Ihrer Facon. Besonders Firmen mit dickem Innovationsdruck wollen heute gerne sowas - und sind quasi zum Scheitern verdammt, denn die Anforderungen in Agilen Methoden, in DevOps-Automatisierung oder Amazon-Knowhow sind gross.

81. Und was mache ich jetzt?  • Captain Obvious • Domain Driven Design • MicroService Monokultur • MicroServices (Faustformeln to come) Und natürlich gibt es noch mehr Varianten. Nano und Pico-Services, Serverless Applications, Backend as a Service und vieles mehr. Das hier sind nur die 4 Variante, die am häuﬁgsten zu sehen sind.

82. Wann Captain Obvious /   PHP Monolith in gut • Weniger als 15 Entwickler • Weil das Core-Team PHP kann und uns treu ist • Weil die Komplexität ok geht (CMS, E-Commerce) Wann mache ich Captain Obvious?

83. Domain Driven Design • Weil wir DDD-Experten in Dev & Business haben • komplexer & eng verzahnter / optimierter Businesscase • nachhaltige Wartbarkeit

84. MicroServices Monokultur • >20 Entwickler im Team • parallele & schnelle Entwicklung erforderlich • gute Ops / Cloud / Monitoring/QA-Struktur • zentrale Org-Struktur

85. MicroServices • Maturity Agil & DevOps • CI, CD, QA, Monitoring, Cloud, IaC, AWS Management gut im Griff • Crossfunktionale Teams

86. Architecture TradeOff Analysis Method   Strategieauswahl auf Basis der mittelfristigen   Businessanforderungen Und wie komme ich zu der neuen Architektur? Wir machen das gerne über einen ATAM - Workshop. ATAM ist die Architecture Tradeoﬀ Analysis Method, und ist eigentlich ein Risikomanagementtool. Weil das Risiko bei Modernisierungen hoch ist bietet sich das Verfahren an. Was macht man da? Man dokumentiert die Mittelfristigen Businessanforderungen in Szenarien, priorisiert sie und bewertet die Architekturvarianten, die einem zur Wahl stehen. Und am Ende kommt eine Decision Matrix nicht nur mit einer Empfehlung, sondern auch mit einem Tradeoﬀ - also den Dingen, die man nicht bekommen wird - heraus.

87. Und dann klappt es?

88. Selten wie geplant , es ist praktisch immer teurer

89. Modernization Burndown Allen Scope erfassen - wir machen das meist mit einem Story-Mapping über die bestehende Software - und prüfen, wie weit man die Migration bekommen hat, und wie weit man den alten Kram schon wegwerfen konnte. Am besten allen Code physikalisch entfernen, den man nicht mehr braucht. Das ist quasi die einzig valide Deﬁnition of Done einer Modernisierung :-)

90. Manpower vs. Tempo Entweder 1.5-2facher Produktivitätsverlust oder 1.5-2facher Aufwand   für Entwicklung & Knowhowaufbau. Und man sollte ankündigen, dass es teurer wird. Eine gute Schätzung ist Faktor 1.5 bis 2, wenn man es gut im Griﬀ hat. Wer kennt Hofstaedters Law? Genau, es dauert länger. Auch wenn man einplant, dass es länger dauert.

91. Kontinuierliche Modernisierung • Parallelbetrieb hinter Proxy • Parallelbetrieb über   Feature Toggles • Absicherung über   Acceptance-Tests Das haben wir schon gemacht, das hilft auch. Bevor ich modernisiere etabliere ich einen Gateway oder einen Proxy vor der Applikation, und migriere anhand von Proxy- Routen. Oder ich nutze Feature-Toggles, um bei manchen Nutzern die neue, bei machen die alte Software auszuliefern. Wenn ich nicht in Produktion testen möchte kann ich das vorher durch Akzeptanztests absichern. Das ist praktisch der einzige Weg zu echtem Risikomanagement.

92. Infrastruktur zum Knowhowaufbau • Team-Rotation Legacy vs. Neu • Slack time & Lightning Talks • Pair Programming,  Coding Dojos • Training on the job Wir hatten es am Anfang - ich brauche sowohl das Domain-Knowhow als auch die Technologiekompetenz bei den Entwicklern. Das ist oﬀensichtlich mehr Knowhow während einer Modernisierung, denn ich habe jetzt zwei Plattformen zu verstehen. Diese Methoden helfen dabei.

93. Too long, didn’t listen 1 Soll ich weiter PHP machen? PHP wird es dank CMS- und E- Commerce-Plattformen noch lange geben. Aber immer weniger Developer, die es mögen. Wem das einfach zu viel Kram war, hier noch mal ein paar wichtige Aussagen. Also: kann ich noch PHP machen? Ja, das ist hinreichend verbreitet, das wird es noch lange geben.

94. Too long, didn’t listen 2 Muss ich jetzt MicroServices? Wenn Ihr Agil, DevOps könnt, viele seid und parallel arbeiten wollt - ja, klar. Muss ich jetzt MicroServices machen? Wenn ich es kann und brauche, dann ja :-) Aber es gibt nicht viele PHP-Firmen, die das wirklich gut können. Eher die grossen.

95. Too long, didn’t listen 3 Auch PHP und MicroServices? Klar, das ist ja quasi der Punkt hinter MicroServices. Da, wo es Sinn macht.

96. Too long, didn’t listen 4 Sonst noch was? Es wird aufwendiger als erwartet.

97. Danke! Fragen? Slides mit Volltext:   slideshare.net/johannhartmann Oder: draussen am Stand :-)

Legacy php - Sanieren oder Ablösen?

Vous êtes en train de lire un aperçu.

Consultez-les par la suite

Legacy php - Sanieren oder Ablösen?

Plus De Contenu Connexe

Diaporamas pour vous (19)

Similaire à Legacy php - Sanieren oder Ablösen? (20)

Plus par Johann-Peter Hartmann (11)

Plus récents (20)