[webEdition7] Integration des Zend Frameworks // Refactoring

[Schmidt]

Guten Abend zusammen,
zunächst einmal ein kleines Lebenszeichen von mir. Es gab die letzten Wochen viel zu tun. Ich komme z.Z. nur am Wochenende dazu mich mit webEdition zu beschäftigen.

Ich habe mir die letzte Zeit nochmal intensiv den Quellcode von webEdition angeschaut, insbesondere in Bezug auf de anstehen Portierung auf Basis des Zend Frameworks.

Bisher war ja geplant das ganze im Unterordner /cms/ nach und nach umzusetzen. Ich sehe hierbei aber einige Punkte die eher für einen neuen Branch (mit anderer Verzeichnisstruktur) sprechen würden:

a) Wir wollten zunächst einmal eine stabile 6.x.x-Version. Nach meiner Erfahrung treten durch Code-Änderungen immer Fehler auf. Alle refaktorierten Teile in die bestehende Version aufzunehmen und bereits zu nutzen halte ich daher für hinderlich.

b) Ich sehe an einigen Stellen den Bedarf von grundlegenden Änderungen, welche nur im Zuge eines Branches sinnvoll integriert werden könnten (z.B. Models) ohne den Druck das das sofort 100% funktionieren muss da im nächsten 6.0.0.x-Update vorhanden. Sowas muss immer gründlichst diskutiert/getestet/implementiert werden. Das sollte komplett frei von solchen Sorgen geschehen.

c) Eine neue Code-Basis könnte genutzt werden, um das Anlegen von Unit-Tests zwingend zu machen. Zu groß wäre ansonsten die Versuchung "mal eben etwas" zu implementieren, das womöglich ungetestet/nicht vollständig getestet in den Release geht. Ich denke mal das jeder von euch mit den Vorteilen des automatisierten Unit-Testings vertraut ist - oder liege ich hier falsch ? Man überlege sich nur mal wie lange bisher per Hand getestet werden musste. Das sollte man vermeiden (wo möglich).

d) einen Code der auf zwei unterschiedlichen Konzepten fußt (MVC vs. plain-OOP/CMD-orientiert) zu warten dürfte erheblich schwieriger sein.

e) Wir sollten uns vornehmen, den Code gründlichst zu refaktorieren, wo möglich auf bestehende Zend-Komponenten zurückgreifen um selbst um die Wartung eines Frameworks erleichtert zu werden. Das können die Jungs vom Zend Framework einfach viel besser. Konkret stelle ich mir das so vor: wir nehmen uns nach und an immer einzelne Komponenten, z.B. die Benutzerberechtigungen vor und schauen: wie ist der Stand, was treten für Probleme auf, was könnte in Zukunft implementiert werden und refaktorieren dann. In einem einheitlichem Code-Stil, mit strenger Nutzung von Zend-Komponenten und leichten Änderungen am Konzept wenn nötig um in Zukunft bestandsfähig zu bleiben. Das heisst jetzt aber nicht das 100% des Codes neu geschrieben werden muss (!). Vieles können wir aus dem bestehendem Code übernehmen, halt nur in anderer Form.

f) grob sehen die Verzeichnisstrukturen bei sauberen Zend Framework-Apps in etwa so aus:

/application
/modules
/models
/forms
/usw.
/data
/temp
/tests
/public oder /html
/usw.

Ich kann hierzu gerne eine komplette Liste erstellen und im Forum posten, ich wollte hierbei nur die grundsätzliche Struktur aufzeigen. Sicherlich auch unterhalb von /cms/ integrierbar wenn man gedrungen wird, aber das "drumherum" ausserhalb von /cms/ soll ja langfristig sowieso verschwinden.




Zeitlich ist eine Refaktorierung eh nicht unter 6-12 Monaten zu erreichen - ohne einen Branch der frei arbeiten kann dauert dies meiner Meinung nach bedeutend länger. Ich biete meine Mitarbeit mit Schwerpunkt Refaktorierung/Unit-Testing an - bin zeitlich aber stark eingeschränkt und kann nur am Wochenende daran arbeiten.

Was meint ihr ? Soll Ich meine Ideen im Forum ausführlich erläutern (Verzeichnisstruktur, Konzepte, usw) ?

Grüße,
Manuel Schmidt

PS: Ich wollte eigentlich in der Mailinglist posten, das kam aber postwendend zurück. Vermutlich muss ich über den original SMTP-Server schicken ?

[Alexander Lindenstruth]

Um an die Mailingliste schreiben zu können, muss man die abonnieren, dann sollte das eigentlich reibungslos funktionieren, egal über welchen SMTP Server (in meinem Fall einer von 1&1)

Prinzipiell spricht schon einiges für einen getrennten Entwicklerzweig. Allerdings sind dazu wie schon gesagt (bzw. geschrieben) zuerst ein paar Zuständigkeiten zu verteilen, schließlich werden in dieser Zeit ja auch im Bugfixzweig Bugs gefixt die dann u.U. in den Entwicklungszweig gemerged werden müssen. Das kann u.U. ziemlich zeutaufwendig und nervig werden. Außerdem sollten in absehbarer Zeit auch für nicht direkt im Projekt involvierte Nutzer Features und Änderungen/Erweiterungen direkt in neuen Releases sichtbar sein sonst haben wir nach außen hin ein Problem, weil das Projekt stehenzubleiben scheint.

Daher wäre ich eher für eine Kombination, d.h. ein schrittweises Refactoring bei dem zusammenhängende Blöcke (und die gibt es durchaus) immer wieder getestet und (wenn stabil und bugarm) in den Bugfixzweig gemerged werden. Dazu müssten aber Abhängigkeiten zwischen den neu zu implementierenden Bereichen (vieles davon dürfte bereits in den ersten Schritt fallen, z.B. Session mit Zend_Session und Zend_Repository, Authentifizierung/Login, Einstellungen, Kommandofluss usw.) geklärt werden, dann lässt sich das auch schrittweise durchführen. Ggf. wird in der SDK-Neuimplementierung lediglich ein Wrapper für die bisherige Funktionalität geschrieben. Wenn dann alle Bereiche, die auf diese Funktionalität (z.B. Einstellungen) zugreifen, umgezogen sind, kann man diese dann selber neu schreiben (bei den Einstellungen z.B. auf Zend_Config) um eine doppelte Datenhaltung zu vermeiden

Bei der grundlegende Reihenfolge würde ich schon wie auf dem we:Tag besprochen folgendes vorschlagen:

• Untersuchungen der JS-Frameworks in Bezug auf Barrierefreiheit
• GUI-Workaround für den Hauptscreen (die Sache mit dem iFrame) als Basis für die neue UI. Dazu gehört auch:
  • Authentifizierung/Login
  • Session mit Zend_Session und Bereitstellung eines Zend_Repository (für Config, Sessioninfos etc.)
  • JS-Kommandofluss
  • Alles was auf dem Hauptscreen läuft (Zugriffsmethoden auf die Elemente wie Tree und Menü, Notifications, Logging etc.)
• Definition und Dokumentation für die Umstellung auf Zend MVC
• Testen und Mergen in den Bugfixzweig
• Definieren von Reihenfolge und Abhängigkeiten
• Anhand der Abhängigkeiten: Definieren von Meilensteinen, zu denen Merges stattfinden können, daran sollten sich auch die Feature-Releasezyklen des Bugfix Zweiges orientieren
• Schrittweise Neuimplementierung

Hoffe ich habe meine wirren Gedanken dazu halbwegs verständlich machen können