Agile Strategien für das Refactoring von Legacy PHP Anwendungen
Viele Teams stehen vor der Herausforderung das Erfolgreiche Web-Anwendungen wartbar und flexibel zu halten.
Schneller Wirtschaftlicher Erfolg hat die Betreiber oft dazu gezwungen schnell viele Features Umzusetzen, was oft zu lasten der Code Qualität ging. Mit der Zeit haben sich hier die soganannten Technischen Schulden angehäuft. Der historische gewachsene Code wird zum bekannten Problem des sogenannten „Big Ball of Mud“. Feature Entwicklungen dauern lange werden somit teuer und das Team ist oftmals mit Bugfixes im beschäftigt. Eines der größten Risiken an diesem Zustand ist auf einen sich verändernden Markt nicht schnell genug reagiert werden kann.
Um nicht wie schon viele andere zeitweise Erfolgreiche Web Angebote an dieser "Feature Lähmung“ zu scheitern ist es an dieser stelle erforderlich die Entscheidung für ein Refactoring zu treffen.
Oft wird als Lösung eine komplette neue Entwicklung der Plattform angestrebt, doch gerade im benutzerabhängigen Endkunden Markt des öffentlichen Web ist dies besonders schwierig, oft ist man neben dem wohlwollen der Benutzer zudem noch auf eine effektive SEO Platzierung des eigenen Portals angewiesen. Bei kompletten neu Entwicklungen ist das Verhalten der Benutzer schwer vor raus zu sagen, oft stoßen solche Relaunches auf ablehnung bei den Stammbenutzern, gerade Communities reagieren hier zeitweise sehr empfindlich. Zudem ist oft über Monate oder Jahre hinweg eine Parallel Entwicklung beider Versionen erforderlich. Bei Umsetzung neuer Features gibt es hier eine Doppeltbelastung. Ich war in der Vergangenheit häufiger in solche Big Bang Refactoring verfahren verwickelt oder habe von Entwicklern aus erster Quelle davon gehört wie sie schief gegangen sind.
In Zeiten von Lean Software Entwicklung mit Agilen Methoden halte ich dieses Vorgehen zudem für nicht mehr Zeitgemäß. Da die Entwicklungszyklen zu lang sind und ein wirklich verlässliches Feedback erst beim Big Bang Relaunch erfolgt.
Ziel eines Refactorings sollte es sein möglichst schnell messbare Erfolge zu
erzielen,
Entwicklung neuer Features muss schnell billiger werden und die gebundenen Ressourcen für Bugfixing und Maintanance müssen schnell reduziert werden.
Gerade im Bereich von historisch gewachsenen PHP Projekten die oftmals ohne feste Code Struktur die Prinzipien Objektorientierter Programmierung oder Design Patterns noch nicht oder nur halbherzig Angewendet. Framworks der ersten Generation wie z.b. Zend Framework 1, Cake oder Symfony 1 in teil Bereichen eingesetzt.
Ein häufiger Ansatz ist ein Technologie switch beim Aufsetzen beim Refactoring, moderne Frameworks wie z.b. Zend Framework 2, Symfony 2, Yii im PHP Bereich, das Spring oder Play Framework in der Java Welt bieten hier neben vielen anderen mögliche Lösungen
Daneben bieten auch Node.Js oder NoSQL oft alternativen für bestimmte Einsatzszenarien.
Um Funktionalität aus dem Legacy Code stückweise her raus zu ziehen eignet sich die Erschaffung von Microservices hervorragend, hierbei ist relativ egal ob diese zunächst über PHP angesprochen oder gleich als entsprechende REST Services etabliert werden. Diese Methodik könnte man auch "Refactoring to Services" bezeichnen.
Um die Refactoring Maßnahmen abzusichern empfiehlt es sich sofern nicht vorhanden möglichst schnell eine gewisse Testabdeckung mit kurzen Feedback Zyklen zu etablieren.
Es geht hierbei nicht um eine möglichst vollständige Abdeckung sondern um ein effektives Sicherheitsnetz das möglichst die wichtigsten Stellen zuerst betrifft.
Unit Test eignen sich zwar für neue Entwicklungen sehr gut sind für Legacy Anwendungen allerdings ungeeignet. Die effektivere Lösung ist es bestehende Funktionalität erstmal durch End 2 End test abzusichern, dies kann mittels einer Behavior Driven Development Schicht wie zum Beispiel Cucumber oder Behat erfolgen oder direkt mit einem Test Tool wie beispielsweise Selenium Webdriver. Wenn man gar nichts hat kann man auch mit dem Selenium IDE Tests aus dem Browser capturen, diese sind allerdings bedeutend weniger wartungsfreundlich als die Webdriver Tests.
Grundsätzlich ist bei Refactorings nicht zu vergessen das neben den Technischen Neuerungen auch das Team eine wichtige Rolle spielt, neue Technologien und Vorgehensweisen müssen elernt werden, gerade auch deswegen sind kurze Feedback schleifen und regelmäßige Anpassungen sehr wichtig. Agile Vorgehens Methodik wie das Einbeziehen des gesamt Teams unter Erwägung technischer und kaufmännischer Gesichtpunkte wie z.b. in Scrum Planning Meetings bietet hier eine gute Grundlage.
Schneller Wirtschaftlicher Erfolg hat die Betreiber oft dazu gezwungen schnell viele Features Umzusetzen, was oft zu lasten der Code Qualität ging. Mit der Zeit haben sich hier die soganannten Technischen Schulden angehäuft. Der historische gewachsene Code wird zum bekannten Problem des sogenannten „Big Ball of Mud“. Feature Entwicklungen dauern lange werden somit teuer und das Team ist oftmals mit Bugfixes im beschäftigt. Eines der größten Risiken an diesem Zustand ist auf einen sich verändernden Markt nicht schnell genug reagiert werden kann.
Um nicht wie schon viele andere zeitweise Erfolgreiche Web Angebote an dieser "Feature Lähmung“ zu scheitern ist es an dieser stelle erforderlich die Entscheidung für ein Refactoring zu treffen.
The Big Bang Relaunch
Oft wird als Lösung eine komplette neue Entwicklung der Plattform angestrebt, doch gerade im benutzerabhängigen Endkunden Markt des öffentlichen Web ist dies besonders schwierig, oft ist man neben dem wohlwollen der Benutzer zudem noch auf eine effektive SEO Platzierung des eigenen Portals angewiesen. Bei kompletten neu Entwicklungen ist das Verhalten der Benutzer schwer vor raus zu sagen, oft stoßen solche Relaunches auf ablehnung bei den Stammbenutzern, gerade Communities reagieren hier zeitweise sehr empfindlich. Zudem ist oft über Monate oder Jahre hinweg eine Parallel Entwicklung beider Versionen erforderlich. Bei Umsetzung neuer Features gibt es hier eine Doppeltbelastung. Ich war in der Vergangenheit häufiger in solche Big Bang Refactoring verfahren verwickelt oder habe von Entwicklern aus erster Quelle davon gehört wie sie schief gegangen sind.
In Zeiten von Lean Software Entwicklung mit Agilen Methoden halte ich dieses Vorgehen zudem für nicht mehr Zeitgemäß. Da die Entwicklungszyklen zu lang sind und ein wirklich verlässliches Feedback erst beim Big Bang Relaunch erfolgt.
Agile Refactoring: das wichtigste zurerst.
Entwicklung neuer Features muss schnell billiger werden und die gebundenen Ressourcen für Bugfixing und Maintanance müssen schnell reduziert werden.
Gerade im Bereich von historisch gewachsenen PHP Projekten die oftmals ohne feste Code Struktur die Prinzipien Objektorientierter Programmierung oder Design Patterns noch nicht oder nur halbherzig Angewendet. Framworks der ersten Generation wie z.b. Zend Framework 1, Cake oder Symfony 1 in teil Bereichen eingesetzt.
Ein häufiger Ansatz ist ein Technologie switch beim Aufsetzen beim Refactoring, moderne Frameworks wie z.b. Zend Framework 2, Symfony 2, Yii im PHP Bereich, das Spring oder Play Framework in der Java Welt bieten hier neben vielen anderen mögliche Lösungen
Daneben bieten auch Node.Js oder NoSQL oft alternativen für bestimmte Einsatzszenarien.
Um Funktionalität aus dem Legacy Code stückweise her raus zu ziehen eignet sich die Erschaffung von Microservices hervorragend, hierbei ist relativ egal ob diese zunächst über PHP angesprochen oder gleich als entsprechende REST Services etabliert werden. Diese Methodik könnte man auch "Refactoring to Services" bezeichnen.
Um die Refactoring Maßnahmen abzusichern empfiehlt es sich sofern nicht vorhanden möglichst schnell eine gewisse Testabdeckung mit kurzen Feedback Zyklen zu etablieren.
Es geht hierbei nicht um eine möglichst vollständige Abdeckung sondern um ein effektives Sicherheitsnetz das möglichst die wichtigsten Stellen zuerst betrifft.
Unit Test eignen sich zwar für neue Entwicklungen sehr gut sind für Legacy Anwendungen allerdings ungeeignet. Die effektivere Lösung ist es bestehende Funktionalität erstmal durch End 2 End test abzusichern, dies kann mittels einer Behavior Driven Development Schicht wie zum Beispiel Cucumber oder Behat erfolgen oder direkt mit einem Test Tool wie beispielsweise Selenium Webdriver. Wenn man gar nichts hat kann man auch mit dem Selenium IDE Tests aus dem Browser capturen, diese sind allerdings bedeutend weniger wartungsfreundlich als die Webdriver Tests.
Grundsätzlich ist bei Refactorings nicht zu vergessen das neben den Technischen Neuerungen auch das Team eine wichtige Rolle spielt, neue Technologien und Vorgehensweisen müssen elernt werden, gerade auch deswegen sind kurze Feedback schleifen und regelmäßige Anpassungen sehr wichtig. Agile Vorgehens Methodik wie das Einbeziehen des gesamt Teams unter Erwägung technischer und kaufmännischer Gesichtpunkte wie z.b. in Scrum Planning Meetings bietet hier eine gute Grundlage.
Mögliche Massnahmen beim Agilen Refactoring
- Applikation in Module splitten
- Split oder sogenanntes A/B Testing für Einzelbereiche der Applikation
- Refactoring hin zu einzelnen Modulen und Services
- Entwickeln von Ziel Paradigmen für Architektur und Code
- Schaffen einer Deployment und Continious Integration Pipeline
- Einführen oder erweitern von Tests
- Workshops zur Identifikation der Problemstellen
- Software Metriken
- Coaching des Teams
- Einbau von Feedback schleifen für Aktuellen Stand
Planen sie ein Refactoring ihrer PHP Legacy Anwendung ?
Gerne stehe ich ihnen als Coach, Trainer und Entwickler zur Verfügung
http://www.webconsults.eu/
- Split oder sogenanntes A/B Testing für Einzelbereiche der Applikation
- Refactoring hin zu einzelnen Modulen und Services
- Entwickeln von Ziel Paradigmen für Architektur und Code
- Schaffen einer Deployment und Continious Integration Pipeline
- Einführen oder erweitern von Tests
- Workshops zur Identifikation der Problemstellen
- Software Metriken
- Coaching des Teams
- Einbau von Feedback schleifen für Aktuellen Stand
Planen sie ein Refactoring ihrer PHP Legacy Anwendung ?
Gerne stehe ich ihnen als Coach, Trainer und Entwickler zur Verfügung
http://www.webconsults.eu/
Danke für Information! Wenn Sie noch eine sichere Plattform für Investments einstellen möchten, dann empfehle Ich Datenraum Erfassung zur Nutzung.
AntwortenLöschen