Sinnvolle Gruppierung von OXID Modulen

MODULAR, das Wort heißt MODULAR 🙂

Als ich das erste Mal mit OXID in Berührung kam, war ich von den Möglichkeiten der modularen Erweiterbarkeit recht angetan. Eigene Funktionalitäten, die vom Core unabhängig in einem eigenen Modul-Ordner separiert werden und somit problemlose Updates versprachen – das hörte sich gut an. Relativ schnell kam jedoch die Frage auf, wie man diese Module sinnvoll gruppiert. Dabei kamen mir spontan zwei Vorgehensweisen in den Sinn. Zum einen die Zusammenstellung nach Funktionalität, zum anderen die Zusammenstellung nach Teilen des Shops, die erweitert oder überschrieben werden. Also alles, was den User im OXID-Shop um Funktionalität erweitert oder manipuliert kommt in ein udoUser-Modul. Letztendlich könnte man es sogar so weit treiben, dass man alle Änderungen/Erweiterungen in ein einziges Modul schreibt.

Zu dem Zeitpunkt war ich noch für ein Unternehmen tätig, das nur seinen eigenen Shop betreute. Eine Wiederverwendbarkeit der Module war also nicht unbedingt nötig. Jedes Modul erzeugt zudem zusätzlichen „Aufwand“ – Ordnerstruktur anlegen, metadata.php erzeugen, je nach Coding Guidelines vielleicht noch eine README.md oder ähnliches. Also war durchaus die Versuchung gegeben, die Funktionalitäten auf möglichst wenige, generische Module zu verteilen.

Nach einigen Jahren OXID Erfahrung, auch im Multiprojekt-Geschäft, möchte ich an dieser Stelle die Argumente aufzeigen, warum man dieser Versuchung nicht nachgeben und (auch im Single-Shop-Betrieb) seine Module nach Funktionalität gruppieren sollte.

Deaktivieren einzelner Funktionalitäten

Das Internet ist extrem schnelllebig. Gestern programmiert, heute veraltet. Aus diversen Gründen (Marketing, Recht, usw.) kann/darf/will man eine Funktion nicht mehr verwenden. Hat man kein eigenes Modul für diese Funktion erstellt, kann man es nicht einfach im Backend deaktivieren, sondern muss die entsprechenden Codezeilen aus dem Quelltext suchen und auskommentieren bzw. entfernen.

Vermeidung von Datenbank und Assets – Datenmüll

Hat man sein Modul wie in Punkt 1 beschrieben aus dem Quelltext entfernt, bleiben häufig die „unsichtbaren“ Anhängsel wie Datenbankfelder, CSS-, JS- und Image-Files zurück und vermüllen den Quelltext. Einmal vergessen, weiß keiner mehr, wozu sie gehör(t)en und lässt sie sicherheitshalber liegen, falls sie noch irgendwo verwendet werden. Über einen ordentlichen Install-/Deinstallprozess im Modul kann ich Datenbankfelder hinzufügen und sauber wieder entfernen. Dieses Vorgehen ist auch hervorragend geeignet, um Datenbankänderungen in verteilten Teams zu managen. Wenn man ein Modul von einem anderen Entwickler bekommt und es aktiviert, hat man automatisch auch die benötigten Datenbankänderungen auf seiner lokalen Maschine.
Assets werden im Modulordner abgelegt und sind so klar den jeweiligen Modulen zuzuordnen.

Fehlersuche

OXID ist bei der Fehlersuche gelegentlich etwas sadistisch veranlagt. Ist man als Entwickler eher etwas weniger masochistisch eingestellt, kann man die Schmerzen mindern, indem man einzelne Module ausschaltet, bis man den Fehler entsprechend weit eingrenzen konnte. Das ist oftmals sehr hilfreich und erleichtert das Debugging enorm.

Dokumentation

Wenn ich pro Modul nur eine oder sehr wenige Funktionen verbaue und dieses Modul entsprechend seiner Funktion benenne, habe ich schon einen guten Anhaltspunkt, was dieses Modul macht. Pflegt man dann noch eine ordentliche „description“ in die zugehörige Metadata-Datei ein, erhält man schon eine recht gute Dokumentation, welche Aufgabe durch dieses Modul übernommen werden.

Multishops, in denen nicht alle Funktionen verfügbar sein sollen/können

In der Enterprise Edition gibt es die Möglichkeit Multishops zu betreiben. Module müssen/können dabei für den jeweiligen Shop de-/aktiviert werden. Wenn man seine Module klein hält und nach ihrer Funktion gruppiert, kann man so sehr schön steuern, welcher Shop welche Funktion bekommt. Hat man mehrere Funktionen in einem Modul zusammengefasst, kann man auch nur den kompletten Funktionsumfang für den Shop aktivieren.

Updates bestehender Module

Früher oder später kommt der Zeitpunkt, an dem man bestehende Funktionalitäten ersetzen möchte bzw. muss. Wenn diese Funktionalität in einem eigenen Modul gekapselt ist, kann man in aller Ruhe eine neue Version entwickeln. Am Release-Day schaltet man innerhalb von Sekunden das alte Modul ab und das neue an. Treten dann im Nachhinein unerwartete Probleme auf, kann man einfach wieder auf die alte Version zurück switchen.
Hat man ursprünglich mehrere Funktionen in ein Modul gepackt, muss ich diese mühsam, wie in Punkt 1 beschrieben aus dem Quelltext entfernen. Das zurückspringen im Fehlerfall ist damit dann ausgeschlossen.

Wer weitere Gründe für die funktionale Gruppierung von Modulen hat, darf diese gerne in den Kommentaren ergänzen. Ich hoffe, dem ein oder anderen OXID Neuling mit diesem Beitrag auf der Suche nach einer sinnvoller Kapselung von Modulen auf den richtigen Weg geholfen zu haben.

 

0.00 avg. rating (0% score) - 0 votes


0 Kommentare

Dein Kommentar

Want to join the discussion?
Feel free to contribute!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.