Beim Durchblättern von Artikeln zum Software-Design stieß ich ständig auf eine Wolke beispielloser Abkürzungen und beiläufig erwähnter Entwicklungspraktiken.

• TDD - Nun, jeder weiß das. Zuerst schreiben wir Tests und dann den Rest des Codes.
• BDD ist etwas Vertrautes, ähnlich wie Tests, aber spezielle.
• TDD - Schon wieder? Also hör auf, hier geht es überhaupt nicht um Tests. Aber warum heißt es das gleiche?
• DDD- gebundene Kontexte, allgegenwärtige Sprache, Domäne ...
• FDD - Ja, wie viel ist möglich?
• MDD - Ernsthaft, Diagrammbasiert?
• PDD - ...

Entwicklungsansätze sind nach Komplexität, Anwendungsbereichen und Zielen unterteilt.
Ich denke, es ist an der Zeit herauszufinden, warum sie gebraucht werden, warum es so viele von ihnen gibt und wie sie für uns nützlich sein können.

Wir werden beginnen, sie von den einfachsten bis zu den komplexesten kennenzulernen, Anwendungsbeispiele und die Vor- und Nachteile jedes einzelnen von ihnen zu betrachten.

TDD - Testgetriebene Entwicklung

TDD ist eine Softwareentwicklungsmethode, die auf der Wiederholung kurzer Entwicklungszyklen basiert: Zunächst wird ein Test geschrieben, der die gewünschte Änderung abdeckt, dann wird Programmcode geschrieben, der das gewünschte Systemverhalten implementiert und es Ihnen ermöglicht, den schriftlichen Test zu bestehen. Dann wird der geschriebene Code mit ständigem Testen der Tests überarbeitet.

Es klingt einfach und klar. Viele kennen diesen Entwicklungsansatz, und sogar Onkel Bob selbst fördert ihn aktiv.

TDD wird als eine Form der ordnungsgemäßen Anwendungskonstruktion angesehen. Die testgetriebene Entwicklungsphilosophie lautet, dass Ihre Tests eine Spezifikation des Verhaltens Ihres Programms sind. Wenn Sie Ihre Testsuite als obligatorischen Bestandteil des Erstellungsprozesses betrachten und Ihre Tests fehlschlagen, wird das Programm nicht erstellt, da es falsch ist. Die Einschränkung besteht natürlich darin, dass die Richtigkeit Ihres Programms nur als Vollständigkeit Ihrer Tests definiert wird. Studien haben jedoch gezeigt, dass eine auf Tests basierende Entwicklung Fehler in der Produktion um 40-80% reduzieren kann.

Wenn Sie TDD verwenden, haben Sie möglicherweise das Gefühl, langsamer als gewöhnlich zu laufen. Dies liegt daran, dass Sie außerhalb der „Komfortzone“ arbeiten, und dies ist ganz normal.

Sobald Sie das Gefühl haben, dass das Schreiben von Tests zu einem einfachen und natürlichen Bestandteil des Workflows geworden ist und Sie bei der Arbeit an einem Projekt nicht mehr über die Verwendung von TDD nachdenken müssen, stellen Sie fest, dass TDD in Ihre Arbeit eingeflossen ist.

Diese Methodik ermöglicht es uns, eine Anwendung zu erstellen, die für automatische Tests geeignet ist, und eine sehr gute Abdeckung des Codes mit Tests, da TK in die Sprache der automatischen Tests übersetzt wird, dh alles, was das Programm tun sollte, wird überprüft. TDD vereinfacht häufig auch die Softwareimplementierung: Die Redundanz der Implementierung wird beseitigt. Wenn eine Komponente den Test besteht, gilt sie als bereit.

Die Architektur der auf diese Weise entwickelten Softwareprodukte ist normalerweise besser (in Anwendungen, die für automatische Tests geeignet sind, ist die Verantwortung zwischen den Komponenten normalerweise sehr gut verteilt, und komplexe Verfahren, die ausgeführt werden, werden in viele einfache zerlegt). Die Stabilität der durch Tests entwickelten Anwendung ist höher, da alle grundlegenden Funktionen des Programms durch Tests abgedeckt werden und ihre Leistung ständig überprüft wird. Die Begleitung von Projekten, bei denen alles oder fast alles getestet wird, ist sehr hoch - Entwickler haben möglicherweise keine Angst davor, Änderungen am Code vorzunehmen. Wenn etwas schief geht, werden die Ergebnisse der automatischen Tests darüber informieren.

Weitere Informationen zu TDD-Prinzipien finden Sie in Kent Becks Buch Extreme Programming. Development through Testing.

TDD - Typgesteuerte Entwicklung

Typgesteuerte Entwicklung wird ebenso wie Entwicklung durch Testen abgekürzt, daher wird normalerweise der vollständige Name geschrieben.

Bei der Entwicklung auf der Basis von Typen sind Ihre Datentypen und Typensignaturen eine Spezifikation des Programms. Typen dienen auch als Dokumentationsform, die garantiert aktualisiert wird.

Typen sind kleine Kontrollpunkte, dank derer wir in unserer gesamten Anwendung viele Minitests erhalten. Darüber hinaus sind die Kosten für die Erstellung von Typen minimal und eine Aktualisierung ist nicht erforderlich, da sie Teil der Codebasis sind.

Die Entwicklung nach Typ ist eine weitere gute Methode zum Erstellen einer Anwendung. Wie bei der testbasierten Entwicklung kann die typbasierte Entwicklung Ihr Vertrauen in Ihren Code erhöhen und Ihnen Zeit sparen, wenn Sie Änderungen an einer großen Codebasis vornehmen.

Von den Minuspunkten nur die zunehmende Komplexität von Sprachen mit dynamischer Typisierung. Für JavaScript ist dieser Ansatz beispielsweise schwieriger anzuwenden als für TypeScript.

Auf einem Habr gibt es einen ausgezeichneten Artikel über das Tippen.

BDD - Verhaltensorientierte Entwicklung

Aufgrund einiger methodischer Ähnlichkeiten werden TDD (Test Driven Development) und BDD (Behavior Driven Development) selbst von Fachleuten häufig verwechselt. Was ist der Unterschied? Die Konzepte beider Ansätze sind ähnlich, zuerst werden Tests durchgeführt und erst dann beginnt die Entwicklung, aber ihr Zweck ist völlig anders. Bei TDD geht es mehr um das Programmieren und Testen auf der technischen Implementierungsebene des Produkts, wenn die Tests von den Entwicklern selbst erstellt werden. Bei BDD handelt es sich um einen Tester oder Analysten, der benutzerdefinierte Skripte in einer natürlichen Sprache beschreibt - wenn ich so sagen darf, in der Geschäftssprache.

BDD - Verhaltensorientierte Entwicklung ist eine verhaltensbasierte Entwicklung. Eine bestimmte Person (oder Personen) schreibt Beschreibungen des Formulars "Als Benutzer möchte ich, wenn die Starttaste gedrückt wird, wurde das Menü wie im Bild angezeigt" (es gibt speziell hervorgehobene Schlüsselwörter). Programmierer haben lange Zeit spezielle Tools geschrieben, die solche Beschreibungen in Tests übersetzen (manchmal für den Programmierer völlig transparent). Und dann die klassische Entwicklung mit Tests.

Wenn Sie die Namen der Tests in Form von Sätzen aufzeichnen und das Vokabular der Geschäftsdomäne verwenden, um die Namen der Methoden zu schreiben, wird die erstellte Dokumentation für Kunden, Analysten und Tester klar.

Skripttexte werden in einer bestimmten Form geschrieben.

Mit (ca. Gegeben - Gegeben) einen Kontext haben,

Wenn (beachten Sie, wann) ein Ereignis eintritt,

Dann (ca. Dann) das Ergebnis überprüfen.

So etwas könnte passieren:

Oder ein anderes Beispiel auf Russisch:

Szenario 1: Auf dem Konto + befindet sich Geld

Ein Konto mit Geld haben

Und eine gültige Karte

Und ein Geldautomat mit Bargeld

Wenn ein Kunde Bargeld anfordert

Stellen Sie dann sicher, dass das Konto belastet wurde

Und stellen Sie sicher, dass Bargeld ausgegeben wird

Und stellen Sie sicher, dass die Karte zurückgegeben wird

Der BDD-Ansatz ermöglichte es uns zusammen mit den Konstruktionspraktiken, die Legacy-Dokumentation mit irrelevanten Informationen aufzugeben und neue Dokumentation im laufenden Betrieb zu erhalten und zusammen mit dem Projekt zu speichern, wodurch Analysten und Tester näher an den Code heranrückten.

BDD ist eher ein Prozess, dessen Ziel es ist, die Kosten für die Implementierung neuer Funktionen zu senken. Schon zu Beginn der Entwicklung erhalten wir wichtige Artefakte. Zum Beispiel Dokumentation, deren Unterstützung verständlich ist. Diese Dokumentation bietet allen interessierten Parteien die Möglichkeit, sich ein Bild von den Produkt- und Benutzerverhaltensszenarien zu machen, die während der Entwicklungsiterationen implementiert werden sollten. Mit dem BDD-Ansatz senken wir auch den Schwellenwert für neue Mitglieder, um an dem Projekt teilzunehmen.

Was ist der Vorteil von BDD?

• Lesbare Tests für Nicht-Programmierer.
• Sie sind leicht zu ändern. Sie werden oft in fast reinem Englisch geschrieben.
• Sie können vom Produktbesitzer oder anderen interessierten Parteien geschrieben werden.
• Die Testergebnisse sind humaner.
• Tests sind unabhängig von der Zielprogrammiersprache. Die Migration in eine andere Sprache wird erheblich vereinfacht.

Nachteile:

Dieser Ansatz hat jedoch seine Nachteile - er ist lang und teuer. BDD ist unpraktisch, selbst wenn Testspezialisten bereits in der Entwicklungsphase einbezogen werden müssen, was den Entwicklungszyklus verlängert.

Der Ausweg aus dieser Situation kann die Wahl eines geeigneten BDD-Frameworks und ordnungsgemäß erstellter Entwicklungsprozesse sein.

Lesen Sie hier mehr über BDD.

Viele haben lange verstanden, dass Tests eine Art Allheilmittel für alle Krankheiten sind, aber ist es wirklich so? Natürlich funktioniert gründlich getesteter Code stabiler und vorhersehbarer, aber Tests bewahren uns nicht vor Problemen und Fehlern in der Entwurfs- und Aufgabeneinstellungsphase. Die folgenden Entwicklungsansätze können Ihnen dabei helfen.

DDD - Domain Driven Design

Subjektorientiertes Design ist keine spezifische Technologie oder Methodik. DDD ist eine Reihe von Regeln, mit denen Sie die richtigen Entwurfsentscheidungen treffen können. Dieser Ansatz kann den Entwurf von Software in einem unbekannten Bereich erheblich beschleunigen.

Subjektorientiertes Design (seltener problemorientiert, Englisch. Domain-gesteuertes Design, DDD) ist eine Reihe von Prinzipien und Schemata, die darauf abzielen, optimale Objektsysteme zu schaffen. Der Entwicklungsprozess besteht darin, Software-Abstraktionen zu erstellen, die als Domänenmodelle bezeichnet werden. Diese Modelle umfassen Geschäftslogik, die eine Beziehung zwischen den tatsächlichen Bedingungen des Anwendungsbereichs des Produkts und dem Code herstellt.

Der DDD-Ansatz ist besonders nützlich in Situationen, in denen der Entwickler kein Spezialist auf dem Gebiet des entwickelten Produkts ist. Beispiel: Ein Programmierer kann nicht alle Bereiche kennen, in denen Software erstellt werden muss. Mithilfe einer korrekten Darstellung der Struktur kann er jedoch mithilfe eines themenorientierten Ansatzes problemlos eine Anwendung entwerfen, die auf wichtigen Punkten und Kenntnissen des Arbeitsbereichs basiert.

In diesem Artikel versuche ich, die Essenz jedes Ansatzes für die Softwareentwicklung zu vermitteln, aber über DDD können Sie mehr als einen Artikel schreiben und alle Nuancen in mehreren Absätzen behandeln. Das wird für mich nicht funktionieren. Daher werde ich beim Erklären erklärende Links zu den wertvollsten Quellen bereitstellen.

Das Hauptziel von Domain-Driven Design ist es, die Komplexität von Geschäftsprozessen, deren Automatisierung und Implementierung in Code zu bekämpfen. "Domain" bedeutet "Domain", und Entwicklung und Design im Rahmen dieses Ansatzes werden von der Domain verdrängt.

Das Schlüsselkonzept in DDD ist die allgegenwärtige Sprache. Die allgegenwärtige Sprache fördert die transparente Kommunikation zwischen den Projektteilnehmern. Er ist nicht einer in dem Sinne, dass er einer für alle Gelegenheiten ist. Im Gegenteil. Alle Teilnehmer kommunizieren darin, alle Diskussionen finden in einer einzigen Sprache statt, und alle Artefakte sollten in einer einzigen Sprache dargestellt werden, dh beginnend mit TK und endend mit einem Code.

Das nächste Konzept ist das „Domain-Modell“. Dieses Modell ist ein Glossar von Begriffen aus der allgegenwärtigen Sprache. Sowohl das Domänenmodell als auch die allgegenwärtige Sprache sind durch den Kontext begrenzt, den Domain-Driven Design als begrenzten Kontext bezeichnet. Er schränkt das Domänenmodell so ein, dass alle darin enthaltenen Konzepte eindeutig sind und jeder versteht, worum es geht.

Beispiel: Nehmen Sie die Entität "Person" und stellen Sie sie in den Kontext "öffentliches Sprechen". In diesem Zusammenhang wird er laut DDD Sprecher oder Sprecher. Und im Kontext von "Familie" - einem Ehemann oder Bruder.

Nun zum Code. Es ist wichtig, dass Ihr Code wie ein Buch gelesen wird, dass er für jeden, der die gemeinsame Sprache des Projekts spricht, einfach und verständlich ist. Was meine ich

Wenn Sie in der Projektsprache den Ausdruck "Das Produkt wurde hinzugefügt" verwenden, ist die folgende Option nicht DDD:

var product = neues Produkt ('Apfel')

product.save ()

Warum? Der Code besagt, dass wir das Produkt auf seltsame Weise erstellt und gespeichert haben. Wie füge ich trotzdem ein Produkt hinzu? Müssen Sie es hinzufügen . Hier ist der DDD-Code:

Produkt :: hinzufügen ('Apfel');

Architektur:

Aus Sicht von Domain-Driven Design spielt es keine Rolle, für welche Architektur Sie sich entscheiden. Bei Domain-Driven Design geht es nicht darum, bei Domain-Driven Design geht es um Sprache und Kommunikation.

Ohne eine saubere Projektarchitektur ist DDD jedoch fast unmöglich, da Sie beim Hinzufügen neuer Funktionen oder beim Ändern der alten versuchen müssen, die Flexibilität und Transparenz der Codebasis aufrechtzuerhalten. In einem großartigen Artikel erfahren Sie mehr über Ports, Adapter und Zwiebelarchitektur. Das Bild oben ist nur davon.

Es gibt auch Artikel über DDD, die ich sehr empfehlen kann - hier und hier .

Was gibt uns das am Ende:

• Fast alle Teammitglieder können den Projektcode lesen.
• Aufgabenstellung wird expliziter;
• Fehler in der Geschäftslogik werden leichter zu suchen;
• Für QS-Spezialisten ist es viel einfacher, den Code zu scannen und logische Fehler und Bugs zu finden.

Nachteile:

• Insbesondere zu Beginn des Projekts sind hochqualifizierte Entwickler erforderlich.
• Nicht alle Kunden sind bereit, solche Kosten zu tragen. DDD muss von allen Teilnehmern am Entwicklungsprozess untersucht werden.

FDD - Features Driven Development

FDD - Diese Methode (kurz als FDD bezeichnet) wurde von Jeff De Luca und dem anerkannten Guru auf dem Gebiet der objektorientierten Technologien, Peter Coad, entwickelt. FDD ist ein Versuch, die bekanntesten Techniken in der Softwareentwicklungsbranche zu kombinieren, die die wichtigen Funktionen (Eigenschaften) der entwickelten Software für den Kunden zugrunde legen. Das Hauptziel dieser Methodik ist es, echte, funktionierende Software systematisch und pünktlich zu entwickeln.

Wie andere adaptive Methoden konzentriert es sich auf kurze Iterationen, von denen jede dazu dient, einen bestimmten Teil der Systemfunktionalität zu erarbeiten. Laut FDD dauert eine Iteration zwei Wochen. FDD hat fünf Prozesse. Die ersten drei beziehen sich auf den Start des Projekts:

• Entwicklung eines gemeinsamen Modells;
• Zusammenstellen einer Liste der erforderlichen Systemeigenschaften;
• Planungsarbeiten an jedem Grundstück;
• Design jeder Immobilie;
• Bau jeder Immobilie.

Die letzten beiden Schritte müssen während jeder Iteration ausgeführt werden. Darüber hinaus ist jeder Prozess in Aufgaben unterteilt und verfügt über Überprüfungskriterien.

Lassen Sie uns näher auf jeden Punkt eingehen.

Entwicklung eines gemeinsamen Modells.

Die Entwicklung beginnt mit einer Analyse der Breite des vorhandenen Aufgabenspektrums und des Kontextes des Systems. Ferner wird für jeden simulierten Bereich eine detailliertere Analyse durchgeführt. Vorläufige Beschreibungen werden in kleinen Gruppen zusammengestellt und zur weiteren Diskussion und Expertenbewertung eingereicht. Nach einem der vorgeschlagenen Modelle oder deren Kombination wird ein Modell für einen bestimmten Bereich. Die Modelle der einzelnen Aufgabenbereiche werden zu einem gemeinsamen endgültigen Modell zusammengefasst, das sich während der Arbeit ändern kann.

Funktionen auflisten

Die während der Erstellung des allgemeinen Modells gesammelten Informationen werden verwendet, um eine Liste von Funktionen zu erstellen. Funktionen werden zu sogenannten "Domänen" (englische Domäne) zusammengefasst und wiederum nach einem Funktionsattribut in Unterregionen (englische Themenbereiche) unterteilt.

Jede Subdomain entspricht einem bestimmten Geschäftsprozess und ihre Schritte werden zu einer Liste von Funktionen (Eigenschaften). Die Funktionen werden in der Form „Aktion - Ergebnis - Objekt“ dargestellt, z. B. „Benutzerkennwort prüfen“. Die Entwicklung jeder Funktion sollte nicht länger als 2 Wochen dauern, andernfalls muss die Aufgabe in kleinere Iterationen zerlegt werden. Die Eigenschaftsliste in FDD entspricht dem Product Backlog in SCRUM.

Eigenschaften (Funktionen) Plan

Die nächste Stufe ist die Verteilung der Funktionen unter führenden Programmierern oder Teams.

Feature-Design

Für jede Eigenschaft wird ein Designpaket erstellt. Der Hauptprogrammierer skizziert eine kleine Gruppe von Immobilien, die innerhalb von zwei Wochen entwickelt werden sollen. Danach bleiben detaillierte Sequenzdiagramme für jede Eigenschaft übrig, in denen das allgemeine Modell angegeben ist. Als nächstes werden "Stubs" von Klassen und Methoden geschrieben. An dieser Stelle müssen wir uns auf das Design des Softwareprodukts konzentrieren.

Funktionsimplementierung

Wir schreiben den Code, entfernen die Stubs, testen.

Nachdem die Eigenschaft getestet und in das Produkt aufgenommen wurde, nehmen wir die Eigenschaft mit der nächsten Priorität und wiederholen den Entwurfs- / Implementierungszyklus.

Insgesamt erhalten wir als Ergebnis:

• Dokumentation der Systemeigenschaften;
• sorgfältiges Design;
• leichter zu bewerten kleine Aufgaben;
• Tests konzentrieren sich auf Geschäftsaufgaben;
• ausgefeilter Produkterstellungsprozess;
• Kurze iterative Entwicklungszyklen ermöglichen es Ihnen, die Funktionalität schnell zu erhöhen und Fehler zu reduzieren.

Nachteile:

• FDD eignet sich eher für große Projekte. Kleine Entwicklungsteams werden nicht alle Vorteile dieses Ansatzes nutzen können.
• erhebliche Implementierungs- und Schulungskosten.

MDD - Modellgetriebene Entwicklung

In jüngster Zeit wurde in Veröffentlichungen dem Thema Architektur und Entwicklung auf der Grundlage von MDA-Modellen (Model Driven Architecture) und MDD-Modellen (Model Driven Development) große Aufmerksamkeit gewidmet. Ohne auf Details einzugehen, werden nur wichtige Punkte hervorgehoben.

Modellgetriebene Entwicklung ist ein Stil der Softwareentwicklung, bei dem Modelle zu den wichtigsten Entwicklungsartefakten werden, aus denen Code und andere Artefakte generiert werden.

Einfach ausgedrückt besteht der springende Punkt bei der Entwicklung darin, die erforderlichen Diagramme zu erstellen, aus denen wir anschließend den Arbeitscode des Projekts generieren.

Das Hauptziel von MDD besteht darin, die mit der Verknüpfung mit bestimmten Systemplattformen und Softwareinfrastrukturen verbundenen Kosten zu minimieren. Schließlich ist die Hauptgeschäftslogik in Diagrammen enthalten und bindet uns nicht an den Umfang der Auswahl einer Programmiersprache und von Entwicklungswerkzeugen.

Lassen Sie uns ein wenig abschweifen und über den Compiler nachdenken. Es konvertiert eine Programmiersprache auf hoher Ebene in eine äquivalente Implementierung in Maschinensprache. Das Modell ist in diesem Fall ein Programm, das in einer höheren Sprache geschrieben ist und irrelevante Details über seine Implementierung verbirgt. In MDD sind unsere Diagramme eine weitere Abstraktionsebene, die es uns nicht ermöglicht, uns in den Entwicklungsdetails zu verlieren, sondern das Gesamtbild zu betrachten.

«», . ( ).

MDD ‑ . , , . MDD-, . Unified Modeling Language – UML 2.0.

Object Management Group (OMG) :

• c , ;
• - ;
• , .

MDD, , — . .

:

• (Minimum Viable Product) ;
• : , , ;
• ;
• .

Nachteile:

• MMD , Rational Software Architect, Simulink Sirius;
• ;
• .

PDD — Panic Driven Development

agile , PDD. , .

.

, , . . , ? , .

, , .

. . UX . ? , . , .

.

, , , . , . . , .

.

— . . . . . .

.

, , , — , . . , , , .

, .

, . . , , .

:

• ;
• ;
• , - .

:

• .

PDD , , , .

Fazit

agile . , , .

- Driven Development , DDD, BDD, MDD , .