Softwaredurchleser statt Softwareentwickler

PHP-Legacy-Projekte sanieren oder ablösen?
Kommentare

Viele PHP-Entwickler kennen die Problematik: alte PHP-Projekte, vor vielen Jahren entstanden und heute immer noch mit wichtiger Funktion im Unternehmen. Die Ratschläge, wie mit solchen Projekten umzugehen ist, sind ebenso vielfältig wie die Projekte selbst. Johann-Peter Hartmann zeigt die möglichen Optionen, Strategien, Herausforderungen und Risiken auf dem Weg zur Ablösung von Legacy-PHP-Projekten.

„Ich bin selber Legacy, ich darf über Legacy-PHP-Projekte reden!“ So eröffnete Johann-Peter Hartmann, CTO von Mayflower, seine Session „Legacy-PHP-Projekte – sanieren oder ablösen?“ auf der International PHP Conference 2016.  Schaut man die gängigen Statistiken, Zahlen und Erhebungen an, die regelmäßig analysiert und veröffentlicht werden – auf RedMonk, GitHub, StackOverflow & Co. – scheint es PHP eigentlich ganz gut zu gehen. Ein etwas anderes Bild zeichnet die Marktforschung von Tiobe. Von einst mehr als zehn Prozent Marktanteil kommt PHP mittlerweile nur noch auf fünf Prozent. Die Ursache, so Hartmann, ist offensichtlich: „Es gibt inzwischen viele Alternativen, 2006 sah das nicht so aus. Und nicht nur das, es gibt inzwischen ziemlich viele ziemlich gute Alternativen.“

Legacy-Software = erfolgreiche Software

Offensichtlich würden viele PHP-Entwickler inzwischen gerne eine andere Programmiersprache einsetzen. Aber das ist nur eine Seite der Medaille. Die andere: ein altes PHP-Projekt, das seinen Ursprung „vor langer Zeit“ hat, allerdings noch heute eine wichtige Funktion im Unternehmen erfüllt. Für solche Fälle gibt es selbstverständlich zahlreiche Ratschläge, wie man damit umzugehen hat. Doch egal wie furchtbar man Legacy-Software findet – offensichtlich handelt es sich um erfolgreiche Software. „Würde sie keiner brauchen, dann wäre sie schließlich nie zu Legacy-Software geworden,“ konstatiert Hartmann.

Was also tun? Denn meist steht man vor folgendem Problem: Naturgemäß hat sich die Softwarewelt in den letzten Jahren extrem verändert. Und so wie das Legacy-PHP-Projekt unter den einstigen Rahmenbedingungen eine valide Lösung darstellte, so veraltet wirkt es heute. Um es weiter im Einsatz halten zu können, muss es kontinuierlich angepasst werden. Logischerweise führt das dazu, dass man sich immer weiter von der einst validen Lösung entfernt. Was ursprünglich das Problem zu 100 Prozent gelöst hat, sieht dann nicht selten wie Stückwerk aus.

Sinkende Development-Performance

Damit einher geht ein ernstes Problem: die Development-Performance sinkt stetig. Warum? Kurz gesagt: Bei jungen Applikationen sind Recherche und Umsetzung preiswert. Bei älteren Applikationen ist es umgekehrt: Recherche und Umsetzung sind teuer, denn der Rechercheaufwand steigt und Interdependenzen müssen erkannt und beachtet werden.

Prinzipiell entstehen laut Hartmann damit drei Sorten von fehlendem Know-how in einer Applikation:

  • der Code selbst
  • die sich dahinter verbergenden Features
  • die Motivation, warum es so ist, wie es ist
johann-peter-hartmann-ipc2016

Johann-Peter Hartmann, CTO von Mayflower, während seiner Session „Legacy-PHP-Projekte – sanieren oder ablösen?“ auf der IPC 2016.

Softwaredurchleser statt Softwareentwickler

Diese Situation hat vor allem ein Ergebnis zur Folge: Man programmiert weniger, recherchiert aber mehr. „Statt Softwareentwickler sind viele von uns eher Softwaredurchleser,“ bemerkt Johann-Peter Hartmann deswegen auch treffend.

Im Durchschnitt verbringen Entwickler lediglich zwei Prozent ihrer Zeit mit dem Schreiben von neuem Code. „Die meiste Zeit – 78 Prozent – verbringen wir mit dem Lesen von Code. Immerhin 20 Prozent unserer Zeit verbringen wir noch mit der Modifikation bestehender Software.“

Neue Software muss her!

Wenn dann der Leidensdruck irgendwann zu hoch wird und die Entscheidung für die Ablösung eines Legacy-Projekts gefallen ist, stellt sich die wichtige Frage: Welche Faktoren sollte man bei der Auswahl der neuen Software beachten?

Eine Möglichkeit wäre beispielsweise ein Blick auf die Qualitätskriterien der ISO 9126 und die darin dokumentierten funktionalen und non-funktionalen Anforderungen von Software. Doch Johann-Peter Hartmann sieht bei einer Modernisierungen andere Faktoren, die mehr Einfluss auf eine solche Entscheidung haben sollten. Als da wären (gegliedert in Gruppen):

Marktfaktoren:

  1. aktueller Featuredruck meiner Applikation
  2. zukünftiger Featuredruck
  3. erwartete Lebenszeit
  4. Cost of Delay
  5. Kostenrisiko
  6. Vendor-Lock-in
  7. Austauschbarkeit

Entwicklermarkt

  1. Verfügbarkeit heute
  2. Verfügbarkeit zukünftig
  3. Kompetenzlevel (wie gut sind die verfügbaren Entwickler?)
  4. Attraktivität (wie viele Entwickler bekomme ich am Markt?)

Meine Software

  1. Größe des Projekts
  2. Komplexität
  3. Domain-Wissen
  4. Spezialisierung
  5. Interagierende Systeme

Meine Organisation

  1. meine Teamgröße
  2. vorhandene Kompetenzen
  3. Skill-Level
  4. Fähigkeiten in Betrieb
  5. Fähigkeiten in Product Management

Technische Anforderungen

  1. Reifegrad
  2. Zukunftstauglichkeit
  3. Erlernbarkeit
  4. Ressourcenbedarf
  5. Skalierbarkeit

Ecosystem

  1. Libraries/Components
  2. Tooling
  3. Community
  4. Integrierbarkeit

30 Faktoren – eine Menge Holz! Da sind doch sicher einige Streichkandidaten oder weniger relevante Faktoren darunter? Johann-Peter Hartmanns Meinung ist jedoch eindeutig: „Alle Faktoren sind relevant! Das ist das gemeine daran: Man muss tatsächlich alle diese Faktoren im Auge behalten, wenn man Architekturentscheidungen zugunsten oder gegen eine Legacy- Plattform treffen will.“

Wahl der Programmiersprache

Klar, die Business-Seite im Unternehmen sieht meist nur Faktor 1, den aktuellen Featuredruck. Die Entwickler fokussieren hingegen meist auf Faktor 11: Attraktivität oder: Wie populär ist die zur Auswahl stehende Programmiersprache und wie viele Entwickler bekomme ich am Markt? Weil aber besonders populäre Sprachen wie Rust oder Go oft noch niedrige Adaptionsraten verzeichnen, ist man praktisch gezwungen mit den Sprachen zu arbeiten, die auch eine angemessene Verbreitung aufweisen. So bleiben dann noch die großen Sieben übrig:

  1. PHP
  2. JavaScript
  3. Java
  4. Python
  5. Ruby
  6. Golang
  7. Scala

PHP und JavaScript sind sehr einfach einzusetzen, wenn man von einer PHP-Applikation kommt. „Java, Python, Ruby und Golang sind unserer Erfahrung nach auch ziemlich schnell zu lernen, bei Scala wird es etwas langsamer, das ist unserer normalen Sprachwelt nicht nahe genug,“ erläutert Hartmann. Sind die Ressourcen knapp, ist man also in der Regel gezwungen, die Arbeit mit PHP und JavaScript fortzusetzen. Natürlich spielen auch Faktoren wie das Ökosystem (wie viele Repositories gibt es), Verfügbarkeit (wie viele Entwickler gibt es am Markt), Reifegrad (Stabilität), Lebenszeit (Zukunftssicherheit) und Entwickler-Support („Dev-Love“) eine gewichtige Rolle.

Legacy-Zwickmühle

Egal, welche Entscheidung getroffen wird: Ohne Ärger wird es nicht gehen, nicht bei einer neuen Plattform und auch nicht beim Verbleib bei der Legacy-Software. Letztere ist aber aus Hartmanns Erfahrungen in der Regel die „schmerzhaftere“ Entscheidung.

In der Folge lassen sich vier Modernisierungsansätze bzw. -strategien herausarbeiten:

  1. Sanieren
  2. Domain Driven Design
  3. Microservice Monokultur
  4. Microservice

Sanieren/Captain Obvious

Sanieren ist die „Captain Obvious“-Variante. Sind bspw. hohe technische Schulden vorhanden, migriert man auf eine „Nicht-Legacy-PHP-Variante“ wie Symfony 2/3. Dahinter stecken meist Motivationsgründe wie Innovationsfähigkeit und der Versuch, Domain-Wissen und vorhandene Kollegen zu halten. Das typische Antipattern bei dieser Strategie ist laut Hartmann jedoch das Phänomen der Multiple Layers of Legacy, sogenannte „tote Modernisierungen“: zu einer alten Architektur gesellt sich eine zweite, neuere. Weil allerdings der Featuredruck so hoch ist, schafft man es nicht, die ursprüngliche Architektur zu renovieren. Doch nach zwei Jahren passiert das gleiche mit der zweiten Architektur. Also wird für neue Features eine dritte Architektur hinzugefügt und für das Refactoring von Architektur 1 ist weiter keine Zeit. Der Teufelskreis setzt sich fort und am Ende landet man bei einem Softwaregebilde, das vermutlich schwerer zu warten ist als die Ursprungsarchitektur. Wann sollte diese Strategie eingesetzt werden? Hartmann empfiehlt sie bei Teamgrößen von weniger als 15 Entwicklern, wenn das Core-Team PHP beherrscht und „treu“ ist und wenn man mit entsprechender Komplexität zurechtkommt (bspw. im Bereich CMS, E-Commerce).

Domain Driven Design

DDD ist mit etwas Verspätung in der PHP-Welt angekommen und beschreibt meist die Strategie einer Modernisierung in Richtung Symfony 2/3 – gerade wenn die Komplexität der Anwendung hoch ist oder für hoch gehalten wird. Die Motivation dahinter ist eine gute Wartbarkeit zu erreichen, gepaart mit einer sauberen Architektur und guten Akquirierungsmöglichkeiten auf Entwicklerseite. Eine wichtige Voraussetzung für den Erfolg ist der Support und ausreichend Budget von Business-Seite sowie Knowhow für Business und Development. Als typisches Antipattern führt Johann-Peter Hartmann „DDD-Lite“ an, also den Umstand, dass sich Domains, Entitäten und Value Objects anders verhalten als die Realität. Warum? Weil die Business-Seite vor lauter Design Patterns außer Acht gelassen wird und nur die Entwickler Aspekte wie Tactical Patterns, Ubiquitous Language, Bounded Contexts und Context Maps kennen.

Der Einsatz von DDD empfiehlt sich laut Hartmann, wenn man DDD-Experten in den Entwicklungs- und Businessabteilungen hat, wenn man einen komplexen und eng verzahnten bzw. optimierten Businesscase hat und wenn nachhaltige Wartbarkeit ein wichtiger Faktor sein soll.

Microservice-Monokultur

Auch in der PHP-Welt sind Microservices ein Buzzword, sprich: in aller Munde. Für Hartmann gibt es sogar zwei auf Microservices basierende Strategieausprägungen. Die erste ist die Microservice-Monokultur. Obwohl gerade die Flexibilität über Plattformen hinweg einer der Hauptvorteile von Microservices sein soll und man sich in der Entscheidung für MS eine bessere Skalierbarkeit, bessere Wartbarkeit und Robustheit erwartet, führen fehlende Automatisierung, hohe Komplexität und viele Layered Services zu einem neuen Problem: dem Neudesign eines Monolithen. Ein solcher „Distributed Monolith“, wie ihn Hartmann nennt, basiert nur jetzt eben auf HTTP und Queues. Passend dazu das Zitat von Martin Fowler:

If you can’t build a well structured monolith, what makes you think you can build a well-structured set of microservices?

Wann also auf eine Microservices-Monokultur setzen? Laut Hartmann, wenn man Teams mit mehr als 20 Entwicklern hat, wenn eine parallele und schnelle Entwicklung gefordert ist, wenn eine gute Ops-/Cloud-/Monitoring- und QA-Struktur verfügbar ist und eine zentrale Organisationsstruktur vorhanden ist.

Microservices

Bleiben noch die klassischen Microservices. Und auch hier lässt sich Fowlers Ausspruch anbringen. Denn laut Hartmann ist meist die technische Strategie vorhanden, doch Teams bauen die Microservices nach ihrem Geschmack. Soll diese Strategie nicht zum Scheitern verdammt sein, müssen die großen Anforderungen in puncto Agiler Methoden, in DevOps-Automatisierung oder Amazon-Knowhow erfüllt sein. Hartmann empfiehlt die klassischen Microservices bei einer entsprechenden Reife in puncto Agilität und DevOps und wenn man Faktoren wie Continuous Integration, Continuous Deployment, Monitoring, Cloud, Infrastructure as Code und AWS Management gut im Griff hat. Auch crossfunktionale Teams sind ein Faktor, der für den Einsatz der Microservices-Strategie spricht.

ATAM – Architecture Tradeoff Analysis Method

Mit der ursprünglich als Risikomanagementtool konzipierten Architecture Tradeoff Analysis Method lassen sich mittelfristige Businessanforderungen in Szenarien dokumentieren. Die Szenarien werden priorisiert und die Architekturvarianten bewertet. Als Ergebnis erhält man eine Decision Matrix, die nicht nur eine Empfehlung enthält, sondern auch etwaige Tradeoffs auszeichnet.

Die Frage, ob bei Beachtung all dieser Faktoren und Ratschläge die Modernisierung klappt, beantwortet Johann-Peter Hartmann kurz und knapp: „Selten wie geplant, es ist praktisch immer teurer:“ Und selbst wenn man einplant, dass die Modernisierung länger dauert, dauert sie (trotzdem noch) länger.

Infrastruktur zum Know-how-Aufbau

Unabdingbar für den Modernisierungsprozess sind Domain-Know-how und die entsprechende Technologiekompetenz bei den Entwicklern. Denn die Modernisierung benötigt mehr Know-how, schließlich hat man zwei Plattformen zu verstehen. Folgende Methoden können dabei helfen:

  • Team-Rotation: Legacy vs Neu
  • Slack time & Lightning Talks
  • Pair Programming, Coding Dojos
  • Training on the job

Fazit

Für Johann-Peter Hartmann steht fest: PHP wird es dank CMS- und E-Commerce-Plattformen noch lange geben. Doch leider sieht es so aus, als würde es immer weniger Entwickler geben, die auf PHP setzen. Den Druck Microservices zu machen, sieht er gelassen: „Wenn ich es kann und brauche, dann ja!“ Man sollte Agile und DevOps beherrschen, die Teams müssen groß genug sein und man muss parallel arbeiten wollen. Nicht viele Unternehmen erfüllen diese Anforderungen – meist nur die großen. Die Kombination von PHP und Microservices muss schlicht und ergreifend sinnvoll sein. Und am Ende ist bei der Frage nach der Sanierung oder Ablösung von PHP-Legacy-Projekten ein wichtiger Punkt zu beachten: Es wird aufwendiger als erwartet!

Go for PHP Developers

mit Terrence Ryan (google)

Everything you need to know about PHP 7.2

mit Sebastian Bergmann (thePHP.cc)

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -