Wie gehen Sie mit Änderungen an Open Source-Frameworks um, die Sie für Ihre Projekte verwenden?

Es mag eine persönliche Eigenart von mir sein, aber ich mag es, Code in lebenden Projekten auf dem neuesten Stand zu halten - einschließlich der Bibliotheken / Frameworks, die sie verwenden. Ein Teil davon ist, dass ich glaube, dass eine Web-App sicherer ist, wenn sie vollständig gepatcht und aktuell ist. Ein Teil davon ist nur ein Hauch von Zwang meinerseits.

In den letzten sieben Monaten haben wir unsere Software grundlegend überarbeitet. Wir haben das Xaraya-Framework, das als Produkt langsam und im Wesentlichen tot war, fallen lassen und auf Cake PHP konvertiert. (Wir haben uns für Cake entschieden, weil wir so die Möglichkeit hatten, unsere Software sehr schnell neu zu schreiben und die Leistung gegenüber Xaraya so stark zu steigern, dass es sich lohnt.)

Wir haben Unit-Tests mit SimpleTest implementiert und alle Namenskonventionen für Dateien und Datenbanken usw. befolgt.

Kuchen wird jetzt auf 2.0 aktualisiert. Und es scheint keinen brauchbaren Migrationspfad für ein Upgrade zu geben. Die Namenskonventionen für Dateien haben sich radikal geändert und SimpleTest zugunsten von PHPUnit fallen gelassen.

Dies wird uns ziemlich zwingen, im 1.3-Zweig zu bleiben, da es nicht möglich sein wird, Cake zu aktualisieren und dann unseren Legacy-Code schrittweise zu verbessern, um die Vorteile des neuen Cake-Frameworks zu nutzen, es sei denn, es gibt ein Konvertierungstool . Wie üblich werden wir also ein altes Framework in unserem Subversion-Repository haben und es einfach nach Bedarf selbst patchen.

Und das bringt mich jedes Mal. So viele Open-Source-Produkte machen es nicht einfach genug, darauf basierende Projekte auf dem neuesten Stand zu halten. Wenn die Entwickler anfangen, mit einem neuen glänzenden Spielzeug zu spielen, werden einige wichtige Patches an älteren Zweigen vorgenommen, aber der größte Schwerpunkt wird auf der neuen Codebasis liegen.

Wie gehen Sie mit radikalen Veränderungen in den von Ihnen verwendeten Open Source-Projekten um? Denken Sie bei der Entwicklung eines Open Source-Produkts bei der Entwicklung neuer Versionen an die Upgrade-Pfade?

Das Problem betrifft nicht nur Open Source. Die gleichen Probleme treten bei kommerziellen Projekten auf. Vielleicht sogar noch mehr, weil Sie keine Quelle haben, können Sie sich selbst pflegen, wenn das Unternehmen den Support einstellt.

Open-Source-Projekte vom Endbenutzertyp haben schnelle Upgrade-Zyklen und alte Versionen verlieren sehr schnell die Unterstützung. Auf der anderen Seite haben Projekte, die für Benutzer konzipiert sind, um die Codierung mit erheblichem Aufwand zu ergänzen, nach einem größeren Upgrade tendenziell lange Unterstützungszyklen des alten Zweigs. Lange genug, damit Sie sich Zeit nehmen können, um darauf zu warten, dass es sich stabilisiert und ausgereift ist, und dann Ihren eigenen Code migrieren und gründlich testen.

Es kann schwierig sein, der Versuchung zu widerstehen, das Neueste und Beste zu haben, aber es ist ein grundlegender Kompromiss zwischen Stabilität und neuen Funktionen in der Software zu erkennen. Man kann keinen haben, ohne den anderen zu opfern. Aus diesem Grund gibt es Bugfix-Zweige, sodass Sie auswählen können, welche Seite des Spektrums Ihren Anforderungen am besten entspricht.

Wir haben dieses Problem durch Modularisierung unseres Codes behoben.

Unsere primäre Website wurde vor ungefähr acht Jahren erstellt, und wir hatten das Glück, dass sie von einem der ersten Mitwirkenden am Spring Framework erstellt wurde. Es war also eine ziemlich gut aufgebaute Grundlage. Leider hatten wir auch das Pech, dass sich dieser Entwickler nach einem Streit über die Richtung, in die er sich bewegte, für Spring entschieden hat. Daher steckt diese Codebasis jetzt auf einer nicht gepflegten Gabel von Spring 1.1.4 (oder etwas von diesem Jahrgang).

Wir haben versucht, den Code neu zu schreiben, um auf neue Versionen von Spring umzusteigen, aber das erwies sich als äußerst schwierig. Daher bestand unsere Lösung darin, neue Funktionen der Site als Module in einer vollständig separaten Anwendung zu erstellen und dabei die neuesten Frameworks wie Spring 3.x, Hibernate 3.6 usw. zu verwenden.

Jetzt laufen zwei Webanwendungen auf derselben Basis-URL und wir verwenden das Modul mod_proxy von Apache, um jeden Pfad der entsprechenden Anwendung zuzuweisen. Beispielsweise geht "/ Members" zur alten Anwendung und "/ Verzeichnisse" zur neuen Anwendung. Ein Besucher der Website hätte jedoch keine Ahnung, dass er unterschiedliche Anwendungen verwendet. Sie sehen für den Benutzer genauso aus.

Die beiden Anwendungen müssen miteinander kommunizieren. Wenn sich beispielsweise ein Mitglied bei der Site anmeldet (mit unserer neuen Anwendung), müssen wir die alte Anwendung darüber informieren, dass sie jetzt angemeldet sind. Dies geschieht über einen einfachen Webdienst, der nur für verfügbar ist localhost. Der Integrationsaufwand zwischen den beiden Apps erwies sich als minimal.

Ein wichtiger Teil dieser Arbeit bestand darin, gemeinsam genutzte Vermögenswerte zu identifizieren und zusammenzufassen. Daher wurden alle statischen Texte, Grafiken, Stylesheets, Javascript und Vorlagen aus der ursprünglichen Anwendung in ein separates drittes Projekt verschoben, das sowohl von der neuen als auch von der alten Anwendung verwendet wird. Dadurch wird sichergestellt, dass beide Webanwendungen gleich aussehen und funktionieren, obwohl sie vollständig voneinander getrennt sind.

Ich stelle mir vor, dass wir im Laufe der Zeit immer mehr der ursprünglichen Anwendung ersetzen werden, bis sie schließlich völlig unnötig ist. Das Schöne an dieser Technik ist, dass wir sie langsam über eine Reihe kleiner, risikoarmer Änderungen durchführen können - es ist keine massive und riskante plötzliche Umstellung auf ein neues System erforderlich.

Ich mache es nicht immer. In vielen Open Source-Projekten werden aktive Wartungszweige für frühere Hauptversionen unterhalten. Manchmal werden diese von Personen gepflegt, die diese Version pflegen müssen. Viele Projekte bleiben auf einer Hauptversion, bis sie selbst für eine Hauptversion bereit sind.

Und das bringt mich jedes Mal.

Jedes Mal? Sie müssen bemerkenswert schlechte Entscheidungen treffen. Es muss ein Beispiel geben, bei dem es nicht passiert ist.

Wenn die Entwickler anfangen, mit einem neuen glänzenden Spielzeug zu spielen

Das ist ein Hinweis. Vermeiden Sie glänzendes neues Spielzeug, wenn Sie Open Source-Projekte verwenden. Vermeiden Sie Release 1.0.

Wie gehen Sie mit radikalen Veränderungen in den von Ihnen verwendeten Open Source-Projekten um?

Schritt 1. Wählen Sie Open Source-Projekte sehr, sehr sorgfältig aus. Vergleichen Sie immer zwei oder mehr konkurrierende Projekte.

Schritt 2. Versuchen Sie beim Vergleich zweier konkurrierender Projekte zu verstehen, welche "wesentlichen" Funktionen angeboten werden und wie beide damit umgehen. Vermeiden Sie es, eine bestimmte API zu früh zu "heiraten".

Schritt 3. Beachten Sie die Konstruktionsprinzipien von "Late Binding" und "Loose Coupling". Versuchen Sie, sich von Open Source-Projektänderungen zu isolieren.

Schritt 4. Machen Sie explizit Kosten-Nutzen-Vergleiche zwischen Open Source-Projekten und "Rolling Your Own". Hin und wieder ist es möglicherweise besser, eine eigene Lösung zu erstellen, als mit einer Open Source-Lösung fertig zu werden.

Das Ändern der Dateinamen sollte nicht zu schwierig sein. Ja, es ist ein großes, hässliches Drehbuch. Ja, es muss während der Konvertierung mehrere Wochen lang ausgeführt werden. Aber es sind endliche Kosten.

Wenn dies jedes Mal passiert , entwickeln Sie bessere Bewältigungsstrategien. Da Ihre Beobachtung der realen Welt ist, dass es immer passieren wird, wird die Hoffnung, dass sich die reale Welt ändert, nicht wirklich viel helfen. Sie haben einige hart erarbeitete Erfahrungen im Wandel. Nutzen Sie das. Betrachten Sie es als eine Infektion und entwickeln Sie Ihre eigene Immunantwort.