Die Version 1.5 ist die bisher umfangreichste neue Version unseres Solr-Moduls für die Produktsuche in Magento. Während wir über die neuen Features bereits berichtet haben, geht es in diesem Beitrag um die Änderungen unter der Haube.
Refactoring: Ziele
Der Auslöser für das nun durchgeführte große Refactoring des Moduls war der Plan, neben Magento 1 auch ein Modul für Magento 2 bereit zu stellen. Wegen der großen Unterschiede zwischen den Magento-Versionen ist eine Konvertierung allerdings nicht so einfach, sodass in jedem Fall ein neues Modul erstellt werden muss.
Dabei wollten wir nicht bei Null anfangen, sondern relevante Teile des jetzigen Magento-1-Moduls wiederverwenden. Ein weiterer wichtiger Faktor war unser Wunsch, in Zukunft nicht zwei komplett getrennte Module warten zu müssen, wenn es z.B. um die Unterstützung neuer Solr-Versionen geht.
Framework-unabhängiger Code
Um diese Ziele zu erreichen, müssen möglichst große Teile des Quellcodes von IntegerNet_Solr zwischen den verschiedenen Modulversionen geteilt werden. Dieser Code muss entsprechend unabhängig vom jeweiligen Framework (Magento 1 bzw. Magento 2) laufen und von dem Framework-spezifischen Teil nur aufgerufen werden, darf aber nicht davon abhängen.
Dependency Injection
Das mit Magento 2 bereits eingeführte Prinzip der Dependency Injection besagt im Prinzip genau dies: Code hängt nicht von anderem (in diesem Fall Framework-spezifischem) Code ab, sondern erhält nur genau die Daten und Objekte, die er benötigt. Die Module für Magento 1 und Magento 2 können jeweils dazu passende Daten injizieren – wichtig ist nur, dass die jeweiligen vom Modul definierten Interfaces eingehalten werden. Denn Magento 1 und Magento 2 liefern beispielweise jeweils zueinander inkompatible Produkt-Objekte. Der Framework-spezifische Teil der Module sorgt jetzt dafür, dass sie in so genannte Bridge-Objekte umgewandelt werden und dann vom Framework-unabhängigen Teil genutzt werden können. Das gleiche gilt z.B. auch für Produktattribute, -filter oder die Konfiguration.
Überall dort, wo das Modul direkt mit Magento interagiert, muss der zugehörige Code natürlich im Framework-spezifischen Teil des Moduls verbleiben.
Automatisierte Tests
Ein weiterer Vorteil des Refactorings: Der dadurch entstandene, Framework-unabhängige Code ist wegen deutlich reduzierter Abhängigkeiten leichter automatisiert testbar, was wir auch kräftig ausnutzen. So haben wir den Code in weiten Teilen mit Unit-Tests sowie Integration-Tests auf Basis von PHPUnit versehen. Dadurch fallen mögliche Bugs, die durch Anpassungen an der Funktionalität entstehen können, direkt auf, was der Qualität der Module sehr zugute kommt.
Codequalität
Auch wenn die Codequalität von IntegerNet_Solr bereits vor dem Refactoring gut war, konnte sie noch einmal gesteigert werden. Kleinere Klassen und Methoden sorgen für eine bessere Lesbarkeit des Codes, und Prinzipien wie Single Responsibility verbessern die Erweiterbarkeit. Dabei werden moderne Software-Entwurfsmuster wie Factories, Value Objects, Facades und Bridges eingesetzt – mehr dazu können Sie in unserer Blogserie „Magento 1 and Magento 2: Shared Code for Extensions“ lesen.
Fazit
Für ein langlebiges und in vielen verschiedenen Konfigurationen eingesetztes Modul wie IntegerNet_Solr ist es notwendig, eine solide und qualitativ hochwertige Code-Basis zu haben. Dank des Refactoring erfüllt unser Modul dieses Ziel, sodass wir uns jetzt auf dieser Basis der Implementierung für Magento 2 widmen können.
Autor: Andreas von Studnitz
Andreas von Studnitz ist Diplom-Informatiker, Magento-Entwickler und Geschäftsführer von integer_net. Seine Schwerpunkte sind Entwicklung, Beratung und die Durchführung von Schulungen. Er ist Magento 2 Certified Professional Developer Plus und hat darüber hinaus weitere Magento Zertifizierungen für Magento 1 und Magento 2. Sowohl im Jahr 2019 als auch 2020 wurde Andreas als Magento Master in der Kategorie „Mentor“ ausgezeichnet.