© saicle/Shutterstock.com
Umgang mit PHP-Legacy-Anwendungen

Umgang mit PHP-Legacy-Anwendungen


In den letzten Jahren konnte man sehr viel über die Kunst des Softwaretestens lesen – von einfachen Unit Tests über Test-driven Development bis hin zu Behaviour-driven Development. Einen brauchbaren Leitfaden findet man jedoch kaum. Legacy-Anwendungen zu bändigen und im Nachgang mit automatisierten Tests zu ergänzen: unbezahlbar. Auch dieser Artikel wird kaum einen allgemeingültigen Weg beschreiben, sind Legacy-Anwendungen doch sehr unterschiedlich in ihrer Natur. Vielmehr zeigt er einen möglichen Weg, der sich in der Praxis bereits bewährt hat und zeigt Probleme theoretischer Softwaredesignkonzepte im täglichen Umgang.

Legacy-Anwendungen: Wikipedia bezeichnet sie als etablierte und historisch gewachsene Anwendungen. Das historische Wachstum scheint das große Problem in der heutigen Softwareentwicklung zu sein. Oft liegt der Ursprung der Probleme aber eher an grundsätzlichen Entscheidungen zu Beginn vieler Projekte. Diese Entscheidungen können auch nicht einfach als Fehlentscheidungen abgetan werden. Zum gegebenen Zeitpunkt war es nicht zwingend die falsche Entscheidung. Wäre dem so, würde man diese Fehler heute nicht mehr machen. Aber sie kommen immer und immer wieder vor. Jeder wird sie in seiner täglichen Arbeit wiederfinden, ebenso wie im realen Leben. Entscheidungen basieren immer auf Abwägungen.

Eine dieser Entscheidungen ist es, zu Beginn eines Projekts auf Softwaretests zu verzichten. Aber worin liegen hier die Ursachen? Ein Grund ist sicherlich, dass eine heutige Legacy-Anwendung zu Beginn nicht legacy, d. h. schon gar nicht etabliert, ist. Prototypen und Quick Shoots sind der Beginn vieler Projekte, die schleichend zu einem Produktivsystem mutieren. Zumeist weil Kunden auch wenig Interesse haben, zu Beginn eines Projekts einen Mehraufwand zu bezahlen. Soll die gedachte Geschäftsidee sich doch erst mal beweisen und höhere Investitionen rechtfertigen. Moderne Design Patterns à la Dependency Injection und Co. hin oder her – einen geringeren Anfangsaufwand bescheren sie einem nur selten. Schon gar nicht, wenn auf Tests keinen Wert gelegt wird oder eine zukünftige Wartung noch nicht abzusehen ist. Den allerwenigsten Kunden ist bewusst, dass Softwarefehler niemals zu vermeiden sind. Es wird immer Fehler geben, aber wer will das schon hören?

buhmann_legacy_1.tif_fmt1.jpgAbb. 1: Magisches Dreieck

Zudem werden Projekte zu Beginn künstlich kleingerechnet. Ein sehr gutes Beispiel aus dem täglichen Leben ist Stuttgart 21. Projekte werden geplant und zu einem Mindestpreis angeboten – k...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang