Erfahrungsbericht – Refactoring eines großen Softwareprojekts

Für einen Kunden haben wir die groß angelegte Umbauaktion eines Intranet Systems mit 4,5 Mio. Zeilen Code umgesetzt. In diesem Beitrag dokumentieren wir für euch diesen Prozess.

Refactoring Prozess

Das Projekt wird schon seit der Gründerzeit der ADACOR Hosting bei uns entwickelt. Mit den Jahren hat die bereits seit über zehn Jahren andauernde Weiterentwicklung dazu geführt, dass der Quellcode unseren eigenen stetig gestiegenen Qualitätsansprüchen nicht mehr genügt und ein grundsätzliches Überdenken der Softwarearchitektur angebracht ist. Die Migration des Projekts auf eine andere Hardware wurde dazu genutzt, die gesamte Codebasis auf ein neues Qualitätslevel anzuheben. Auch die PHP-Version des Projekts wurde von 5.1 auf 5.3 angehoben. Mit der Umsetzung waren vier Kollegen befasst.

Der Umbau der Verzeichnisstruktur

Im Zuge des Refactorings entschlossen wir uns dazu, die Verzeichnisstruktur des Projektes von Grund auf zu ändern. Bisher fanden sich im „Document-Root“ diverse einzelne PHP-Dateien, die alle von außen erreichbar und separat aufrufbar waren. Da dies nicht mehr unserer aktuellen Arbeitsweise entspricht, entschieden wir uns dazu, diese Vorgehensweise zu ändern, sowie auch alle anderen Dateien des Projekts in eine sinnvolle, aufgeräumte Verzeichnisstruktur einzusortieren.

Die Applikation ist nun nur noch über die index.php extern aufrufbar. Diese bindet dann die entsprechenden anderen Dateien ein. Da die restlichen Dateien nicht mehr unterhalb des Document-Roots liegen sollten, wurden in der Folge weitere Änderungen notwendig: Sowohl alle Links als auch die Include-Pfade in den PHP-Dateien mussten geändert werden.

Einsatz der Webserver-Erweiterung Mod_rewrite im Projektverlauf

Da es sich um mehrere tausend Vorkommnisse handelt, wollten wir nicht alle Links manuell anpassen. Daher beschlossen wir die Webserver-Erweiterung „mod_rewrite“ zu verwenden. Hier legten wir Regeln an, die die Aufrufe der bisherigen Links nun automatisch auf die zu verwendende index.php umleiten. Da wir dort dann Zugriff auf den ursprünglich angeforderten Pfad hatten, konnten wir entsprechend darauf reagieren und die richtigen Dateien includen. Analog zu dieser Vorgehensweise legten wir zusätzlich noch eine Datei „getResource.php“ in den Document-Root. Sie ist für die Auslieferung zusätzlicher Ressourcen wie Bilder, Javascript- oder CSS-Dateien zuständig. Auch dafür verwendeten wir wieder mod_rewrite-Regeln. Durch diese Vorgehensweise haben wir erreicht, dass sämtliche Anfragen an den Server ausschließlich durch die index.php oder die getResource.php bearbeitet werden. Dieses Konzept erleichtert uns die Kontrolle sämtlicher HTTP Requests und ist aus Performancegesichtspunkten vertretbar, da es sich um ein Intranetsystem und kein öffentliches Portal mit mehreren tausend Besuchern handelt.

Das Anpassen der Pfade

Jetzt standen wir vor dem Problem, dass die Include- und Require-Pfade in den PHP-Dateien auf die alte Verzeichnisstruktur verwiesen. Wobei die Pfade relativ und absolut gehalten waren. Bei diesem Part sind wir keine Kompromisse eingegangen und haben die gesamte Codebasis unter den Entwicklern aufgeteilt und von Hand sämtliche Pfade korrigiert.

Image

filoo ClouDEasy

Sie wollen eine sichere ClouD? Dann haben Sie diese mit ClouDEasy soeben gefunden. Hier bekommen Sie eine skalierbare Lösung, mit der Sie sofort loslegen können. Es gibt keine lange Einarbeitungszeit – diese ClouD funktioniert einfach. Jetzt direkt informieren  

Bei einem Refactoring dieses Ausmaßes und vor allem bei der Anzahl der involvierten Mitarbeiter ist Koordination äußerst wichtig, damit Tasks nicht doppelt bearbeitet werden. Noch wichtiger war, dass durch unzureichende Planung kein Part vergessen wird.

Erschwert wurde der Prozess dadurch, dass zu Beginn des Refactorings keine Möglichkeiten zum Testen bestanden, da das neue Framework noch nicht vollständig umgesetzt war. Die Herausforderung bestand nun darin, das System umzukrempeln aber zugleich zu versuchen, dass anschließende Re-Refactoring so gering wie möglich zu halten. Dies kann bei schlechter Planung schnell zu einer riesigen Arbeit ausarten und damit zusätzliche Zeit- und Budgetprobleme mit sich bringen.

Als nächster Schritt mussten alle Pfadangaben auf die von Benutzern hochgeladenen Dokumente angepasst werden.

Wichtig war es dabei, den neuen Deploymentprozess im Hinterkopf zu behalten. Da durch diesen beim Deployment der gesamte Applikationspfad ersetzt wird, mussten User-Dateien, die zuvor fälschlicherweise innerhalb des Applikationspfades gespeichert wurden in den Ordner für hochgeladene Dokumente verschoben werden.

Auch in der MySQL Datenbank traten Altlasten zutage: Pfadangaben in Tabellenfeldern. Auch diese mussten wir selbstverständlich korrigieren und taten dies mit einem Script, nachdem wir mehrere Stellen entdeckten, an denen Pfade in Datenbanktabellen gespeichert waren.

Der letzte Schritt bestand in der Suche nach Problemen wegen des PHP 5.3 Updates. Nachdem das eine oder andere $HTTP_GET_VARS und $HTTP_POST_VARS aus den dunklen Vorzeiten des schon über zehn Jahre andauernden Projektes ersetzt war und einige exotische Workarounds für inzwischen triviale Tasks weichen mussten, sah es im Ergebnis schon ganz ordentlich aus.

Der Deployment-Prozess

Der alte Deployment-Prozess lief in der Form ab, dass ein Entwickler die gewünschten Änderungen an den Dateien aus unserem Subversion-Repository machte, diese dann selbst auf den Server hochlud und den geänderten Stand dann wieder eincheckte.

Dies führte allerdings immer mal wieder dazu, dass die Dateien auf dem Server nicht denen im Versionierungssystem entsprachen und entsprechend längst behobene Bugs plötzlich wieder auftraten. Also haben wir uns dazu entschlossen, den Deployment-Prozess zu ändern.

Zukünftig sollte es so sein, dass ein Entwickler seine Änderungen nur noch ins Subversion eincheckt und auf dem Server dann ein Script gestartet wird, das diese Änderungen vollautomatisch aus dem Versionierungssystem auscheckt. Dabei wollten wir jedoch die zuvor aktive Revision zunächst auf dem Server behalten, damit im Fehlerfall schnell wieder ein Wechsel zur alten Version möglich ist.


Das Script dupliziert nun zunächst das aktive Release-Verzeichnis um dann ein SVN-Update auf das Duplikat auszuführen. Da von den Benutzern hochgeladene Dateien nicht versioniert werden, haben wir diese aus dem Release-Pfad herausgezogen und in einem eigens dafür angelegten Verzeichnis gespeichert.

Für Änderungen an der Datenbankstruktur werden in Zukunft Update-Scripte geschrieben und diese nach einer Sicherhheitsabfrage automatisch beim Deployment ausgeführt. Dies verbessert für uns die Nachvollziehbarkeit von Änderungen und macht es möglich, manuelle Änderungen an der produktiven Datenbank vollständig zu verbieten.

Fazit: Durch Refactoring Stabilität des Projekts erhöht

Das Refactoring betrachten wir im nachhinein als vollen Erfolg, auch wenn sich nach außen hin auf den ersten Blick nichts verändert hat. Die aufgeräumte Codebasis erleichtert den Programmierern die tägliche Arbeit und der Deploymentprozess macht Änderungen besser nachvollziehbar und erhöht die Stabilität des produktiven Systems. Weiterhin ist die Architektur aller unserer Projekte nun soweit angeglichen, dass sich Entwickler aus verschiedenen Projekten leicht in ein anderes hineinfinden können. Diese Gründe rechtfertigen den Aufwand für das Refactoring aus unserer Sicht allemal.

,


Weitere Artikel zum Thema lesen

Beim Monitoring der Infrastruktur setzt ADACOR auf Nagios und Bacula

Hosting, IT Security

Beim Monitoring der Infrastruktur setzt ADACOR auf Nagios und Bacula

24/7 Monitoring der Infrastruktur und sicheres Backup sorgen für eine hohe Verfügbarkeit der Server-Infrastruktur.

weiter lesen

Digi3 relaunched Website von Open Grid Europe mit Apache Solr

Hosting

Digi3 relaunched Website von Open Grid Europe mit Apache Solr

Erfahrungsbericht: Relaunch der Website von Open Grid Europe mit Apache Solr.

weiter lesen

Unter den Augen des Gesetzes – Unternehmen handeln nach Bundesdatenschutzgesetz

Cloud, Hosting, IT Security

Unter den Augen des Gesetzes

Bundesdatenschutzgesetz und IT-Compliance am Beispiel der ADACOR.

weiter lesen


Neueste Nachrichten von ADACOR

IT Security

Hintergründe und aktuelle Informationen zur WannaCry-Attacke

Zum Heulen - wie die bislang größte Malware-Attacke ihren Ausgang nahm und welche Gegenmaßnahmen möglich sind.

weiter lesen

Hosting

Pflege und Aufbau eines Datennetzwerks im Rechenzentrum

Konzeptionelle Vorarbeit inklusive der Planung von Redundanzen beim Aufbau eines Datennetzwerks spart im Betrieb Zeit und Kosten.

weiter lesen

Vulnerability Management

Hosting

Mit Vulnerability Management Sicherheitslücken schließen

Durch regelmäßiges Scannen werden Schwachstellen in Systemen und Applikationen erkannt und beseitigt.

weiter lesen

Diese Seite verwendet Cookies, welche uns helfen, unsere Services anzubieten und zu verbessern.
Erfahren Sie mehr über unsere Cookie-Richtlinien. Durch die Nutzung dieser Website erklären Sie sich mit der Nutzung von Cookies einverstanden.