Das steckt hinter Component Driven Development

Nahezu alle Bereiche in der Projektentwicklung durchlaufen stetig einen Weiterentwicklungsprozess – alles wird agiler, spezifischer und vor allem priorisierter. Das gilt natürlich in großen Teilen für die Entwicklung, aber auch immer mehr im Design bzw. Frontend werden neue Arbeitsmethoden präsenter. Ein Beispiel dafür ist das Component Driven Development. Was hinter diesem Begriff steckt, beschreiben wir hier.

Niemals alles der Reihe nach

Bevor wir genauer auf die Eigenschaften von Component Driven Development (CDD) eingehen, macht es Sinn, sich die Beweggründe für eine Anpassung der Arbeitsweise anzuschauen. Jede Weiterentwicklung ist die Konsequenz aus gesammelten Erfahrungen und dem natürlichen Drang, Arbeitsprozesse zu optimieren. In der Projektentwicklung ist dies vor allem die Agilität, die ständig neue Ansätze etabliert. So wurde zum Beispiel die einst beliebte Wasserfallmethode nahezu vollständig von agilen Methoden abgelöst, die es den Entwicklungsteams leichter macht, auf Änderungen und neue Anforderungen zu reagieren.

Dieses Beispiel lässt sich auch sehr gut auf das Design und die Frontend-Entwicklung projizieren: In der Vergangenheit (bei einigen Unternehmen auch noch aktuell) wurde zuerst das Konzept entwickelt, danach das Design, das darauf basieren soll und ganz Schluss erfolgte erst die Umsetzung. Dieses Vorgehen klingt zunächst sehr plausibel, schließlich wird die Arbeit immer mit einem genauen Plan im Hinterkopf angegangen. Aber wie bei der Wasserfallmethode hatte das Ganze ein paar Haken und führt im Regelfall zu folgenden Problemen:

• Lange Umsetzungsdauer: Dadurch, dass alles Stück für Stück und der Reihe nach entwickelt wird, kann es zu Verzögerungen kommen und Teile, die weniger komplex und deshalb schneller umzusetzen sind, bleiben liegen, weil sie noch nicht „an der Reihe sind“.
• Verzögerung bei Testing und Feedback: Aufbauend auf dem vorangegangenen Problem kommt es logischerweise auch zu Verzögerungen beim Testing, weil immer die komplette Entwicklung abgewartet werden muss, bevor sich das Qualitätsmanagement an die Arbeit machen kann. Darüber hinaus kann ein gefundener Bug, der ganz am Anfang bei der Entwicklung entstanden ist, eine komplette Neuentwicklung verursachen. Dies wäre für Kunde und Dienstleister ohne Zweifel die schlimmste anzunehmende Situation.
• Handlungsmöglichkeiten erst zum Schluss: Wie bereits erwähnt, tauchen durch diese Arbeitsmethode Probleme oder Herausforderungen mit dem Konzept oder dem Design nur in der letzten Phase auf. So fällt zum Beispiel erst bei der Umsetzung auf, dass eine Idee technisch gar nicht umsetzbar ist, Designs inkonsequent sind oder gar das ganze Konzept unklar ist.

Bei dieser Übersicht wird schnell klar, dass der „althergebrachte Weg“ Probleme mit sich bringt, die alle zusammenhängen und sich gegenseitig verstärken – es entsteht sozusagen ein ganzer Rattenschwanz an Schwierigkeiten. So startete im Design ein Umdenken, auf welche Weise sich diese Problemkette verhindern lässt. Eine Antwort darauf ist eben Component Driven Development, quasi das Frontend-Äquivalent der agilen Entwicklung.

Component Driven Development ist die Verbindung mehrerer Ansätze

Nicht nur die Herangehensweise der Frontend-Entwicklung hat sich weiterentwickelt, sondern natürlich auch die Frontend-Architektur selbst. Wie im gesamten Spektrum des E-Commerce gilt auch hier: Neue Technologien erfordern neue Wege. Ein großer Umbruch für das Frontend war zum Beispiel das Aufkommen der Headless-Technologie. Mehrere Einzelteile ergeben ein schnelleres, flexibleres und agiles großes Ganzes. Und so ähnlich lässt sich auch der Ansatz des Component Driven Developments beschreiben. Wie der Name schon verrät, wird die Entwicklung auf einzelne Komponenten aufgeteilt und priorisiert.

Demnach werden Designs nicht mehr seitenbasiert gestaltet, sondern fußen eben auf den jeweiligen Komponenten. Mehrere Komponenten zusammengesetzt und kombiniert ergeben schließlich eine fertige Seite, die einem konsequenten Design-Konzept folgt. Man kann sich diese Art der Entwicklung also ungefähr wie einen Website-Baukasten vorstellen, in dem es vorgefertigte Elemente wie Slides, Infoboxen, Textbereiche gibt.

Da die einzelnen Komponenten unabhängig voneinander entwickelt werden, lassen sie sich auch einzeln testen und zu Demonstrationszwecken anwenden. Allein diese Tatsache kann sämtliche oben genannte Probleme von vornerein verhindern.

Außerdem: Im Gegensatz zu dem seitenbasierten Design, lassen sich die Komponenten durch ihre Unabhängigkeit zum einen parallel entwickeln und können zum anderen jederzeit weiterentwickelt werden, ohne dass das ganze Konzept dann nicht mehr passt.

Iterative Zusammenarbeit ist auch im Design die beste Wahl

Eigentlich ist Component Driven Development vom Ansatz her streng betrachtet gar nichts sonderlich Neues – schließlich basiert es auf der UNIX-Philosophie. Und natürlich klingt das Ganze auch nicht ganz unbeabsichtigt wie ein auf das Design getrimmter Klon der agilen Projektmethode.

[otw_shortcode_info_box border_type=“bordered“ border_color_class=“otw-black-border“ border_style=“bordered“ rounded_corners=“rounded-10″ background_color_class=“otw-silver“]UNIX-Methode

Die UNIX-Methode ist eine Entwicklungsphilosophie von Douglas McIlroy, der als Pionier der Komponenten-basierten Entwicklung gilt, auf der auch das gleichnamige UNIX-Betriebssystem basiert. Im Wesentlichen lässt sich die Philosophie in drei Haupteigenschaften, die eine Software haben sollte, aufteilen:

Die Komponenten sollten…

• nur eine Aufgabe erledigen und diese auch gut machen
• so programmiert sein, dass sie mit den anderen Komponenten kompatibel sind
• eine universelle Schnittstelle verstehen und zwar die der Verarbeitung von Textströmen.

Vor allem die ersten beiden Eigenschaften finden sich zum Beispiel im Component Driven Development sehr stark wieder.[/otw_shortcode_info_box]

Agile Methoden passen in ihrem Ansatz sehr gut mit Component Driven Development zusammen und lösen wie bereits erwähnt viele der genannten Probleme. Außerdem ist die Ähnlichkeit von CDD mit agilen Projektmethoden nur logisch, denn so fügt sich das Design nahtlos in die restlichen Projektabläufe ein.

Zusammengefasst: Wenn die Bereiche UX (Design und Konzept) und IT (Entwicklung und Systemadministration) in diesem Arbeitsmodus zusammenarbeiten, entstehen folgende Vorteile:

• schneller Feedbackzyklus
• Aufgaben können leichter aufgeteilt, parallel entwickelt und priorisiert werden
• Transparenz – jeder Schritt ist für alle Projektbeteiligten und Stakeholders ersichtlich
• Komponenten sind abgekapselt („sandboxed“) und sind leichter zu testen, weil sie sich überall gleich verhalten.

Auch wenn Component Driven Development – genau wie bisweilen viele Weiterentwicklungen im E-Commerce und in der Projektentwicklung – wie ein weiteres Buzzword rüberkommt, hat diese Methode doch absolut ihre Daseinsberechtigung. Und ist deshalb nicht umsonst mittlerweile eine weit verbreitete Herangehensweise beim Design und der Frontend-Entwicklung.

Bild: freepik