code4business Software GmbH - Magento Associate

Ü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 AnforderungenP2 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 falschP4 Formaler Entwurf ist erschwertP5 Know-How von erfahrenen Entwicklern wird nicht ausgeschöpftP6 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 verwendetP8 Geringe Code-QualitätP9 Unerwartete SeiteneffekteP10 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ändigP12 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 lasseno
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 Spezifikationo
M23 Entwicklungs-, Test- und Live-Systeme synchronisieren+
M24 Manuelle Unit Testso
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 Testingoo
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-ExtensionsP14 Mehrere Schleifen zwischen Layoutern, Templatern und EntwicklernP15 Für Entwickler aufwändige Einarbeitung in WerkzeugeP16 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-ImageP18 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
oteilweise anwendbar
-nicht anwendbar

Trackbacks für diesen Eintrag.

  1. Forschungsarbeit Carbon Development Process | Magento Agentur und Entwicklung

Antwort hinterlassen