Untersuchung der Phasen des spezifikationsgesteuerten Entwicklungsarbeitsablaufs

Abgeschlossen

Jede Phase des Spec-Driven Development (SDD)-Workflows spielt eine entscheidende Rolle bei der Umwandlung von Ideen in arbeitsfähige Software. Entwickler, die den Zweck, den Inhalt und die Ausgabe jeder Phase verstehen, können SDD effektiv auf ihre eigenen Projekte anwenden.

Hinweis

Eine Greenfield-Anwendung wird verwendet, um zu veranschaulichen, wie jede Phase des SDD-Prozesses auf der vorherigen Phase aufbaut. Dasselbe Greenfield-Szenario wird später im Modul verwendet, wenn Sie mehr über die GitHub Spec Kit-Befehle erfahren, die jede Phase vereinfachen.

Von Vision bis hin zur Ausführung

Stellen Sie sich vor, Sie erstellen eine neue Anwendung: einen RSS-Feedleser, mit dem Benutzer Feeds abonnieren, neue Artikel anzeigen und nachverfolgen können, was sie gelesen haben. Wie gehen Sie von dieser Idee zum Arbeiten mit Code mit SDD? Die Antwort ist ein systematischer Ablauf durch vier Phasen, die jeweils Artefakte erzeugen, die in die nächste fließen.

Phase 1: Angeben

Die Spezifikation definiert genau, was die Software tun soll. Jede Implementierungsentscheidung führt auf sie zurück. Wenn die Funktionalität nicht in der Spezifikation angezeigt wird, wird sie nicht im Endprodukt angezeigt, es sei denn, Sie aktualisieren die Spezifikation.

Was eine gute Spezifikation enthält

Eine gut strukturierte Spezifikation enthält mehrere wichtige Abschnitte:

• Zusammenfassung: Eine präzise Beschreibung des Features aus Sicht des Endbenutzers. In diesem Abschnitt wird in einem oder zwei Sätzen "Was macht dieses Feature?" beantwortet.

  Beispiel: "Diese Anwendung ermöglicht Benutzern, RSS- und Atom-Feeds zu abonnieren, Artikel nach dem neuesten zuerst anzuzeigen und den Lese-/Ungelesen-Status zu verfolgen. Feeddaten werden lokal auf dem Gerät gespeichert."

• Benutzergeschichten: Kurze Beschreibungen der Interaktion der Benutzer mit dem Feature. Benutzergeschichten erfassen Absicht und Wert anstelle der technischen Implementierung.

  Beispiel:

  • Als Benutzer möchte ich RSS-Feeds nach URL hinzufügen, damit ich meinen Lieblingswebsites folgen kann.
  • Als Benutzer möchte ich ungelesene Artikel zuerst sortiert sehen, damit ich aktuelle Inhalte aufholen kann.

• Akzeptanzkriterien: Spezifische, testbare Bedingungen, die erfüllt sein müssen, damit das Feature als vollständig betrachtet wird. Schreiben Sie Akzeptanzkriterien als feststellbare Fakten.

  Beispiel:

  • Der Benutzer kann einen Feed hinzufügen, indem er eine gültige RSS- oder Atom-URL eingibt.
  • Ungültige Feed-URLs zeigen eine eindeutige Fehlermeldung an.
  • Neue Artikel werden nach dem Aktualisieren von Feeds angezeigt.
  • Artikel werden mit Lese-/Ungelesen-Status angezeigt, der zwischen Sitzungen beibehalten wird.

• Funktionale Anforderungen: Detaillierte Beschreibungen des Systemverhaltens – Funktionsweise des Features. Funktionale Anforderungen erläutern Benutzergeschichten mit Spezifischen zu Schnittstellen, Prozessen und Datenverarbeitung.

• Nicht funktionsfähige Anforderungen: Qualitätsattribute wie Leistung, Sicherheit und Skalierbarkeit. Nicht funktionsfähige Anforderungen stellen sicher, dass KI-generierter Code den Qualitätsstandards des Unternehmens entspricht, nicht nur funktionale Korrektheit.

• Randfälle: Ungewöhnliche Szenarien, Fehlerzustände und Grenzverhalten. Das explizite Dokumentieren von Randfällen verhindert, dass KI Annahmen vornimmt, die deiner Absicht möglicherweise nicht entsprechen.

Die Denkweisenverschiebung

Das Schreiben der Spezifikation ist genauso wichtig wie das Schreiben von Code. Die Spezifikation ist keine Formalität, um das Projektmanagement zu erfüllen – es ist das Artefakt, das die KI-unterstützte Codegenerierung steuert. Investieren Sie die gleiche Sorgfalt in die Herstellung von Spezifikationen wie bei der manuellen Implementierung von Features.

Phase 2: Planen

Eine Spezifikation definiert, was Sie erstellen müssen. Ein technischer Plan definiert , wie Sie ihn erstellen. Der Plan wandelt Anforderungen in Architekturentscheidungen um und stellt sicher, dass Ihre Implementierung sowohl mit der Spezifikation als auch mit den Grundsätzen Ihres Projekts übereinstimmt.

Was ein guter Plan enthält

Ein Plan sollte die folgenden Elemente enthalten:

• Architekturübersicht: Eine allgemeine Ansicht der Interaktion von Komponenten. Für den RSS-Feedleser:

  "Erstellen Sie eine .NET Anwendung mit einer lokalen SQLite-Datenbank zum Speichern von Feeds und Artikeln. Ein FeedService verarbeitet RSS/Atom-Analyse und -Überprüfung. Auf der Benutzeroberfläche wird eine Feedliste und eine Artikelansicht mit Lese-/Ungelesen-Nachverfolgung angezeigt. Wenn ein Benutzer einen Feed hinzufügt, überprüft die App die URL, ruft den Feedinhalt ab, analysiert Artikel und speichert sie lokal."

• Technologiestapel und wichtige Entscheidungen: Explizite Dokumentation von Technologieentscheidungen und -rationalen. Jede Entscheidung sollte sowohl den Spezifikationsanforderungen als auch den Organisationsprinzipien entsprechen.

  Beispielentscheidungen:

  • Laufzeit: .NET 8 Konsolenanwendung.
  • Datenspeicher: SQLite mit Entity Framework Core für lokale Persistenz.
  • Feedanalyse: System.ServiceModel.Syndication für RSS/Atom-Unterstützung.
  • Sicherheit: HTML-Bereinigung vor dem Rendern von Artikelinhalten.

• Implementierungssequenz: Die logische Reihenfolge der Implementierungsschritte. Eine typische Sequenz stellt sicher, dass grundlegende Elemente (Datenbankschema) vor abhängigen Komponenten (API, die in die Datenbank schreibt) vorhanden sind.

• Überprüfung der Verfassung: Eine Überprüfung, dass vorgeschlagene Lösungen den Projektprinzipien entsprechen. Wenn Ihre Projektkonstitution besagt, dass "HTML-Inhalt vor dem Rendern bereinigt werden muss", bestätigt die Planüberprüfung, dass Sie eine HTML-Bereinigungsbibliothek verwenden.

• Annahmen und offene Fragen: Dokumentation von Annahmen und ungelösten Fragen. Diese Transparenz hilft, potenzielle Probleme zu erkennen, bevor die Implementierung beginnt.

Die Trennung von Spezifikation und Plan

Wenn Sie später Technologien wechseln – z. B. von SQLite zu einer anderen Datenbank – aktualisieren Sie den Plan, während die Spezifikation weitgehend unverändert bleibt. Die Featureanforderungen werden nicht geändert; nur der Implementierungsansatz ändert sich.

Phase 3: Vorgänge

Technische Pläne bieten Architekturrichtung, aber die Umsetzung erfordert konkrete, umsetzbare Schritte. In der Aufgabenphase werden allgemeine Entscheidungen in bestimmte Arbeitsaufgaben umgewandelt.

Wie gute Aufgaben aussehen

Jeder Vorgang sollte folgendes sein:

• Umsetzbare: Die Aufgabe gibt klar an, was getan werden muss.
• Überprüfbar: Sie können überprüfen, ob die Aufgabe abgeschlossen ist.
• Unabhängig, sofern möglich: Die Aufgabe kann häufig abgeschlossen werden, ohne auf nicht verknüpfte Arbeit zu warten.
• Zeitgebunden: Ein Entwickler kann die Aufgabe in einem angemessenen Zeitrahmen abschließen.

Hier ist ein Beispiel für eine gut bezogenen Aufgabe: "Implementieren einer AddFeed-Methode, die eine RSS/Atom-URL akzeptiert. Die Methode überprüft das Feedformat, analysiert den Feedinhalt, speichert Feedmetadaten und Artikel in SQLite und gibt die Feed-ID zurück."

Diese Aufgabe ist spezifisch darüber, was erstellt werden soll, was sie akzeptiert, welche Überprüfungen angewendet werden sollen, wo Daten gespeichert werden sollen und was zurückgegeben werden soll.

Phasenbasierte Organisation

Komplexe Features profitieren von der Organisation von Aufgaben in Phasen:

1. Phase 1 – Gründung: Richten Sie die Projektstruktur ein, erstellen Sie ein Datenbankschema, und fügen Sie erforderliche Pakete hinzu.
2. Phase 2 – Kernfunktionalität: Implementieren Sie die Feedanalyse, fügen Sie die URL-Validierung hinzu, und implementieren Sie den Artikelspeicher.
3. Phase 3 – Benutzeroberfläche: Erstellen Sie die Feedlistenansicht, fügen Sie die Artikelanzeige hinzu, und implementieren Sie die Lese-/Ungelesen-Nachverfolgung.
4. Phase 4 – Sicherheit: Fügen Sie HTML-Bereinigung hinzu, implementieren Sie HTTPS-nur-Feed-Abrufe, und fügen Sie fehlerbehandlung hinzu.
5. Phase 5 – Tests: Schreiben Sie Komponententests, erstellen Sie Integrationstests, und dokumentieren Sie die Anwendung.

Abhängigkeiten von Aufgaben

Die Aufgabenreihenfolge ist von Bedeutung. Datenbankschemaänderungen werden in der Regel zuerst vorgenommen, da Back-End-Code von der Schemaexistenz abhängt. Back-End-API-Endpunkte kommen vor Front-End-Komponenten, die diese Endpunkte aufrufen. Tests werden ausgeführt, nachdem der getestete Code vorhanden ist.

Überprüfungsprüfpunkt

Bevor Sie zur Implementierung wechseln, überprüfen Sie Aufgaben anhand des Plans und der Spezifikation. Zum Beispiel:

• Wenn eine Anforderung nicht von einem Vorgang abgedeckt wird, fügen Sie einen entsprechenden Vorgang hinzu.
• Wenn ein Vorgang nicht mit dem Plan oder der Spezifikation verknüpft ist, bewerten Sie, ob der Vorgang erforderlich ist.

Phase 4: Implementieren

Wenn phasen 1-3 gut durchgeführt werden, sollte die Implementierung einfach sein. Sie können Aufgaben einzeln mit klaren Anleitungen ausführen.

Der Implementierungsprozess

Die Implementierung folgt einer einfachen Schleife:

1. Wählen Sie die nächste Aufgabe aus der Aufgabenliste aus.
2. Schreiben Sie Code zum Implementieren der Aufgabe (manuell oder mithilfe von KI-Unterstützung).
3. Testen Sie, dass der Vorgang die Erwartungen an die Spezifikation und den Plan erfüllt.
4. Markieren Sie die Aufgabe als erledigt, und wechseln Sie zum nächsten Vorgang.

Die Implementierung wird fortgesetzt, bis alle Aufgaben ausgeführt werden, d. h., die Anforderungen der Spezifikation werden alle implementiert. Integrieren und testen Sie häufig – möglicherweise nach jedem Vorgang oder einer kleinen Gruppe von Aufgaben – um sicherzustellen, dass das System als Ganzes funktioniert.

Behandeln von Entdeckungen während der Implementierung

Während der Implementierung können Sie feststellen, dass etwas verpasst wurde oder aktualisiert werden muss. Anstatt Ad-hoc-Codeänderungen vorzunehmen, empfiehlt SDD, dass Sie zurückkehren und die Spezifikation oder den Plan entsprechend aktualisieren und dann die verbleibenden Aufgaben anpassen. Dieser Prozess hält Artefakte im Einklang mit der Realität, wobei sie als lebende Dokumente beibehalten werden.

Iterative Natur und Prüfpunkte

Während die Elemente der Liste sequenziell angeordnet sind, ermöglicht SDD Iterationen. Hier sind einige Beispiele:

• Nachdem Sie eine Spezifikation geschrieben haben, erhalten Sie möglicherweise Feedback, das die Anforderungen verändern kann. Wenn sich die Anforderungen ändern, sollten Sie die Spezifikation aktualisieren, bevor Sie den Plan erstellen.
• Etwa zur Hälfte der Implementierung könnten einige Randfälle auftreten, die nicht in der Spezifikation enthalten sind. Wenn Änderungen, die sich auf die Implementierung auswirken, entdeckt werden, sollten Sie Ihre Spezifikationsdokumente, Pläne und Aufgabendokumente aktualisieren, bevor Sie mit der Implementierung fortfahren.

Iteration ist ein wichtiger Vorteil. Die Kosten für Änderungen sind geringer, da wissen in der Spezifikation und im Plan erfasst wird. Wenn Änderungen vorgenommen werden, werden sie systematisch weitergegeben.

Prüfpunkte zwischen Phasen sorgen für Qualität und Ausrichtung. Bevor Sie von Spezifikation zu Plan wechseln, überprüfen Sie, ob die Spezifikation vollständig und klar ist. Bevor Sie von Plan zu Vorgängen wechseln, stellen Sie sicher, dass der Plan machbar und detailliert genug ist. Vergewissern Sie sich vor der Implementierung, dass Aufgaben alle Anforderungen erfüllen. Es ist besser, mehr Zeit im Voraus zu verbringen, als probleme später zu beheben.

Das Ergebnis des SDD-Workflows

Der Endzustand ist eine vollständig implementierte App oder ein Feature, bei dem der Code mit einer Spezifikation übereinstimmt, und Sie verfügen über Dokumentation (Spezifikation und Plan), die genau der Implementierung entspricht. Die Ausrichtung zwischen Code und Dokumentation bietet die folgenden Vorteile:

• Wartung: Verstehen, was das System tut und warum.
• Onboarding: Neue Teammitglieder können die Spezifikation lesen und einen Plan machen, um das System zu verstehen.
• Vertrauen: Die Dokumentation spiegelt die Realität genau wider – im Gegensatz zu vielen Projekten, bei denen Dokumente vom Code abweichen.

Das Schreiben all dieser Artefakte von Hand mag vielleicht mühsam klingen, aber KI-Tools wie GitHub Spec Kit können die schwere Arbeit der Erstellung der Spezifikation, des Plans und der Aufgaben automatisieren.

Zusammenfassung

Die vier Phasen der spezifikationsgesteuerten Entwicklung – Angeben, Planen, Aufgaben und Implementieren – bieten einen strukturierten Workflow, der Ideen in Arbeitssoftware transformiert. Jede Phase erzeugt Artefakte, die den nächsten Schritt leiten, um die Ausrichtung zwischen Anforderungen und Implementierung sicherzustellen. Die lebendige Natur dieser Artefakte ermöglicht eine kontinuierliche Anpassung, während die systematischen Prüfpunkte Qualität und Kohärenz während des gesamten Prozesses erhalten.

Hinweis

Weitere Details finden Sie auf der Registerkarte "Text und Bilder ".