Übersicht von Maßnahmen und Problemen bei der Entwicklung von Magento-Modulen

Im Rahmen einer Forschungsarbeit haben Fabian Schmengler und Dr. Nikolai Krambrock typische Probleme bei der Entwicklung von Magento-Modulen analysiert. Außerdem wurden – teils durch Interviews, teils durch Recherche und Test – Maßnahmen ermittelt, um den Problemen Herr zu werden. In diesem Post werden Probleme und Maßnahmen gegenüber gestellt. Zu der Forschungsarbeit gibt es eine Übersicht und Erklärung. Die Probleme und Maßnahmen können für eine Erklärung jeweils angeklickt werden.

Zuordnung von Problemen und Maßnahmen in der Analyse

	P1 Ungenaue oder widersprüchliche Anforderungen	P2 Zusätzlicher Recherche-Schritt
M1 Schulung des Kunden / Product Owners	o
M2 Einbeziehung des Kunden in den Entwicklungsprozess	o
M3 Abstrakte Schätzung mit Story Points und Team Velocity
M4 Standards selber dokumentieren (basierend auf Reverse Engineering und Erfahrung)		+
M5 Schulungen
M6 Negativbeispiele
M7 Bei der Einstellung berücksichtigen: Erfahrung mit C#, Java u.ä. hilfreicher als mit PHP
M8 Vorhandene Werkzeuge verwenden
M9 Disziplin und Entwickler-Anspruch
M10 Code Reviews
M11 Automatisierte Tests
M12 Selenium-Tests von Programmierern erstellen lassen
M13 Review von Fremd-Extensions
M14 Eigenentwicklungen nach Möglichkeit vorziehen
M15 Abhängigkeiten zwischen Modulen und Templates vermeiden
M16 Alternative Entwürfe evaluieren
M17 Schätzungen hinterfragen
M18 Pair Programming
M19 Mehr Zeitdruck
M20 „aufpassen und nachschauen“
M21 Abrechnung nach Aufwand
M22 Kein vorgefertigtes finales Anforderungsdokument, transparent kontinuierliche Änderung der Spezifikation
M23 Entwicklungs-, Test- und Live-Systeme synchronisieren
M24 Manuelle Unit Tests
M25 Konfigurations-Änderungen der Anwendung nur über Update-Scripts		o
M26 Informiert bleiben über aktuelle Entwicklungen, auch in der Community
M27 Ein Team aus Templatern (Frontend) und Entwicklern (Backend), an Blockern wird gemeinsam gearbeitet (Scrum-Sirene)
M28 „Technical Debt“-Philosophie: Refactoring, Clean Code
M29 Inkrementeller Entwurf
M30 Framework-Dokumentation		o
M31 Reverse Engineering		o
M32 Pattern Detection		–
M33 Visuelle Modellierung mit UML		–
M34 Visuelle Modellierung mit Magento-UML		+
M35 FDD-Prozess
M36 Testgetriebene Entwicklung (TDD)
M37 Einfacher Entwurf
M38 Programming by Contract
M39 Coding Guidelines
M40 SOLID Prinzipien
M41 Testfall-Generatoren
M42 Built-in Tests
M43 Assertion-basierte Tests
M44 Integrierte White-box Tests
M45 Test-Automatisierung systematisch entscheiden
M46 Smoke Test Suite
M47 Mutation Testing
M48 Modellbasiertes Testen
M49 Abstraktion von funktionalen Tests, automatisierte Akzeptanztests
M50 Kompatibilitätsanalyse mit FDMM

Zuordnung von Problemen und Maßnahmen im Entwurf

	P3 Zeitliche Aufwandschätzung falsch	P4 Formaler Entwurf ist erschwert	P5 Know-How von erfahrenen Entwicklern wird nicht ausgeschöpft	P6 Anlernen dauert lange
M1 Schulung des Kunden / Product Owners
M2 Einbeziehung des Kunden in den Entwicklungsprozess
M3 Abstrakte Schätzung mit Story Points und Team Velocity	+
M4 Standards selber dokumentieren (basierend auf Reverse Engineering und Erfahrung)	o		+
M5 Schulungen				+
M6 Negativbeispiele				o
M7 Bei der Einstellung berücksichtigen: Erfahrung mit C#, Java u.ä. hilfreicher als mit PHP				o
M8 Vorhandene Werkzeuge verwenden
M9 Disziplin und Entwickler-Anspruch
M10 Code Reviews
M11 Automatisierte Tests
M12 Selenium-Tests von Programmierern erstellen lassen
M13 Review von Fremd-Extensions
M14 Eigenentwicklungen nach Möglichkeit vorziehen
M15 Abhängigkeiten zwischen Modulen und Templates vermeiden
M16 Alternative Entwürfe evaluieren	o
M17 Schätzungen hinterfragen
M18 Pair Programming			+	o
M19 Mehr Zeitdruck
M20 „aufpassen und nachschauen“
M21 Abrechnung nach Aufwand
M22 Kein vorgefertigtes finales Anforderungsdokument, transparent kontinuierliche Änderung der Spezifikation
M23 Entwicklungs-, Test- und Live-Systeme synchronisieren
M24 Manuelle Unit Tests
M25 Konfigurations-Änderungen der Anwendung nur über Update-Scripts
M26 Informiert bleiben über aktuelle Entwicklungen, auch in der Community
M27 Ein Team aus Templatern (Frontend) und Entwicklern (Backend), an Blockern wird gemeinsam gearbeitet (Scrum-Sirene)
M28 „Technical Debt“-Philosophie: Refactoring, Clean Code
M29 Inkrementeller Entwurf		o
M30 Framework-Dokumentation		o	o
M31 Reverse Engineering		o	o
M32 Pattern Detection		–	–
M33 Visuelle Modellierung mit UML		–	–
M34 Visuelle Modellierung mit Magento-UML		+	+
M35 FDD-Prozess
M36 Testgetriebene Entwicklung (TDD)		–
M37 Einfacher Entwurf
M38 Programming by Contract		o
M39 Coding Guidelines
M40 SOLID Prinzipien
M41 Testfall-Generatoren
M42 Built-in Tests
M43 Assertion-basierte Tests
M44 Integrierte White-box Tests
M45 Test-Automatisierung systematisch entscheiden
M46 Smoke Test Suite
M47 Mutation Testing
M48 Modellbasiertes Testen
M49 Abstraktion von funktionalen Tests, automatisierte Akzeptanztests
M50 Kompatibilitätsanalyse mit FDMM

Zuordnung von Problemen und Maßnahmen bei der Codierung

	P7 Debugger/ Versions- kontrolle nicht verwendet	P8 Geringe Code-Qualität	P9 Unerwartete Seiteneffekte	P10 Iterationen Codierung und Test
M1 Schulung des Kunden / Product Owners
M2 Einbeziehung des Kunden in den Entwicklungsprozess
M3 Abstrakte Schätzung mit Story Points und Team Velocity
M4 Standards selber dokumentieren (basierend auf Reverse Engineering und Erfahrung)
M5 Schulungen
M6 Negativbeispiele
M7 Bei der Einstellung berücksichtigen: Erfahrung mit C#, Java u.ä. hilfreicher als mit PHP
M8 Vorhandene Werkzeuge verwenden	+	o	o
M9 Disziplin und Entwickler-Anspruch		+
M10 Code Reviews		+
M11 Automatisierte Tests			o
M12 Selenium-Tests von Programmierern erstellen lassen
M13 Review von Fremd-Extensions
M14 Eigenentwicklungen nach Möglichkeit vorziehen
M15 Abhängigkeiten zwischen Modulen und Templates vermeiden
M16 Alternative Entwürfe evaluieren		+
M17 Schätzungen hinterfragen
M18 Pair Programming		+		+
M19 Mehr Zeitdruck
M20 „aufpassen und nachschauen“		o
M21 Abrechnung nach Aufwand
M22 Kein vorgefertigtes finales Anforderungsdokument, transparent kontinuierliche Änderung der Spezifikation
M23 Entwicklungs-, Test- und Live-Systeme synchronisieren
M24 Manuelle Unit Tests
M25 Konfigurations-Änderungen der Anwendung nur über Update-Scripts			o
M26 Informiert bleiben über aktuelle Entwicklungen, auch in der Community
M27 Ein Team aus Templatern (Frontend) und Entwicklern (Backend), an Blockern wird gemeinsam gearbeitet (Scrum-Sirene)
M28 „Technical Debt“-Philosophie: Refactoring, Clean Code		+
M29 Inkrementeller Entwurf
M30 Framework-Dokumentation
M31 Reverse Engineering
M32 Pattern Detection
M33 Visuelle Modellierung mit UML
M34 Visuelle Modellierung mit Magento-UML
M35 FDD-Prozess
M36 Testgetriebene Entwicklung (TDD)		o		o
M37 Einfacher Entwurf		o
M38 Programming by Contract		o
M39 Coding Guidelines		+
M40 SOLID Prinzipien		o
M41 Testfall-Generatoren
M42 Built-in Tests
M43 Assertion-basierte Tests
M44 Integrierte White-box Tests
M45 Test-Automatisierung systematisch entscheiden
M46 Smoke Test Suite
M47 Mutation Testing
M48 Modellbasiertes Testen
M49 Abstraktion von funktionalen Tests, automatisierte Akzeptanztests
M50 Kompatibilitätsanalyse mit FDMM

Zuordnung von Problemen und Maßnahmen beim Test

	P11 Automatisierte funktionale Tests sind aufwändig	P12 Unit Tests sind aufwändig und ineffektiv
M1 Schulung des Kunden / Product Owners
M2 Einbeziehung des Kunden in den Entwicklungsprozess
M3 Abstrakte Schätzung mit Story Points und Team Velocity
M4 Standards selber dokumentieren (basierend auf Reverse Engineering und Erfahrung)
M5 Schulungen
M6 Negativbeispiele
M7 Bei der Einstellung berücksichtigen: Erfahrung mit C#, Java u.ä. hilfreicher als mit PHP
M8 Vorhandene Werkzeuge verwenden
M9 Disziplin und Entwickler-Anspruch
M10 Code Reviews
M11 Automatisierte Tests
M12 Selenium-Tests von Programmierern erstellen lassen	o
M13 Review von Fremd-Extensions
M14 Eigenentwicklungen nach Möglichkeit vorziehen
M15 Abhängigkeiten zwischen Modulen und Templates vermeiden
M16 Alternative Entwürfe evaluieren
M17 Schätzungen hinterfragen
M18 Pair Programming
M19 Mehr Zeitdruck
M20 „aufpassen und nachschauen“
M21 Abrechnung nach Aufwand
M22 Kein vorgefertigtes finales Anforderungsdokument, transparent kontinuierliche Änderung der Spezifikation	o
M23 Entwicklungs-, Test- und Live-Systeme synchronisieren	+
M24 Manuelle Unit Tests		o
M25 Konfigurations-Änderungen der Anwendung nur über Update-Scripts
M26 Informiert bleiben über aktuelle Entwicklungen, auch in der Community
M27 Ein Team aus Templatern (Frontend) und Entwicklern (Backend), an Blockern wird gemeinsam gearbeitet (Scrum-Sirene)
M28 „Technical Debt“-Philosophie: Refactoring, Clean Code
M29 Inkrementeller Entwurf
M30 Framework-Dokumentation
M31 Reverse Engineering
M32 Pattern Detection
M33 Visuelle Modellierung mit UML
M34 Visuelle Modellierung mit Magento-UML
M35 FDD-Prozess
M36 Testgetriebene Entwicklung (TDD)
M37 Einfacher Entwurf
M38 Programming by Contract
M39 Coding Guidelines
M40 SOLID Prinzipien
M41 Testfall-Generatoren	+	–
M42 Built-in Tests		+
M43 Assertion-basierte Tests		–
M44 Integrierte White-box Tests		–
M45 Test-Automatisierung systematisch entscheiden	–	–
M46 Smoke Test Suite	+
M47 Mutation Testing	o	o
M48 Modellbasiertes Testen	+	–
M49 Abstraktion von funktionalen Tests, automatisierte Akzeptanztests	+
M50 Kompatibilitätsanalyse mit FDMM	–

Zuordnung von Problemen und Maßnahmen bei der Integration

	P13 Geringe Code-Qualität von Fremd-Extensions	P14 Mehrere Schleifen zwischen Layoutern, Templatern und Entwicklern	P15 Für Entwickler aufwändige Einarbeitung in Werkzeuge	P16 Fehleranfälliges Deployment
M1 Schulung des Kunden / Product Owners
M2 Einbeziehung des Kunden in den Entwicklungsprozess
M3 Abstrakte Schätzung mit Story Points und Team Velocity
M4 Standards selber dokumentieren (basierend auf Reverse Engineering und Erfahrung)
M5 Schulungen
M6 Negativbeispiele
M7 Bei der Einstellung berücksichtigen: Erfahrung mit C#, Java u.ä. hilfreicher als mit PHP			o
M8 Vorhandene Werkzeuge verwenden				o
M9 Disziplin und Entwickler-Anspruch	o
M10 Code Reviews
M11 Automatisierte Tests
M12 Selenium-Tests von Programmierern erstellen lassen
M13 Review von Fremd-Extensions	o
M14 Eigenentwicklungen nach Möglichkeit vorziehen	o
M15 Abhängigkeiten zwischen Modulen und Templates vermeiden		o
M16 Alternative Entwürfe evaluieren
M17 Schätzungen hinterfragen
M18 Pair Programming
M19 Mehr Zeitdruck
M20 „aufpassen und nachschauen“
M21 Abrechnung nach Aufwand
M22 Kein vorgefertigtes finales Anforderungsdokument, transparent kontinuierliche Änderung der Spezifikation
M23 Entwicklungs-, Test- und Live-Systeme synchronisieren
M24 Manuelle Unit Tests	o			o
M25 Konfigurations-Änderungen der Anwendung nur über Update-Scripts
M26 Informiert bleiben über aktuelle Entwicklungen, auch in der Community				o
M27 Ein Team aus Templatern (Frontend) und Entwicklern (Backend), an Blockern wird gemeinsam gearbeitet (Scrum-Sirene)		+
M28 „Technical Debt“-Philosophie: Refactoring, Clean Code
M29 Inkrementeller Entwurf
M30 Framework-Dokumentation
M31 Reverse Engineering
M32 Pattern Detection
M33 Visuelle Modellierung mit UML
M34 Visuelle Modellierung mit Magento-UML
M35 FDD-Prozess
M36 Testgetriebene Entwicklung (TDD)
M37 Einfacher Entwurf
M38 Programming by Contract
M39 Coding Guidelines
M40 SOLID Prinzipien
M41 Testfall-Generatoren
M42 Built-in Tests
M43 Assertion-basierte Tests
M44 Integrierte White-box Tests
M45 Test-Automatisierung systematisch entscheiden
M46 Smoke Test Suite
M47 Mutation Testing
M48 Modellbasiertes Testen
M49 Abstraktion von funktionalen Tests, automatisierte Akzeptanztests
M50 Kompatibilitätsanalyse mit FDMM

Zuordnung von Problemen und Maßnahmen für allgemeine Probleme

	P17 Hinterhof-Image	P18 Viele Change Requests
M1 Schulung des Kunden / Product Owners		o
M2 Einbeziehung des Kunden in den Entwicklungsprozess		o
M3 Abstrakte Schätzung mit Story Points und Team Velocity
M4 Standards selber dokumentieren (basierend auf Reverse Engineering und Erfahrung)
M5 Schulungen
M6 Negativbeispiele
M7 Bei der Einstellung berücksichtigen: Erfahrung mit C#, Java u.ä. hilfreicher als mit PHP
M8 Vorhandene Werkzeuge verwenden
M9 Disziplin und Entwickler-Anspruch
M10 Code Reviews
M11 Automatisierte Tests
M12 Selenium-Tests von Programmierern erstellen lassen
M13 Review von Fremd-Extensions
M14 Eigenentwicklungen nach Möglichkeit vorziehen
M15 Abhängigkeiten zwischen Modulen und Templates vermeiden
M16 Alternative Entwürfe evaluieren
M17 Schätzungen hinterfragen
M18 Pair Programming
M19 Mehr Zeitdruck
M20 „aufpassen und nachschauen“
M21 Abrechnung nach Aufwand		o
M22 Kein vorgefertigtes finales Anforderungsdokument, transparent kontinuierliche Änderung der Spezifikation		o
M23 Entwicklungs-, Test- und Live-Systeme synchronisieren
M24 Manuelle Unit Tests
M25 Konfigurations-Änderungen der Anwendung nur über Update-Scripts
M26 Informiert bleiben über aktuelle Entwicklungen, auch in der Community
M27 Ein Team aus Templatern (Frontend) und Entwicklern (Backend), an Blockern wird gemeinsam gearbeitet (Scrum-Sirene)
M28 „Technical Debt“-Philosophie: Refactoring, Clean Code
M29 Inkrementeller Entwurf
M30 Framework-Dokumentation
M31 Reverse Engineering
M32 Pattern Detection
M33 Visuelle Modellierung mit UML
M34 Visuelle Modellierung mit Magento-UML
M35 FDD-Prozess
M36 Testgetriebene Entwicklung (TDD)
M37 Einfacher Entwurf
M38 Programming by Contract
M39 Coding Guidelines
M40 SOLID Prinzipien
M41 Testfall-Generatoren
M42 Built-in Tests
M43 Assertion-basierte Tests
M44 Integrierte White-box Tests
M45 Test-Automatisierung systematisch entscheiden
M46 Smoke Test Suite
M47 Mutation Testing
M48 Modellbasiertes Testen
M49 Abstraktion von funktionalen Tests, automatisierte Akzeptanztests
M50 Kompatibilitätsanalyse mit FDMM

Legende

+	anwendbar
o	teilweise anwendbar
–	nicht anwendbar