Manchmal kann die vor Ihnen liegende Codierungsaufgabe überwältigend komplex sein. Trotz der Verfeinerung der User Story bleiben zahlreiche Unbekannte übrig. In solchen Situationen haben Sie zwei Möglichkeiten: Sie können die Story immer weiter verfeinern und auf eine Erleuchtung hoffen, oder Sie können mit dem beginnen, was Sie bereits wissen.
Kürzlich habe ich mich für den letzteren Ansatz entschieden: Ich habe einfach losgelegt. Ausgestattet mit einigen Annahmen darüber, wie die Dinge funktionieren sollten, begann ich mit der Entwicklung einer Anwendung mit einer grafischen Benutzeroberfläche und einem Backend. Das Ziel war es, zwei Objektdiagramme zu vergleichen und sie so darzustellen, dass ein Benutzer sie selektiv zusammenführen kann.
Erste Schritte
Mein erster Schritt bestand darin, die Unterschiede zwischen den beiden Objektgraphen zu ermitteln. Es konnten Knoten hinzugefügt oder entfernt werden, und die Beziehungen zwischen den Knoten könnten aktualisiert worden sein. Dies führte zu einer Sammlung von "Änderungs"-Objekten. Um jeden Vorgang anzugehen, begann ich mit einem kleinen Test und folgte dabei den Prinzipien der testgetriebenen Entwicklung (TDD). Wenn die Tests zu komplex wurden, wusste ich, dass etwas fehlte.
Nebenbei bemerkt ist TDD ein iterativer Arbeitsablauf, bei dem Sie einen bestimmten Aspekt, den Sie lösen möchten, in Bezug auf die von Ihnen verwendete Programmiersprache beschreiben. Diese Beschreibung hat die Form eines Tests. Dann implementieren Sie einen Teil des Codes, der die Anforderungen des Tests erfüllt. Bereinigen Sie den Code und wiederholen Sie den Vorgang.
Änderungen der Gruppierung
Die Implementierung dieses ersten Teils gab mir nicht nur die Gewissheit, dass wir zwei Diagramme effektiv vergleichen können, sondern ebnete auch den Weg für den nächsten Schritt: das Frontend. Ziel war es, die Änderungen in einer Baumansicht anzuzeigen, die es mir ermöglicht, zusammenhängende Änderungen zu gruppieren. Wenn zum Beispiel ein Knoten hinzugefügt wird, sind damit oft auch einige verwandte Beziehungen verbunden. Um die Hierarchie zu erstellen, benötigte ich die grafische Benutzeroberfläche noch nicht. Das war praktisch, denn so konnte ich einen TDD-Ablauf ohne externe Abhängigkeiten beibehalten.
Die ersten Versuche mit diesem einfachen Ansatz zeigten jedoch schnell seine Grenzen auf. Die Benutzer und sogar ich selbst fanden es überwältigend, den Sinn der Änderungen zu verstehen. Offensichtlich war der einfache Ansatz zu simpel.
Während ich die Idee verfeinerte, wie die Änderungen dem Benutzer präsentiert werden sollten, erwiesen sich die Tests, die ich auf dem Weg dorthin erstellt hatte, als unschätzbar wertvoll als Leitplanken. Ich konnte etwas ändern und beobachten, ob sich das Verhalten entsprechend änderte. Manchmal bedeutete dies, dass die Tests erfolgreich waren, während ich in anderen Fällen erwartete, dass sie fehlschlagen würden.
Abschließende Gedanken
Indem ich das erwartete Verhalten des Systems in Form von Tests beschrieb, legte ich einen einfachen Vertrag fest: einen Funktionsaufruf, der bei einer Eingabe die richtige Ausgabe liefert. Die Tests machten keine Annahmen über die innere Funktionsweise des Codes. Während des gesamten Prozesses musste ich den anfänglichen Vergleichscode feinabstimmen. Da ich den Code jedoch um die Tests herum aufgebaut hatte, bestanden die Änderungen hauptsächlich darin, neue Tests hinzuzufügen und sicherzustellen, dass das vorhandene Verhalten noch funktionierte.
Das Endergebnis waren drei unabhängige Module: eines für die Berechnung der Änderungen, eines für deren Gruppierung und eines für die Darstellung der Änderungen in der Benutzeroberfläche. Das Design ergab sich aus dem Schreiben von Tests im Vorfeld. TDD hat wahrlich den Tag gerettet!
Verfasst von
Arjan Molenaar
Unsere Ideen
Weitere Blogs
Contact