Menü
Ein Beitrag von Adacor

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

Optimale Cloud-Lösungen nach Ihren Vorstellungen

Ob bewährte VMware-Lösungen, leicht zu bedienende Cloudlösung oder zuverlässige vServer...
Bei Filoo finden Sie die richtige Cloud für Ihre Bedürfnisse.

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.

,

Sie möchten keinen Beitrag verpassen?

Es gibt einen Newsletter. Hier können Sie ihn abonnieren.

Datenschutzhinweise


Weitere Artikel zum Thema lesen

ISO 27001 Zertifizierung – bester Schutz für IT

Biz & Trends, Cloud, Hosting, IT Security

ISO 27001 Zertifizierung – bester Schutz für IT

Aufgrund der Komplexität von Informationstechnik und der Nachfrage nach Zertifizierungen sind in den letzten Jahren zahlreiche Anleitungen, Standards und nationale Normen zur IT-Sicherheit entstanden....

weiter lesen

Applikationsbetrieb auf virtuellen Servern

IT-News

Applikationsbetrieb auf virtuellen Servern

Kann einer Virtualisierungsform der Vorzug gegeben werden? Sebastian Weiss hat genau hingeschaut.

weiter lesen

Cloud, Hosting

Welche Verfügbarkeit braucht mein Web-Projekt?

Unser Fragenkatalog hilft zur Bestimmung der erforderlichen Verfügbarkeit weiter.

weiter lesen


Neueste Nachrichten von Adacor

IT Security

Risikomanagement als Mehrwert für Unternehmen sehen

Wie Sie das Zusammenspiel von ISMS und IKS für sich nutzen können.

weiter lesen

Cloud

AWS, Azure und Co.: Brauchen Sie wirklich eine große Public-Cloud?

Das Angebot großer Public Clouds klingt für viele Unternehmen verlockend. Eine Private Cloud kann jedoch die ökonomisch sinnvollere Lösung sein.

weiter lesen

Biz & Trends

Was ist eigentlich Digitalisierung?

Der Begriff „ Digitalisierung“ weist viele Facetten auf. Die Aufteilung in Bereiche bringt jedoch Klarheit.

weiter lesen