Verhaltensgesteuerte Entwicklung: Der endgültige Leitfaden • BUOM

29. Juli 2021

Bei der Entwicklung von Software im Team ist Kommunikation wichtig. Durch verhaltensgesteuerte Entwicklung (BDD) können alle Beteiligten verstehen, was ein Softwareprojekt bewirkt, unabhängig von ihrem technischen Hintergrund. Das Erlernen der Grundlagen der verhaltensbasierten Entwicklung kann Ihnen dabei helfen, festzustellen, ob diese Methode Ihrem Projekt in der Produktion helfen kann. In diesem Artikel erklären wir Ihnen, wie Sie verhaltensgesteuerte Entwicklung in Ihren Projekten einsetzen können und welche Vor- und Nachteile diese Methode hat.

Was ist verhaltensbasierte Entwicklung?

Verhaltensgesteuerte Entwicklung ist eine Softwareentwicklungsmethode, bei der Programmcode in eine zugängliche Sprache übersetzt wird. Dadurch können Kunden Programmverhaltensziele in einem Format definieren, das jeder, einschließlich Entwickler, verstehen kann. BDD ermutigt alle an einem Projekt Beteiligten, sich auf das zu konzentrieren, was das Programm tun soll, und nicht auf die Details des Codes. Jeder Teilnehmer, der ein Ziel für die Software definieren möchte, definiert das Verhalten, wann das Verhalten auftritt und welche Ergebnisse das Verhalten in einer domänenspezifischen Sprache (DSL) hervorruft. DSL ist eine Programmiersprache, die sich auf bestimmtes Softwareverhalten konzentriert.

BDD verwendet auch Elemente der testgetriebenen Entwicklung (TDD), einer Codetesttechnik, die die Analyse wiederholt, bis der Projektcode so minimal und präzise wie möglich ist. Durch die Verwendung von TDD-Codeelementen trägt BDD dazu bei, die Kommunikation und minimale Programmierung während des gesamten Projekts zu fördern.

So nutzen Sie verhaltensgesteuerte Entwicklung

Wenn Sie planen, verhaltensbasierte Entwicklung für Ihr Projekt zu verwenden, sehen Sie sich einige der folgenden Schritte an:

1. Besprechen Sie die Software

Beginnen Sie damit, die Software mit Ihrem gesamten Team zu besprechen. Finden Sie heraus, was der Kunde von der Software erwartet, einschließlich der Parameter, die das Codierungsverhalten definieren und was das Codierungsverhalten bewirkt. Um den Diskussionsprozess zu beschleunigen, sollten Sie das folgende Vorlagenformat verwenden:

Weiter (Listen Sie die grundlegenden Anforderungen auf, um das Codierungsverhalten zu starten)

Zusätzlich (Listen Sie alle zusätzlichen Anforderungen auf, um das Codierungsverhalten zu starten.)

Code (Listen Sie auf, welche Parameter das Codierungsverhalten verursachen)

потом (Listen Sie auf, was das Codierungsverhalten verursacht)

Ein Beispiel für eine Kundenanfrage könnte sein:

Vorausgesetzt, der Benutzer befindet sich auf der Startseite.

Und der Benutzer geht zur Anmeldeseite.

Wenn der Benutzer Informationen eingibt: Benutzername, Passwort

Der Benutzer befindet sich dann auf der Profilseite

2. Setzen Sie Ziele basierend auf Verhaltenserwartungen.

Nachdem Sie alle Kundenanfragen gesammelt haben, erstellen Sie Ziele basierend auf den Anfragen. Ihr Team kann Anforderungen an Codierungsbeschränkungen anpassen oder Ideen verfeinern, bevor mit dem Codieren begonnen wird. Versuchen Sie vor Beendigung des Meetings, so viele Anfragen wie möglich zu dokumentieren. Das Dokumentieren von Ideen kann bei der Kommunikation außerhalb des Meetings hilfreich sein. Kunden können sich an Programmierer wenden, um Anpassungen vorzunehmen, Ideen zu klären oder Verhaltensweisen aus der Codierungsliste zu entfernen.

3. Ziele auf DSL umstellen

Nach der ersten Diskussion können Programmentwickler mit der Codierung von Verhaltensanforderungen in die DSL beginnen. Ermutigen Sie die Teammitglieder, Aktualisierungen des Codierungsprozesses, Verhaltensanpassungen und alle neuen angeforderten Verhaltensweisen mitzuteilen. Erwägen Sie die Abhaltung zusätzlicher Besprechungen, um die Ergebnisse des DSL-Codes zu überprüfen, das Arbeitsprodukt zu testen und Fragen von Teammitgliedern zu beantworten.

4. Verhalten testen und dokumentieren

Sobald die Entwickler alle Verhaltensweisen im DSL codiert haben, beginnen Sie mit der Dokumentation der DSL-Codes mit dem Verhalten des Programms. Wenn neue Mitglieder dem Projekt beitreten, kann ihnen die DSL-Dokumentation helfen, den Status und das Verhalten des Projekts zu verstehen. Nachdem das gesamte Verhalten des DSL-Codes programmiert und dokumentiert wurde, kann das Programmierteam nun User Stories erstellen. Die User-Story-Vorlage sieht so aus:

Geschichte: (Eine einzeilige Zusammenfassung des gesamten Codeverhaltens)

Erzählung:

Seit (Name des Benutzers)

Ich möchte (Das Ergebnis des Codeverhaltens)

Damit ich es kann (Zusammenfassung des Zwecks des Codeverhaltens)

Akzeptanzkriterien (dargestellt als Szenarien):

Szenario: (Listen Sie die grundlegenden Anforderungen auf, um das Codierungsverhalten zu starten)

In Anbetracht dessen (Listen Sie alle zusätzlichen Anforderungen auf, um das Codierungsverhalten zu starten)

Code (Listen Sie auf, welche Parameter das Codierungsverhalten verursachen)

Затем (Listen Sie auf, was das Codierungsverhalten verursacht)

И (Listen Sie auf, was das Codierungsverhalten sonst noch verursacht)

Unten finden Sie eine Beispiel-User-Story:

Verlauf: Der Kontoinhaber meldet sich beim Konto an

Als Kontoinhaber

Ich möchte mich in mein Konto einloggen

Damit ich auf meine Informationen zugreifen kann

Szenario: Konto entsperrt

Vorausgesetzt, der Benutzer hat drei fehlgeschlagene Passwortversuche nicht eingegeben

Wenn der Kontoinhaber den richtigen Benutzernamen und das richtige Passwort eingibt

Der Kontoinhaber meldet sich dann bei seinem Konto an

Und der Kontoinhaber wird auf seine Profilseite weitergeleitet.

Vorteile einer verhaltensorientierten Entwicklung

Zu den Vorteilen der verhaltensbasierten Entwicklung gehören:

Verbessert die Kommunikation

Verhaltensgesteuerte Entwicklung fördert das Feedback aller Projektbeteiligten. Mit der Zugänglichkeit von BDD können ganze Teams, Abteilungen oder Unternehmen neue Ideen und Projektfunktionen kommunizieren. Teams ohne Softwareentwickler können Programme erstellen, Probleme beheben und neue Lösungen entwickeln, um Zeit zu sparen und Software zu verbessern. Da BDD eine verständliche Sprache verwendet, können Stakeholder leicht verstehen, was das aktuelle Produkt leistet, und klären, wie sie es verbessern möchten.

Reduziert Codefehler

Da BDD in jeder Entwicklungsphase TDD verwendet, sind Codefehler im endgültigen Projekt selten. TDD überwacht und testet ständig die Codebasis, auch wenn niemand im Team den Code anpasst. Wenn Programmierer neuen Code schreiben oder vorhandenen Code ändern, verringert TDD die Wahrscheinlichkeit von Codefehlern im Endprodukt.

Fördert minimale Codierung

TDD fördert eine minimale Codierung während seiner Prozesse. Wenn ein Projektmitglied eine neue Codezeile schreibt, prüft TDD den Code sowohl auf Fehler als auch auf minimalen Code. Einige TDD-Programme ändern automatisch Codezeilen. Selbst wenn Teammitglieder nicht am Code eines Projekts arbeiten, kürzt TDD ihn kontinuierlich, um die Programmierdichte zu verringern.

Verhaltensentwicklungsdefizite

Zu den potenziellen Nachteilen der verhaltensbasierten Entwicklung gehören:

DSL-Verschlüsselung erforderlich

Die verfügbare BDD-Sprachkodierung erfordert einen DSL-Programmierschritt. Nach der Validierung der Kundenanfragen erstellen die Programmierer des Teams DSL-Code für jeden Befehl, den BDD verwendet. Darüber hinaus dokumentieren Programmierer auch die DSL-Programmierung und ihre Definitionen für ein umfassendes Verständnis des Befehls. Für größere Teams dürften Dokumentation und Programmierung kein Hindernis darstellen. Für kleinere Teams können diese beiden zusätzlichen Prozesse eine Herausforderung darstellen. Einige Unternehmen könnten jedoch von der verbesserten Zugänglichkeit durch zusätzliche Dokumentation profitieren.

Verlässt sich auf Kundenbewertungen

Die BDD-Programmierung erfordert Kundenfeedback, um ein funktionierendes Produkt zu entwickeln. Da Teams während Besprechungen und in der Kommunikation BDD-Verhaltensweisen entwickeln, erfordert jede weitere Programmierung nach der ersten Besprechung zusätzliche Diskussionen. Teams, die BDD verwenden, berichten häufig über neue Funktionen, Erweiterungen und Lösungen für das Produkt. Da BDD für jede neue Aktion eine DSL-Codierung erfordert, kann sich die Produktion verlangsamen, wenn keine Codierungsexperten verfügbar sind. Eine derart häufige Kommunikation zwischen Kunden und Entwicklern kann jedoch die Konsistenz von Ideen und Zielen gewährleisten und dazu beitragen, kostspielige Änderungen in der Postproduktion zu vermeiden.

Verwendet ständige Tests

Während TDD-Tests dazu beitragen, Fehler im Endprodukt zu verhindern, können sie auch die Produktion verlangsamen. Im Gegensatz zu anderen Codierungstechniken erlaubt TDD Programmierern nicht, ineffizienten Code zu schreiben. Projektstandards erfordern möglicherweise zunächst TDD-Anforderungen, aber wenn sich die Projektstandards des Teams ändern, bleibt TDD bestehen. Obwohl es ein Projekt verlangsamen kann, können Unternehmen von seinen Fehlerreduzierungsprozessen profitieren.