Im Rahmen einer Forschungsarbeit haben Fabian Schmengler und Dr. Nikolai Krambrock typische Probleme bei der Entwicklung von Magento-Modulen analysiert. Zu der Forschungsarbeit gibt es eine Übersicht und Erklärung. Zur Ermittlung der Problem wurden problemzentrierte Interviews durchgeführt, deren Mitschrift heruntergeladen werden kann. Die in den Interviews genannten Probleme werden hier tabellarisch und textuell erklärt. Die Maßnahmen zum Abwenden der Probleme werden in den Maßnahmen erklärt. Zudem gibt es eine Zuordnung zwischen Problemen und Maßnahmen.

ProblemTätigkeit
P1 Ungenaue oder widersprüchliche AnforderungenAnalyse
P2 Zusätzlicher Recherche-SchrittAnalyse
P3 Zeitliche Aufwandschätzung falschEntwurf
P4 Formaler Entwurf ist erschwertEntwurf
P5 Know-How von erfahrenen Entwicklern wird nicht ausgeschöpftEntwurf
P6 Anlernen dauert langeEntwurf, Codierung
P7 Debugger und/oder Versionskontrolle wird nicht verwendetCodierung
P8 Geringe Code-Qualität (insb. Wartbarkeit und Zuverlässigkeit) CodierungCodierung
P9 Unerwartete SeiteneffekteCodierung, Test
P10 Viele Iterationen zwischen Codierung und TestCodierung, Test
P11 Automatisierte funktionale Tests sind aufwändigTest
P12 Unit Tests sind aufwändig und ineffektivTest
P13 Geringe Code-Qualität von Fremd-ExtensionsIntegration
P14 Mehrere Schleifen zwischen Layoutern, Templatern und EntwicklernIntegration
P15 Für Entwickler aufwändige Einarbeitung in WerkzeugeIntegration
P16 Fehleranfälliges DeploymentIntegration
P17 Hinterhof-ImageAllgemein
P18 Viele Change RequestsAllgemein


P1 Ungenaue oder widersprüchliche Anforderungen

Dass Anforderungen vom Kunden unvollständig oder ungenau sind, ist ein generelles Problem in der Softwareentwicklung, was durch systematische Anforderungsanalyse behandelt wird. Ludewig und Lichter bezeichnen daher auch die vollständige und präzise Anforderungsanalyse als wichtigste technische Voraussetzung für eine erfolgreiche Software-Entwicklung. Im Kontext eines umfangreichen Anwendungsframeworks wie Magento verstärkt sich dieses Problem allerdings, da der Kunde den Funktionsumfang meist nicht überblickt.

P2 Zusätzlicher Recherche-Schritt

Hohe Komplexität des Framework-Quellcodes kombiniert mit fehlender Dokumentation des Frameworks führen dazu, dass häufig zusätzliche Recherche notwendig ist, bevor mit dem Entwurf begonnen werden kann.

P3 Zeitliche Aufwandschätzung falsch

Die Expertenschätzung, bei der derjenige der eine Aufgabe implementiert, ihren zeitlichen Aufwand schätzt, ist aus den selben Gründen oft ungenau. Das kann an fehlender Erfahrung liegen.

P4 Formaler Entwurf ist erschwert

Dieses Problem ergibt sich implizit aus den Interviews, obwohl es dort nicht direkt als Problem angesprochen wird. Ohne Formalisierung des Entwurfs kann er nicht diskutiert und geprüft werden.

P5 Know-how von erfahrenen Entwicklern wird nicht ausgeschöpft

Dies ist ein Folgeproblem von P4, das sich direkt bemerkbar macht. Entwickler, die mehrere Jahre Erfahrung mit dem Framework haben und seine Funktionsweise gut kennen, können dieses Wissen 1:1 in Schulungen weitergeben. In einer Firma vorhandenes Know-how wird also nicht optimal genutzt.

P6 Anlernen dauert lange

Umfangreiche Anwendungsframeworks haben eine entsprechend steile Lernkurve, besonders wenn die Dokumentation verhältnismäßig mager ausfällt.

P7 Debugger und/oder Versionskontrolle wird nicht verwendet

Dass vorhandene Werkzeuge in der Praxis aus Unkenntnis oder Gewohnheit oft nicht verwendet werden, ist ein Problem, das der Geschichte von PHP und mangelnder Ausbildung von PHP-Entwicklern geschuldet ist. Beides sind qualitätssichernde Werkzeuge, ohne die die Entwicklung aufwändiger und fehleranfälliger ist.

P8 Geringe Code-Qualität (insb. Wartbarkeit und Zuverlässigkeit)

Auch bei Entwicklern mit hohem Anspruch lässt die Gesamtqualität des Codes zu wünschen übrig, da die Anwendung Qualitäts-Mängel von PHP und vom Framework erbt. So führt die fehlende Typsicherheit von PHP zu einem Mangel an Prüfbarkeit.

P9 Unerwartete Seiteneffekte

Je komplexer und nicht-linearer das Framework, desto größer ist das Risiko von unerwarteten Seiteneffekten. Bei Magento ist dies dementsprechend ein typisches Problem, das Zuverlässigkeit und Änderbarkeit der Software beeinträchtigt.

P10 Viele Iterationen zwischen Codierung und Test

Wenn während der Entwicklung eines Features nicht bereits systematisch getestet wird, werden beim (manuellen) funktionalen Test häufig noch Fehler gefunden, es geht zurück in die Codierung und diese Schritte wiederholen sich mehrmals, was die Entwicklung erheblich verzögern kann.

P11 Automatisierte funktionale Tests sind aufwändig

Wenn es nicht bereits Testfälle für die Basis-Funktionen des Frameworks gibt, ist die Erstellung dieser Tests ein großer Initial-Aufwand. Und selbst wenn es sie gibt, müssen sie laufend gepflegt werden, um Änderungen und Erweiterungen abzubilden.

P12 Unit Tests sind aufwändig und ineffektiv

Anwendungen, die auf Frameworks aufbauen, welche nicht selbst Unit tested sind, lassen sich schwer Unit testen, da Testbarkeit kein Kriterium bei der Entwicklung des Frameworks ist. Bei Magento führt dies dazu, dass Unit Tests in der Praxis kaum angewendet werden. Besonders das Testen von Klassen, die eng mit dem Framework gekoppelt sind, ist aufwändig.

P13 Geringe Code-Qualität von Fremd-Extensions

Ein modulares, erweiterbares System hat theoretisch den Vorteil, dass auf fertige Erweiterungen zurückgegriffen werden kann. Gerade bei PHP-Frameworks lässt die Qualität dieser Erweiterungen aber oft stark zu wünschen übrig, ihr Einsatz kostet damit mehr als er nutzt. Hier verstärken sich die mangelhafte Ausbildung von PHP-Entwicklern und Qualitätsmängel des Framework-Designs gegenseitig.

P14 Mehrere Schleifen zwischen Layoutern, Templatern und Entwicklern

Die Zusammenarbeit von verschiedenen Parteien an einem Projekt ist ein allgemeines organisatorisches Problem. Bei Web-Frameworks kommt hinzu, dass die Frontend- Entwicklung eigene Anforderungen an das Layout hat. Das Resultat sind Verzögerungen des Projekts.

P15 Für Entwickler aufwändige Einarbeitung in Werkzeuge

Es gibt für PHP keine einheitliche Werkzeug-Landschaft und die verfügbaren Werkzeuge sind oftmals mehr auf Systemadministratoren zugeschnitten als auf Entwickler. So kommt es dass es Werkzeuge gibt, die den Entwicklungsprozess unterstützen könnten, die Hürde, sie einzusetzen aber zu hoch ist.

P16 Fehleranfälliges Deployment

Die Abhängigkeit von globalen Systemkonfigurationen ist eine typische Fehlerquelle für PHP-Anwendungen.

P17 Hinterhof-Image

Das zitierte Hinterhof-Image ist ein allgemeines Problem der Branche, das ein Resultat von unprofessioneller Arbeit ist und mit der Verbesserung von Entwicklungsprozessen indirekt angegangen wird.

P18 Viele Change Requests

Viele Änderungswünsche im Laufe des Projekts ergeben sich analog zu P1 aus fehlender Übersicht über die Framework-Funktionalität. Daher ist das Wasserfall-Modell, in dem Change Requests den gesamten Ablauf verzögern, hier nicht anwendbar.